From nobody Thu Aug 1 07:54:18 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092021200F3; Thu, 1 Aug 2019 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 WPEPKizHXe36; Thu, 1 Aug 2019 07:54:06 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 9411E12000E; Thu, 1 Aug 2019 07:54:05 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id m10so69439987edv.6; Thu, 01 Aug 2019 07:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=kvHqXaI86roKaggE8kh0PGJrOSwhHkL2IAj+Kh/zgNo=; b=b4wEbzYUsW/rTBJrsRiaB4YCMgGJvrdDNOYJg3MJtB5jW1jDIwi3n5fuCqYXWFkdyx WPL3jgADN6R3esMcLSHvo3NiVnmwWkY5wLnKtvKITjVU4sAhBGEJjREqvH2xrlbnLkxA OFUbgtHzGzR+3sWCygK4CDX6JmzTk/30ScR8I+yPs6wj3z1pd+ihj2NIgNzyEK/kaQju YSwGLE6Tgfg1+F/5FORzmouDNoQInBN5Ximw8BWYKHObw6BYAv9F4sxT2Ya7blXo/nMG WVHqlHAu7xHceZscQIkRT2on5A+e6NYRPQcZo5QDH4Fs2SIZK9Ny3WrRFFPmA7hNryUz EIlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=kvHqXaI86roKaggE8kh0PGJrOSwhHkL2IAj+Kh/zgNo=; b=ua2KEAlnwWFdDi354dLWclPFmgmo1+2Q8R72G5rhYtm2dt1dJEQx7aJ7SYsjkCWQGA LlmI+5saCpjb3aTWabgHQvYJxqRk8A+F9Z98hA5cbY3I+/MdflU8Jr+Up5zFGRhx9fBE PtKZXekDxB6db+7QHuzoo9aHwvuR6VQC4r3rfRFBheHid7Gb5eNEbNcnCNE7r/K2i7uf KqYK8A6n/EVgLOi5wzqSzQifonXfPB6sCRGnKMPIASZu+fAbLL9d1Qlyk/MkUbOPQ+ph wI2PgoLXoVlmMbyFa9TIQYAyJBKGDLYGwxhI+FNFowpvId2Wj4LYUMh/RtbW+02pOXcc S41g== X-Gm-Message-State: APjAAAWEIBrHUeG3xu0zvhKKq4jXp4IxD18zNGT3AF1ATpRjR4YmdDkQ feFOcb24Gy55tAdL+bNbsCjCukOvIVcza4LhFraxOmxC X-Google-Smtp-Source: APXvYqzLo298tMQNv637v8DpIaoup4YBcBhbKwTCLD6iH5IxPea/p2ME0lIzY8A/8TbBaC+HR8eDQgcNehKB5GzfJx8= X-Received: by 2002:a17:906:505:: with SMTP id j5mr100179292eja.261.1564671242922; Thu, 01 Aug 2019 07:54:02 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 1 Aug 2019 16:54:01 +0200 From: Alvaro Retana MIME-Version: 1.0 Date: Thu, 1 Aug 2019 16:54:01 +0200 Message-ID: To: draft-ietf-roll-aodv-rpl@ietf.org Cc: roll , roll-chairs , Ines Robles Content-Type: multipart/alternative; boundary="0000000000009fed5c058f0f6947" Archived-At: Subject: [Roll] AD Review of draft-ietf-roll-aodv-rpl-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 14:54:16 -0000 --0000000000009fed5c058f0f6947 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear authors: I just finished reading this document. I am excited about the new functionality, but I have several significant issues/questions about the document, and a lot of comments (in-line below). (1) What is AODV-RPL? Reading the document, my impression of AODV-RPL varies between an enhancement to RPL for Reactive Route Discovery (*maybe* in addition to the usual proactive routing), to ships-in-the-night reactive-only protocol that uses some of the RPL concepts (but not exactly sure which ones). The different MOP indicates that it is different from "base" RPL (rfc6550), but it is not clear what the assumptions are...and which parts are "inherited" from the "base" and which ones are not used. Another way to ask the same question is: What is the relationship of AODV-RPL to RPL? What mechanisms are not applicable with the new MOP? Is it expected that an instance of RPL will also be running in the network? Please be clear early in the document. To quote Charlie: "AODV-RPL is a variation on RPL" [1]. What remains, what changes, etc.. (2) Document Status (for the Chairs/Shepherd) I didn't find a specific discussion in the archive about the status of this document. Did one take place? At this point I am mostly curious given the similarities with rfc6997 (Experimental) and the fact that "Future Work" is discussed -- not typical in a Standards Track document. IOW, why is this document intended to be a Proposed Standard and not Experimental? (3) Replacing rfc6997?? This document uses some of the features from rfc6997 (see some comments about that in-line), which is fine. The Introduction falls just short of saying that this work replaces rfc6997. Should it be considered a replacement? I ask mostly in the context of rfc7733 (RPL in Home and Building) which mandates (MUST) the use of rfc6997. Should rfc7733 be Updated? [I'm just asking the question for it to be considered...I am not sure of deployments which conform to rfc7733 or rfc6997...or the impact this would have.] (4) Link checks The operation of AODV-RPL depend on link checks (=C2=A76.2.1/=C2=A76.4) to = determine symmetry and whether it can "fulfill the requirements". But these checks are not explained or defined anywhere (are they?) beyond an *example* in the Appendix. I think defining the checks is a critical part of the specification of the mechanism...specially for a Standards Track protocol. Please take a look at the comments below. I will wait for the major points to be addressed before starting the IETF Last Call. Thanks!! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/roll/PoQQBOmWZ2XFRWVK13Q5Z4W9x-s [Line numbers from idnits.] ... 14 Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) [minor] This is not the clearest title I've ever seen. Suggestion: Reactive Route Discovery using RPL (AODV-RPL) ...or something like that. 15 draft-ietf-roll-aodv-rpl-07 17 Abstract 19 Route discovery for symmetric and asymmetric Point-to-Point (P2P) 20 traffic flows is a desirable feature in Low power and Lossy Networks 21 (LLNs). For that purpose, this document specifies a reactive P2P 22 route discovery mechanism for both hop-by-hop routing and source 23 routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL 24 protocol. Paired Instances are used to construct directional paths, 25 in case some of the links between source and target node are 26 asymmetric. [minor] s/(AODV) based RPL protocol/(AODV) based RPL protocol (AODV-RPL) ... 100 1. Introduction [general comment] Avoid mentioning the "negative" of other proposals and focus on why this work is needed. IOW, the justification should not be "because others can't do it". [nit] Some of the paragraphs throughout the document are very long and could be split to better convey the ideas. 102 RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy 103 Networks)) is a IPv6 distance vector routing protocol designed to 104 support multiple traffic flows through a root-based Destination- 105 Oriented Directed Acyclic Graph (DODAG). Typically, a router does 106 not have routing information for most other routers. Consequently, 107 for traffic between routers within the DODAG (i.e., Point-to-Point 108 (P2P) traffic) data packets either have to traverse the root in non- 109 storing mode, or traverse a common ancestor in storing mode. Such 110 P2P traffic is thereby likely to traverse longer routes and may 111 suffer severe congestion near the DAG root (for more information see 112 [RFC6997], [RFC6998]). [nit] s/RPL[RFC6550]/RPL [RFC6550] [minor] s/Routing Protocol for LLNs (Low-Power and Lossy Networks)/Routing Protocol for Low-Power and Lossy Networks That's the name of the protocol. [nit] s/is a IPv6/is an IPv6 [minor] "Such P2P traffic is thereby likely to traverse longer routes and may suffer severe congestion near the DAG root (for more information see [RFC6997], [RFC6998])." I see that those other RFCs also make the statement that congestion is possible, and even longer routes...but I don't see more information there. Did I miss it? If not, then I don't see the value of those references at this point. 114 To discover better paths for P2P traffic flows in RPL, P2P-RPL 115 [RFC6997] specifies a temporary DODAG where the source acts as a 116 temporary root. The source initiates DIOs encapsulating the P2P 117 Route Discovery option (P2P-RDO) with an address vector for both hop- 118 by-hop mode (H=3D1) and source routing mode (H=3D0). Subsequently, e= ach 119 intermediate router adds its IP address and multicasts the P2P mode 120 DIOs, until the message reaches the Target Node, which then sends the 121 "Discovery Reply" object. P2P-RPL is efficient for source routing, 122 but much less efficient for hop-by-hop routing due to the extra 123 address vector overhead. However, for symmetric links, when the P2P 124 mode DIO message is being multicast from the source hop-by-hop, 125 receiving nodes can infer a next hop towards the source. When the 126 Target Node subsequently replies to the source along the established 127 forward route, receiving nodes determine the next hop towards the 128 Target Node. For hop-by-hop routes (H=3D1) over symmetric links, thi= s 129 would allow efficient use of routing tables for P2P-RDO messages 130 instead of the "Address Vector". [minor] Expand DIO on first use. [minor] The description above of P2P-RPL seems to include too much (unnecessary for this document) detail. It also seems to propose enhancements (in the last couple of sentences). Consider simplifying to something like this: To discover better paths for P2P traffic flows in RPL, P2P-RPL [RFC6997] specifies a temporary DODAG where the source acts as a temporary root. P2P-RPL is efficient for source routing, but can be much less efficient for hop-by-hop routing due to the extra address vector overhead. 132 RPL and P2P-RPL both specify the use of a single DODAG in networks of 133 symmetric links, where the two directions of a link MUST both satisfy 134 the constraints of the objective function. This disallows the use of 135 asymmetric links which are qualified in one direction. But, 136 application-specific routing requirements as defined in IETF ROLL 137 Working Group [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may be 138 satisfied by routing paths using bidirectional asymmetric links. For 139 this purpose, [I-D.thubert-roll-asymlink] described bidirectional 140 asymmetric links for RPL [RFC6550] with Paired DODAGs, for which the 141 DAG root (DODAGID) is common for two Instances. This can satisfy 142 application-specific routing requirements for bidirectional 143 asymmetric links in core RPL [RFC6550]. Using P2P-RPL twice with 144 Paired DODAGs, on the other hand, requires two roots: one for the 145 source and another for the target node due to temporary DODAG 146 formation. For networks composed of bidirectional asymmetric links 147 (see Section 5), AODV-RPL specifies P2P route discovery, utilizing 148 RPL with a new MoP. AODV-RPL makes use of two multicast messages to 149 discover possibly asymmetric routes. This provides higher route 150 diversity and can find suitable routes that might otherwise go 151 undetected by RPL. AODV-RPL eliminates the need for address vector 152 overhead in hop-by-hop mode. This significantly reduces the control 153 packet size, which is important for Constrained LLN networks. Both 154 discovered routes (upward and downward) meet the application specific 155 metrics and constraints that are defined in the Objective Function 156 for each Instance [RFC6552]. On the other hand, the point-to-point 157 nature of routes discovered by AODV-RPL can reduce interference near 158 the root nodes and also provide routes with fewer hops, likely 159 improving performance in the network. [major] "RPL and P2P-RPL both specify the use of a single DODAG in networks of symmetric links, where the two directions of a link MUST both satisfy the constraints of the objective function." s/MUST/must Because you are referring to RPL/P2P-RPL, the MUST is not Normative. [minor] s/as defined in IETF ROLL Working Group [RFC5548]/as defined in [RFC5548] [minor] s/application-specific routing requirements...may be satisfied by routing paths using bidirectional asymmetric links./application-specific routing requirements may also be satisfied by routing paths using bidirectional asymmetric links. I found just one mention of anything related to asymmetry (in rfc5673)...so I think adding "also" is important. [minor] "For this purpose, [I-D.thubert-roll-asymlink] described bidirectional asymmetric links for RPL [RFC6550] with Paired DODAGs, for which the DAG root (DODAGID) is common for two Instances. This can satisfy application-specific routing requirements for bidirectional asymmetric links in core RPL [RFC6550]." I think that mention to this draft is unnecessary and may be confusing to readers: the work seems to have been abandoned, and if it satisfies the requirements, then why do we need something else? ;-) [minor] I would also take out this sentence: "Using P2P-RPL twice..." [minor] Expand MoP on first use. BTW, rfc6550 uses MOP (not MoP), please be consistent. [minor] "Both discovered routes (upward and downward) meet the application specific metrics and constraints that are defined in the Objective Function for each Instance [RFC6552]." I didn't find any talk of application specific metrics in rfc6552. ... 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in 175 [RFC2119], [RFC8174]. This document uses the following terms: [major] Please use the rfc8174 template without modifications. ... 264 3. Overview of AODV-RPL [minor] It would be very nice if this overview had forward references to where the behavior is specified. 266 With AODV-RPL, routes from OrigNode to TargNode within the LLN 267 network are established "on-demand". In other words, the route 268 discovery mechanism in AODV-RPL is invoked reactively when OrigNode 269 has data for delivery to the TargNode but existing routes do not 270 satisfy the application's requirements. The routes discovered by 271 AODV-RPL are not constrained to traverse a common ancestor. Unlike 272 RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric 273 communication paths in networks with bidirectional asymmetric links. 274 For this purpose, AODV-RPL enables discovery of two routes: namely, 275 one from OrigNode to TargNode, and another from TargNode to OrigNode. 276 When possible, AODV-RPL also enables symmetric route discovery along 277 Paired DODAGs (see Section 5). [major] I get the impression that this document is an extension to RPL, to be used when the existing routes don't meet specific requirements...at this point the reactive part would kick in. Is that a fair characterization? The document jumps into talking about the extension, but it says nothing about how the base RPL is used with it...or even if it is. Please spend a paragraph explaining that relationship. 279 In AODV-RPL, routes are discovered by first forming a temporary DAG 280 rooted at the OrigNode. Paired DODAGs (Instances) are constructed 281 according to the AODV-RPL Mode of Operation (MoP) during route 282 formation between the OrigNode and TargNode. The RREQ-Instance is 283 formed by route control messages from OrigNode to TargNode whereas 284 the RREP-Instance is formed by route control messages from TargNode 285 to OrigNode. Intermediate routers join the Paired DODAGs based on 286 the rank as calculated from the DIO message. Henceforth in this 287 document, the RREQ-DIO message means the AODV-RPL mode DIO message 288 from OrigNode to TargNode, containing the RREQ option (see 289 Section 4.1). Similarly, the RREP-DIO message means the AODV-RPL 290 mode DIO message from TargNode to OrigNode, containing the RREP 291 option (see Section 4.2). The route discovered in the RREQ-Instance 292 is used for transmitting data from TargNode to OrigNode, and the 293 route discovered in RREP-Instance is used for transmitting data from 294 OrigNode to TargNode. [nit] s/rank/Rank/g To be consistent with how rfc6550 uses the term. 296 4. AODV-RPL DIO Options 298 4.1. AODV-RPL DIO RREQ Option 300 OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO 301 message. A RREQ-DIO message MUST carry exactly one RREQ option. [major] What should a receiver do if more than one RREQ options are received? 303 0 1 2 3 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type | Option Length |S|H|X| Compr | L | MaxRank | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Orig SeqNo | | 309 +-+-+-+-+-+-+-+-+ | 310 | | 311 | | 312 | Address Vector (Optional, Variable Length) | 313 | | 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 1: DIO RREQ option format for AODV-RPL MoP 319 OrigNode supplies the following information in the RREQ option: 321 Type 322 The type assigned to the RREQ option (see Section 9.2). [major] s/Type/Option Type/g That is the name in rfc6550. [minor] Use TBDx so that it matches the IANA Considerations section. The same applies to other places where TBDx can be used. ... 348 L 350 2-bit unsigned integer determining the duration that a node is 351 able to belong to the temporary DAG in RREQ-Instance, including 352 the OrigNode and the TargNode. Once the time is reached, a node 353 MUST leave the DAG and stop sending or receiving any more DIOs for 354 the temporary DODAG. The definition for the "L" bit is similar to 355 that found in [RFC6997], except that the values are adjusted to 356 enable arbitrarily long route lifetime. [major] "definition for the "L" bit is similar to that found in [RFC6997], except that..." I think that this statement may be confusing to readers...remove it. 358 * 0x00: No time limit imposed. 359 * 0x01: 16 seconds 360 * 0x02: 64 seconds 361 * 0x03: 256 seconds 363 L is independent from the route lifetime, which is defined in the 364 DODAG configuration option. The route entries in hop-by-hop 365 routing and states of source routing can still be maintained even 366 after the DAG expires. [??] I don't understand what the last sentence is trying to say. It sounds as if the information learned through the DAG can still be used after the DAG expires...up until the route lifetime expires...is that it? Please clarify. ... 373 Orig SeqNo 374 Sequence Number of OrigNode, defined similarly as in AODV 375 [RFC3561]. [major] "similarly as in AODV" Similarly, or the same?? Note that this reference could require rfc3561 to be a Normative Reference. I found this text in =C2=A76.1, which defines this field. Which one is correct? Suggestion: point to =C2=A76.1. Each node maintains a sequence number, which rolls over like a lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for detailed operation. When the OrigNode initiates a route discovery process, it MUST increase its own sequence number to avoid conflicts with previously established routes. The sequence number is carried in the OrigSeqNo field of the RREQ option. ... 382 A node MUST NOT join a RREQ instance if its own rank would equal to 383 or higher than MaxRank. Targnode can join the RREQ instance at a 384 rank whose integer portion is equal to the MaxRank. A router MUST 385 discard a received RREQ if the integer part of the advertised rank 386 equals or exceeds the MaxRank limit. This definition of MaxRank is 387 the same as that found in [RFC6997]. [minor] s/own rank would equal to/own rank would be equal to [nit] s/Targnode/TargNode [minor] The second sentence sounds like it contradicts the first one (where it says that "A node MUST NOT join..."); I think that inverting the order would help: TargNode can join the RREQ instance at a rank whose integer portion is equal to the MaxRank. Other nodes MUST NOT join a RREQ instance if its own rank is equal to or higher than MaxRank. [major] "This definition of MaxRank is the same as that found in [RFC6997]." True, for the most part: the context of the definition is different. Because the definition are not exactly the same, and MaxRank is defined in this document, please take the sentence out. I don't think it adds anything significant. 389 4.2. AODV-RPL DIO RREP Option 391 TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO 392 message. A RREP-DIO message MUST carry exactly one RREP option. 393 TargNode supplies the following information in the RREP option: [major] What should the receiver do if more than one RREP option is received? ... 441 Shift 442 6-bit unsigned integer. This field is used to recover the 443 original InstanceID (see Section 6.3.3); 0 indicates that the 444 original InstanceID is used. [major] s/InstanceID/RPLInstanceID/g 446 Rsv 447 MUST be initialized to zero and ignored upon reception. [major] Do you expect these bits to be assigned by IANA in the future? ... 456 4.3. AODV-RPL DIO Target Option 458 The AODV-RPL Target (ART) Option is based on the Target Option in 459 core RPL [RFC6550]. The Flags field is replaced by the Destination 460 Sequence Number of the TargNode and the Prefix Length field is 461 reduced to 7 bits so that the value is limited to be no greater than 462 127. [minor] What is the name of this option: "AODV-RPL DIO Target Option" or "AODV-RPL Target Option"? Please be consistent. [??] "the Prefix Length field is reduced to 7 bits so that the value is limited to be no greater than 127." Why? Is there an advantage? Seriously, I'm curious. 464 A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO 465 message MUST carry exactly one ART Option. [major] What should a node do if more than one ART Option is received in a RREP-DIO message? 467 OrigNode can include multiple TargNode addresses via multiple AODV- 468 RPL Target Options in the RREQ-DIO, for routes that share the same 469 constraints. This reduces the cost to building only one DODAG. 470 Furthermore, a single Target Option can be used for different 471 TargNode addresses if they share the same prefix; in that case the 472 use of the destination sequence number is not defined in this 473 document. [major] To be clear, what are the "constraints"? Where are they defined/signaled? Are you talking about the contents of the RREQ Option (S, H, MaxRank...anything else?)? If so, please point that out explicitly; "constraints" are mentioned in different places, but I couldn't find an explicit definition. [major] "...in that case the use of the destination sequence number is not defined in this document." Then that means that this last feature is not supported...right? If that's true, then please don't mention it. ... 511 Target Prefix / Address 512 (variable-length field) An IPv6 destination address or prefix. 513 The Prefix Length field contains the number of valid leading bits 514 in the prefix. The bits in the Target Prefix / Address field 515 after the prefix length (if any) MUST be set to zero on 516 transmission and MUST be ignored on receipt. [major] "The bits in the Target Prefix / Address field after the prefix length (if any)..." I can see how this "is ok" because the receiver knows of these trailing bits from the Option Length...*but*, why even allow it? Why would the Target Prefix / Address not simply have a length =3D Prefix Length? BTW, I know that rfc6550 has the same definition. That doesn't make it right. Every extra bit has a cost...prefixes are elided, and here extra bits are allowed. 518 5. Symmetric and Asymmetric Routes 520 In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode, 521 R is an intermediate router, and T is the TargNode. If the RREQ-DIO 522 arrives over an interface that is known to be symmetric, and the 'S' 523 bit is set to 1, then it remains as 1, as illustrated in Figure 4. 524 If an intermediate router sends out RREQ-DIO with the 'S' bit set to 525 1, then all the one-hop links on the route from the OrigNode O to 526 this router meet the requirements of route discovery, and the route 527 can be used symmetrically. [nit] A couple of places use "S bit", "'S' bit" is used above (and in most of the document)...please be consistent. Recommendation: S bit or S-bit. [BTW, please apply the same style to the other bits.] ... 552 Upon receiving a RREQ-DIO with the 'S' bit set to 1, a node 553 determines whether this one-hop link can be used symmetrically, i.e., 554 both the two directions meet the requirements of data transmission. 555 If the RREQ-DIO arrives over an interface that is not known to be 556 symmetric, or is known to be asymmetric, the 'S' bit is set to 0. If 557 the 'S' bit arrives already set to be '0', it is set to be '0' on 558 retransmission (Figure 5). Therefore, for asymmetric route, there is 559 at least one hop which doesn't fulfill the constraints in the two 560 directions. Based on the 'S' bit received in RREQ-DIO, the TargNode 561 T determines whether or not the route is symmetric before 562 transmitting the RREP-DIO message upstream towards the OrigNode O. [nit] s/for asymmetric route/for an asymmetric route 564 The criteria used to determine whether or not each link is symmetric 565 is beyond the scope of the document, and may be implementation- 566 specific. For instance, intermediate routers MAY use local 567 information (e.g., bit rate, bandwidth, number of cells used in 568 6tisch), a priori knowledge (e.g. link quality according to previous 569 communication) or use averaging techniques as appropriate to the 570 application. [major] s/MAY/may This may is not Normative because there is no specific action (just examples). ... 602 6.1. Route Request Generation ... 614 Each node maintains a sequence number, which rolls over like a 615 lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for 616 detailed operation. When the OrigNode initiates a route discovery 617 process, it MUST increase its own sequence number to avoid conflicts 618 with previously established routes. The sequence number is carried 619 in the OrigSeqNo field of the RREQ option. [minor] s/Each node maintains a sequence number...detailed operation./Each node maintains a sequence number; the operation is specified in section 7.2 of [RFC6550]. ...and take the reference to Perlman83 out. It is enough for the specification to be done once; rfc6550 already took care of it. [nit] s/OrigSeqNo/Orig SeqNo ... 632 The transmission of RREQ-DIO obeys the Trickle timer. If the 633 duration specified by the "L" bit has elapsed, the OrigNode MUST 634 leave the DODAG and stop sending RREQ-DIOs in the related 635 RPLInstance. [minor] "The transmission of RREQ-DIO obeys the Trickle timer." A reference would be nice. 637 6.2. Receiving and Forwarding RREQ messages 639 6.2.1. General Processing 641 Upon receiving a RREQ-DIO, a router which does not belong to the 642 RREQ-instance goes through the following steps: [nit] s/RREQ-instance/RREQ-Instance/g [major] What if you do belong to the instance? I'm assuming that RREQ can be sent once the DODAG is built...or would what require a difference RPLInstance? 644 Step 1: 646 If the 'S' bit in the received RREQ-DIO is set to 1, the router 647 MUST check the two directions of the link by which the RREQ-DIO is 648 received. In case that the downward (i.e. towards the TargNode) 649 direction of the link can't fulfill the requirements, the link 650 can't be used symmetrically, thus the 'S' bit of the RREQ-DIO to 651 be sent out MUST be set as 0. If the 'S' bit in the received 652 RREQ-DIO is set to 0, the router only checks into the upward 653 direction (towards the OrigNode) of the link. [major] "the router MUST check the two directions of the link" How is the link checked? [major] "If the 'S' bit...is set to 0..." The action for when the S bit is set to 1 was defined using MUST...should this action also include Normative Language? 655 If the upward direction of the link can fulfill the requirements 656 indicated in the constraint option, and the router's rank would 657 not exceed the MaxRank limit, the router joins the DODAG of the 658 RREQ-Instance. The router that transmitted the received RREQ-DIO 659 is selected as the preferred parent. Later, other RREQ-DIO 660 messages might be received. How to maintain the parent set, 661 select the preferred parent, and update the router's rank obeys 662 the core RPL and the OFs defined in ROLL WG. In case that the 663 constraint or the MaxRank limit is not fulfilled, the router MUST 664 discard the received RREQ-DIO and MUST NOT join the DODAG. [major] What is the "constraint option"? [minor] "How to maintain the parent set, select the preferred parent, and update the router's rank obeys the core RPL and the OFs defined in ROLL WG." If there's no change, then I think this sentence is not needed. If you want to keep it, then please reference specific documents and don't just point to the WG (in fact, don't point to the WG because the persistent references are documents). ... 672 Step 3: 674 If the 'H' bit is set to 1, then the router (TargNode or 675 intermediate) MUST build the upward route entry accordingly. The 676 route entry MUST include at least the following items: Source 677 Address, InstanceID, Destination Address, Next Hop, Lifetime, and 678 Sequence Number. The Destination Address and the InstanceID can 679 be respectively learned from the DODAGID and the RPLInstanceID of 680 the RREQ-DIO, and the Source Address is copied from the ART 681 Option. The next hop is the preferred parent. The lifetime is 682 set according to DODAG configuration and can be extended when the 683 route is actually used. The sequence number represents the 684 freshness of the route entry, and it is copied from the Orig SeqNo 685 field of the RREQ option. A route entry with same source and 686 destination address, same InstanceID, but stale sequence number, 687 SHOULD be deleted. [major] "...MUST build the upward route entry accordingly." I was going to ask what does "accordingly" mean, but the next sentence indicates what it has to include. Instead of having two sentences trying to specify the same thing, please collapse them into one. [minor] This route is to OrigNode, correct? Please say so. I know that it has been mentioned that the RREQ-Instance is used for that -- remind the reader. [major] "...the Source Address is copied from the ART Option." What is the "Source Address"? I ask because I assumed that it is the address used by the local router to send data to the OrigNode, but the only address in the ART Option is the "Target Prefix". What am I missing? [nit] Please be consistent in how names are used. For example, the paragraph above uses both "Next Hop" and "next hop" to refer to the same thing. [minor] "The lifetime is set according to DODAG configuration and can be extended when the route is actually used." I think that this is a little confusing, because you seem to be talking about route lifetime and not the L (which I interpreted as lifetime too) value in the RREQ Option, right? Please be specific. [nit] s/entry with same source/entry with the same source [major] "A route entry with same source and destination address, same InstanceID, but stale sequence number, SHOULD be deleted." When would it be ok to not delete the entry? IOW, why is that not a MUST? 689 If the 'H' bit is set to 0, an intermediate router MUST include 690 the address of the interface receiving the RREQ-DIO into the 691 address vector. [major] Step 3 (at least the first paragraph) seems to be about building a route entry. What is different if the H bit is set to 0? How is the route entry built? [minor] This last paragraph talks about forwarding the RREQ, so perhaps it fits better in the next step. 693 Step 4: 695 An intermediate router transmits a RREQ-DIO via link-local 696 multicast. TargNode prepares a RREP-DIO. [minor] "TargNode prepares a RREP-DIO." Please add a forward reference to =C2=A76.3. 698 6.2.2. Additional Processing for Multiple Targets 700 If the OrigNode tries to reach multiple TargNodes in a single RREQ- 701 instance, one of the TargNodes can be an intermediate router to the 702 others, therefore it SHOULD continue sending RREQ-DIO to reach other 703 targets. In this case, before rebroadcasting the RREQ-DIO, a 704 TargNode MUST delete the Target Option encapsulating its own address, 705 so that downstream routers with higher ranks do not try to create a 706 route to this TargetNode. [major] "...one of the TargNodes can be an intermediate router to the others, therefore it SHOULD continue sending RREQ-DIO to reach other targets." When would a TargNode choose not to forward the RREQ? IOW, why is that not a MUST? 708 An intermediate router could receive several RREQ-DIOs from routers 709 with lower ranks in the same RREQ-instance but have different lists 710 of Target Options. When rebroadcasting the RREQ-DIO, the 711 intersection of these lists SHOULD be included. For example, suppose 712 two RREQ-DIOs are received with the same RPLInstance and OrigNode. 713 Suppose further that the first RREQ has (T1, T2) as the targets, and 714 the second one has (T2, T4) as targets. Then only T2 needs to be 715 included in the generated RREQ-DIO. If the intersection is empty, it 716 means that all the targets have been reached, and the router SHOULD 717 NOT send out any RREQ-DIO. Any RREQ-DIO message with different ART 718 Options coming from a router with higher rank is ignored. [major] "...the intersection of these lists SHOULD be included." When would a node not include the intersection? IOW, why is this not a MUST? [major] "If the intersection is empty...the router SHOULD NOT send out any RREQ-DIO." When would it be ok to sent the RREQ out? If there are no targets, then it seems like you would never want to. IOW, why is that not a MUST NOT? [minor] I'm not sure about the intersection logic above...but maybe I'm missing something. The example seems to imply that every RREQ should include all outstanding targets (?)...so that comparing the first one (T1, T2) with the second (T2, T4), implies that T1 has been found...is that correct? If so, then it looks like T4 is still a valid target, but the intersection wouldn't include it. What am I missing? [minor] Related: The specification above only applies to the period of time between receiving the first RREQ and the initial rebroadcast, right? IOW, if a RREQ is received and rebroadcast....and then a second RREQ is received (with a different list of targets), then the rebroadcast should not include just the intersection, right? 720 6.3. Generating Route Reply (RREP) at TargNode 722 6.3.1. RREP-DIO for Symmetric route 724 If a RREQ-DIO arrives at TargNode with the 'S' bit set to 1, there is 725 a symmetric route along which both directions can fulfill the 726 requirements. Other RREQ-DIOs might later provide asymmetric upward 727 routes (i.e. S=3D0). Selection between a qualified symmetric route 728 and an asymmetric route that might have better performance is 729 implementation-specific and out of scope. If the implementation uses 730 the symmetric route, the TargNode MAY delay transmitting the RREP-DIO 731 for duration RREP_WAIT_TIME to await a better symmetric route. [major] RREP_WAIT_TIME is not defined anywhere. [major] "...a better symmetric route." What makes a route better? 733 For a symmetric route, the RREP-DIO message is unicast to the next 734 hop according to the accumulated address vector (H=3D0) or the route 735 entry (H=3D1). Thus the DODAG in RREP-Instance does not need to be 736 built. The RPLInstanceID in the RREP-Instance is paired as defined 737 in Section 6.3.3. In case the 'H' bit is set to 0, the address 738 vector received in the RREQ-DIO MUST be included in the RREP-DIO. 739 TargNode increments its current sequence number and uses the 740 incremented result in the Dest SeqNo in the ART option of the RREQ- 741 DIO. The address of the OrigNode MUST be encapsulated in the ART 742 Option and included in this RREP-DIO message. 744 6.3.2. RREP-DIO for Asymmetric Route 746 When a RREQ-DIO arrives at a TargNode with the 'S' bit set to 0, the 747 TargNode MUST build a DODAG in the RREP-Instance rooted at itself in 748 order to discover the downstream route from the OrigNode to the 749 TargNode. The RREP-DIO message MUST be re-transmitted via link-local 750 multicast until the OrigNode is reached or MaxRank is exceeded. [minor] The previous section talked about delaying the RREP. Should that be considered here too? 752 The settings of the fields in RREP option and ART option are the same 753 as for the symmetric route, except for the 'S' bit. 755 6.3.3. RPLInstanceID Pairing [minor] Pairing only applied to symmetric routes, right? Please say so. 757 Since the RPLInstanceID is assigned locally (i.e., there is no 758 coordination between routers in the assignment of RPLInstanceID), the 759 tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely 760 identify a discovered route. The upper layer applications may have 761 different requirements and they can initiate the route discoveries 762 simultaneously. Thus between the same pair of OrigNode and TargNode, 763 there can be multiple AODV-RPL instances. To avoid any mismatch, the 764 RREQ-Instance and the RREP-Instance in the same route discovery MUST 765 be paired somehow, e.g. using the RPLInstanceID. [minor] "The upper layer applications may have different requirements and they can initiate the route discoveries simultaneously." The applications don't initiate route discovery... Application requirements are mentioned several times in this document, but it is not clear to me how those requirements are reflected in the RREQ. [major] "..MUST be paired somehow, e.g. using the RPLInstanceID." There is no clear Normative action here. s/MUST/must ... 782 6.4. Receiving and Forwarding Route Reply [-] Some of the comments above apply to this section too. ... 803 If the constraints are not fulfilled, the router MUST NOT join the 804 DODAG; the router MUST discard the RREQ-DIO, and does not execute 805 the remaining steps in this section. [nit] s/and does not execute/and not execute ... 813 Step 3: 815 If the 'H' bit is set to 1, then the router (OrigNode or 816 intermediate) MUST build a downward route entry. The route entry 817 SHOULD include at least the following items: OrigNode Address, 818 InstanceID, TargNode Address as destination, Next Hop, Lifetime 819 and Sequence Number. For a symmetric route, the next hop in the 820 route entry is the router from which the RREP-DIO is received. 821 For an asymmetric route, the next hop is the preferred parent in 822 the DODAG of RREQ-Instance. The InstanceID in the route entry 823 MUST be the original RPLInstanceID (after subtracting the Shift 824 field value). The source address is learned from the ART Option, 825 and the destination address is learned from the DODAGID. The 826 lifetime is set according to DODAG configuration and can be 827 extended when the route is actually used. The sequence number 828 represents the freshness of the route entry, and is copied from 829 the Dest SeqNo field of the ART option of the RREP-DIO. A route 830 entry with same source and destination address, same InstanceID, 831 but stale sequence number, SHOULD be deleted. [major] The description in =C2=A76.2.1 says that the "route entry MUST include...". Why is SHOULD used in this case? When is it ok to not include these items? Should the same apply to =C2=A76.2.1? ... 851 7. Gratuitous RREP [minor] This section introduces T and O (instead of TargNode/OrigNode) to explain the operation. That is not a bad thing, but I think that having consistent terminology is a really good thing. ... 872 In case of hop-by-hop routing, R MUST unicast the received RREQ-DIO 873 hop-by-hop to T. The routers along the route SHOULD build new route 874 entries with the related RPLInstanceID and DODAGID in the downward 875 direction. Then T MUST unicast the RREP-DIO hop-by-hop to R, and the 876 routers along the route SHOULD build new route entries in the upward 877 direction. Upon receiving the unicast RREP-DIO, R sends the 878 gratuitous RREP-DIO to the OrigNode as defined in Section 6.3. [major] I don't understand how the "routers along the route" can do anything if the messages are unicast...?? 880 8. Operation of Trickle Timer 882 The trickle timer operation to control RREQ-Instance/RREP-Instance 883 multicast is similar to that in P2P-RPL [RFC6997]. [major] "The trickle timer operation...is similar to that in P2P-RPL [RFC6997]." Similar, or the same?? Note that if it is the same, then rfc6997 would have to be a Normative Reference. 885 9. IANA Considerations 887 9.1. New Mode of Operation: AODV-RPL 889 IANA is required to assign a new Mode of Operation, named "AODV-RPL" 890 for Point-to-Point(P2P) hop-by-hop routing under the RPL registry. 891 The value of TBD1 is assigned from the "Mode of Operation" space 892 [RFC6550]. [major] NEW> IANA is asked to assign a new Mode of Operation, named "AODV-RPL" for Point-to-Point(P2P) hop-by-hop routing from the "Mode of Operation" Registry [RFC6550]. 894 +-------------+---------------+---------------+ 895 | Value | Description | Reference | 896 +-------------+---------------+---------------+ 897 | TBD1 (5) | AODV-RPL | This document | 898 +-------------+---------------+---------------+ 900 Figure 6: Mode of Operation 902 9.2. AODV-RPL Options: RREQ, RREP, and Target 904 Three entries are required for new AODV-RPL options "RREQ", "RREP" 905 and "ART" with values of TBD2 (0x0A), TBD3 (0x0B) and TBD4 (0x0C) 906 from the "RPL Control Message Options" space [RFC6550]. [major] NEW> IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and "ART", as described in Figure 7 from the "RPL Control Message Options" Registry [RFC6550]. 908 +-------------+------------------------+---------------+ 909 | Value | Meaning | Reference | 910 +-------------+------------------------+---------------+ 911 | TBD2 (0x0A) | RREQ Option | This document | 912 +-------------+------------------------+---------------+ 913 | TBD3 (0x0B) | RREP Option | This document | 914 +-------------+------------------------+---------------+ 915 | TBD3 (0x0C) | ART Option | This document | 916 +-------------+------------------------+---------------+ 918 Figure 7: AODV-RPL Options 920 10. Security Considerations 922 The security mechanisms defined in section 10 of [RFC6550] and 923 section 11 of [RFC6997] can also be applied to the control messages 924 defined in this specification. The RREQ-DIO and RREP-DIO both have a 925 secure variant, which provide integrity and replay protection as well 926 as optional confidentiality and delay protection. [major] rfc6997/=C2=A711 mostly talks about the processing of the new messa= ges defined there. How does that apply to this document? [major] rfc6997 says that section "10 of [RFC6550] describe RPL's security framework...This security framework can also be used in P2P-RPL after taking into account the constraints specified in Section 11." How does that apply to this document if both "section 10 of [RFC6550] and section 11 of [RFC6997]" are mentioned above? [minor] =C2=A73 talks about the fact that an RREQ-DIO is a DIO message with= the rREQ Option (and there's similar text for the RREP-DIO). However, I think it's confusing to the reader to mention that there are secure variants. I think that expanding the description (at the end of =C2=A73) of what exactl= y the *-DIO messages are (and that the definition includes the secure variants) would go a long way. 928 AODV-RPL can operate in the three security modes defined in 929 [RFC6550]. AODV-RPL messages SHOULD use a security mode at least as 930 strong as the security mode used in RPL. [major] "AODV-RPL messages SHOULD use a security mode at least as strong as the security mode used in RPL." What does that mean? As I asked before, what is the relationship in the network between RPL and AODV-RPL. I have been assuming that the Options are simply included as an "add-on" to the base RPL already running, but this statement seems to imply that they are completely independent if they can have different security modes. ?? 932 o Unsecured. In this mode, RREQ-DIO and RREP-DIO are used without 933 any security fields as defined in section 6.1 of [RFC6550]. The 934 control messages can be protected by other security mechanisms, 935 e.g. link-layer security. This mode SHOULD NOT be used when RPL 936 is using Preinstalled mode or Authenticated mode (see below). [major] There is a Normative contradiction: (above) "This mode SHOULD NOT be used when RPL is using Preinstalled mode or Authenticated mode (see below)." ...and... (below) "Unsecured messages MUST be dropped." It seems to me that maybe s/SHOULD NOT/MUST NOT [major] Related: There's no indication on what should be done with unsecured messages in Authenticated mode. I'm assuming the same drop action. 938 o Preinstalled. In this mode, AODV-RPL uses secure RREQ-DIO and 939 RREP-DIO messages, and a node wishing to join a secured network 940 will have been pre-configured with a shared key. A node can use 941 that key to join the AODV-RPL DODAG as a host or a router. 942 Unsecured messages MUST be dropped. This mode SHOULD NOT be used 943 when RPL is using Authenticated mode. [major] When is it ok to use this mode with Authenticated mode? IOW, why is that not a MUST NOT? ... 961 11. Future Work [minor] This section sounds appropriate for an Experimental document and not one in the Standards Track. [major] I would expect some of the items below to be specified in a Standards Track document. For instance, "the initial state of a link" seems pretty basic. Put another way, what should be the settings (for the items mentioned here)? 963 There has been some discussion about how to determine the initial 964 state of a link after an AODV-RPL-based network has begun operation. 965 The current draft operates as if the links are symmetric until 966 additional metric information is collected. The means for making 967 link metric information is considered out of scope for AODV-RPL. In 968 the future, RREQ and RREP messages could be equipped with new fields 969 for use in verifying link metrics. In particular, it is possible to 970 identify unidirectional links; an RREQ received across a 971 unidirectional link has to be dropped, since the destination node 972 cannot make use of the received DODAG to route packets back to the 973 source node that originated the route discovery operation. This is 974 roughly the same as considering a unidirectional link to present an 975 infinite cost metric that automatically disqualifies it for use in 976 the reverse direction. [major] "The current draft operates as if the links are symmetric until additional metric information is collected." =C2=A76 mandates a check to determine the state symmetry. How is that (unspecified) check related to this text? It seems to be that it is the same thing; is it? 978 12. Contributors [minor] In general Contributors are listed list before the Author's Address at the bottom [rfc7322]. ... 1060 Appendix A. Example: ETX/RSSI Values to select S bit [minor] Please expand ETX/RSSI on first mention (=C2=A75). 1062 We have tested the combination of "RSSI(downstream)" and "ETX 1063 (upstream)" to determine whether the link is symmetric or asymmetric 1064 at the intermediate nodes. The example of how the ETX and RSSI 1065 values are used in conjuction is explained below: [style nit] Don't write in the first person ("We have..."). [minor] It would be really nice to provide a reference for these tests. [minor] Add references for ETX/RSSI. [nit] s/conjuction/conjunction ... 1083 We tested the operations in this specification by making the 1084 following experiment, using the above parameters. In our experiment= , 1085 a communication link is considered as symmetric if the ETX value of 1086 NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, within 1:3 1087 ratio. This ratio should be taken as a notional metric for deciding 1088 link symmetric/asymmetric nature, and precise definition of the rati= o 1089 is beyond the scope of the draft. In general, NodeA can only know 1090 the ETX value in the direction of NodeA -> NodeB but it has no direc= t 1091 way of knowing the value of ETX from NodeB->NodeA. Using physical 1092 testbed experiments and realistic wireless channel propagation 1093 models, one can determine a relationship between RSSI and ETX 1094 representable as an expression or a mapping table. Such a 1095 relationship in turn can be used to estimate ETX value at nodeA for 1096 link NodeB--->NodeA from the received RSSI from NodeB. Whenever 1097 nodeA determines that the link towards the nodeB is bi-directional 1098 asymmetric then the "S" bit is set to "S=3D0". Later on, the link f= rom 1099 NodeA to Destination is asymmetric with "S" bit remains to "0". [nit] s/Figure.8/Figure 8 [nit] s/within 1:3 ratio/within 1:3 a ratio [nit] s/, and precise definition of the ratio is beyond the scope of the draft./. Not needed, this is just an example. 1101 Appendix B. Changelog [nit] Add a note to the RFC Editor to remove this section before publication. --0000000000009fed5c058f0f6947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Dear authors:

I just finished = reading this document.=C2=A0 I am excited about the new functionality, but = I have several significant issues/questions about the document, and a lot o= f comments (in-line below).

(1) What is AODV-RPL?
Reading the document, my impression of AO= DV-RPL varies between an enhancement to RPL for Reactive Route Discovery (*= maybe* in addition to the usual proactive routing), to ships-in-the-night r= eactive-only protocol that uses some of the RPL concepts (but not exactly s= ure which ones).=C2=A0 The different MOP indicates that it is different fro= m "base" RPL (rfc6550), but it is not clear what the assumptions = are...and which parts are "inherited" from the "base" a= nd which ones are not used.

Another way to ask the same question is: What is the re= lationship of AODV-RPL to RPL?=C2=A0 What mechanisms are not applicable wit= h the new MOP?=C2=A0 Is it expected that an instance of RPL will also be ru= nning in the network?

Please be clear early in the document.=C2=A0 To quote Charl= ie: "AODV-RPL is a variation on RPL" [1].=C2=A0 What remains, wha= t changes, etc..


(2) Document Status (for the C= hairs/Shepherd)

I didn't find a specific discussion in the archive about the st= atus of this document.=C2=A0 Did one take place?=C2=A0 At this point I am m= ostly curious given the similarities with rfc6997 (Experimental) and the fa= ct that "Future Work" is discussed -- not typical in a Standards = Track document.=C2=A0 IOW, why is this document intended to be a Proposed S= tandard and not Experimental?


(3) Replacing rfc= 6997??

T= his document uses some of the features from rfc6997 (see some comments abou= t that in-line), which is fine.=C2=A0 The Introduction falls just short of = saying that this work replaces rfc6997.=C2=A0 Should it be considered a rep= lacement?=C2=A0 I ask mostly in the context of rfc7733 (RPL in Home and Bui= lding) which mandates (MUST) the use of rfc6997.=C2=A0 Should rfc7733 be Up= dated? =C2=A0[I'm just asking the question for it to be considered...I = am not sure of deployments which conform to rfc7733 or rfc6997...or the imp= act this would have.]


(4) Link checks

The operation o= f AODV-RPL depend on link checks (=C2=A76.2.1/=C2=A76.4) to determine symme= try and whether it can "fulfill the requirements".=C2=A0 But thes= e checks are not explained or defined anywhere (are they?) beyond an *examp= le* in the Appendix.=C2=A0 I think defining the checks is a critical part o= f the specification of the mechanism...specially for a Standards Track prot= ocol.


Pleas= e take a look at the comments below.=C2=A0 I will wait for the major points= to be addressed before starting the IETF Last Call.

Thanks!!

Alvaro.



[Line numbers from idnits.]
...
14 =C2=A0 =C2=A0 = Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)

[minor] This is not = the clearest title I've ever seen. =C2=A0 Suggestion: Reactive Route Di= scovery using RPL (AODV-RPL) =C2=A0 =C2=A0...or something like that.
<= div style=3D"margin:0px">
15 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-roll-aod= v-rpl-07

17 Abstrac= t

19 =C2=A0 Route = discovery for symmetric and asymmetric Point-to-Point (P2P)
20= =C2=A0 traffic flows is a desirable feature in Low power and Lossy= Networks
21 =C2=A0 (LLNs).=C2=A0 For that purpose, th= is document specifies a reactive P2P
22 =C2=A0 route d= iscovery mechanism for both hop-by-hop routing and source
23= =C2=A0 routing: Ad Hoc On-demand Distance Vector Routing (AODV) ba= sed RPL
24 =C2=A0 protocol.=C2=A0 Paired Instances are= used to construct directional paths,
25 =C2=A0 in cas= e some of the links between source and target node are
26 =C2=A0 asymmetric.

[minor] s/(AODV) based RPL protocol/(AODV) based RPL protoc= ol (AODV-RPL)


...
100 1.=C2= =A0 Introduction

[general comment] Avoid mentioning the "negative" of oth= er proposals and focus on why this work is needed.=C2=A0 IOW, the justifica= tion should not be "because others can't do it".

[nit] Some of the pa= ragraphs throughout the document are very long and could be split to better= convey the ideas.

102 =C2=A0 RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy
103 =C2=A0 Networks)) is a IPv6 distance vector routing = protocol designed to
104 =C2=A0 support multiple traff= ic flows through a root-based Destination-
1= 05 =C2=A0 = Oriented Directed Acyclic Graph (DODAG).=C2=A0 Typically, a router does
106 =C2=A0 not have routing information for most other ro= uters.=C2=A0 Consequently,
107 =C2=A0 for traffic betw= een routers within the DODAG (i.e., Point-to-Point
108 = =C2=A0 (P2P) traffic) data packets either have to traverse the root in non= -
109 =C2=A0 storing mode, or traverse a common ancest= or in storing mode.=C2=A0 Such
110 =C2=A0 P2P traffic = is thereby likely to traverse longer routes and may
111 =C2=A0 suffer severe congestion near the DAG root (for more information s= ee
112 =C2=A0 [RFC6997], [RFC6998]).

[nit] s/RPL[RFC6550]/RP= L [RFC6550]

[minor] s/Routing Protocol for LLNs (Low-Power and Lossy Networks)/Rout= ing Protocol for Low-Power and Lossy Networks =C2=A0 =C2=A0That's the n= ame of the protocol.

[nit] s/is a IPv6/is an IPv6
[minor] "Such P2P traffic is thereby= likely to traverse longer routes and may suffer severe congestion near the= DAG root (for more information see [RFC6997], [RFC6998])." =C2=A0I se= e that those other RFCs also make the statement that congestion is possible= , and even longer routes...but I don't see more information there.=C2= =A0 Did I miss it?=C2=A0 If not, then I don't see the value of those re= ferences at this point.

114 =C2=A0 To discover better paths for P2P traffic flows in RPL, P2P= -RPL
115 =C2=A0 [RFC6997] specifies a temporary DODAG = where the source acts as a
116 =C2=A0 temporary root.= =C2=A0 The source initiates DIOs encapsulating the P2P
117 =C2=A0 Route Discovery option (P2P-RDO) with an address vector for bot= h hop-
118 =C2=A0 by-hop mode (H=3D1) and source routi= ng mode (H=3D0).=C2=A0 Subsequently, each
11= 9 =C2=A0 i= ntermediate router adds its IP address and multicasts the P2P mode
120 =C2=A0 DIOs, until the message reaches the Target Node, wh= ich then sends the
121 =C2=A0 "Discovery Reply&qu= ot; object.=C2=A0 P2P-RPL is efficient for source routing,
122 =C2=A0 but much less efficient for hop-by-hop routing due to the = extra
123 =C2=A0 address vector overhead.=C2=A0 Howeve= r, for symmetric links, when the P2P
124 =C2=A0 mode D= IO message is being multicast from the source hop-by-hop,
125 =C2=A0 receiving nodes can infer a next hop towards the source.= =C2=A0 When the
126 =C2=A0 Target Node subsequently re= plies to the source along the established
12= 7 =C2=A0 f= orward route, receiving nodes determine the next hop towards the
128 =C2=A0 Target Node.=C2=A0 For hop-by-hop routes (H=3D1) over= symmetric links, this
129 =C2=A0 would allow efficien= t use of routing tables for P2P-RDO messages
130 =C2= =A0 instead of the "Address Vector".

[minor] Expand DIO on first use.

[minor] The= description above of P2P-RPL seems to include too much (unnecessary for th= is document) detail.=C2=A0 It also seems to propose enhancements (in the la= st couple of sentences).=C2=A0 Consider simplifying to something like this:=

=C2=A0 = =C2=A0To discover better paths for P2P traffic flows in RPL, P2P-RPL
<= div style=3D"margin:0px">=C2=A0 =C2=A0[RFC6997] specifies a temporary DODAG= where the source acts as a
=C2=A0 =C2=A0tem= porary root.=C2=A0 P2P-RPL is efficient for source routing,
=C2=A0 =C2=A0but can be much less efficient for hop-by-hop = routing due to the
=C2=A0 =C2=A0extra addres= s vector overhead.


132 =C2=A0 RPL and P2P-RPL both specif= y the use of a single DODAG in networks of
1= 33 =C2=A0 = symmetric links, where the two directions of a link MUST both satisfy
=
134 =C2=A0 the constraints of the objective function.=C2=A0= This disallows the use of
135 =C2=A0 asymmetric links= which are qualified in one direction.=C2=A0 But,
136 = =C2=A0 application-specific routing requirements as defined in IETF ROLL
137 =C2=A0 Working Group [RFC5548], [RFC5673], [RFC5826]= and [RFC5867] may be
138 =C2=A0 satisfied by routing = paths using bidirectional asymmetric links.=C2=A0 For
139 =C2=A0 this purpose, [I-D.thubert-roll-asymlink] described bidirectiona= l
140 =C2=A0 asymmetric links for RPL [RFC6550] with P= aired DODAGs, for which the
141 =C2=A0 DAG root (DOD= AGID) is common for two Instances.=C2=A0 This can satisfy
142 =C2=A0 application-specific routing requirements for bidirectiona= l
143 =C2=A0 asymmetric links in core RPL [RFC6550].= =C2=A0 Using P2P-RPL twice with
144 =C2=A0 Paired DODA= Gs, on the other hand, requires two roots: one for the
145 =C2=A0 source and another for the target node due to temporary DODAG
146 =C2=A0 formation.=C2=A0 For networks composed of bi= directional asymmetric links
147 =C2=A0 (see Section = 5), AODV-RPL specifies P2P route discovery, utilizing
148 =C2=A0 RPL with a new MoP.=C2=A0 AODV-RPL makes use of two multicast me= ssages to
149 =C2=A0 discover possibly asymmetric rout= es.=C2=A0 This provides higher route
150 =C2=A0 divers= ity and can find suitable routes that might otherwise go
151 <= /span> =C2=A0 undetected by RPL.=C2=A0 AODV-RPL eliminates the need for add= ress vector
152 =C2=A0 overhead in hop-by-hop mode.=C2= =A0 This significantly reduces the control
1= 53 =C2=A0 = packet size, which is important for Constrained LLN networks.=C2=A0 Both
154 =C2=A0 discovered routes (upward and downward) meet = the application specific
155 =C2=A0 metrics and constr= aints that are defined in the Objective Function
156 = =C2=A0 for each Instance [RFC6552].=C2=A0 On the other hand, the point-to-p= oint
157 =C2=A0 nature of routes discovered by AODV-RP= L can reduce interference near
158 =C2=A0 the root nod= es and also provide routes with fewer hops, likely
159 = =C2=A0 improving performance in the network.

[major] "RPL and P2P-RPL both sp= ecify the use of a single DODAG in networks of symmetric links, where the t= wo directions of a link MUST both satisfy the constraints of the objective = function." =C2=A0s/MUST/must =C2=A0 Because you are referring to RPL/P= 2P-RPL, the MUST is not Normative.

[minor] s/as defined in IETF ROLL Working Group = [RFC5548]/as defined in [RFC5548]

=
[minor] s/application-specific routing requiremen= ts...may be satisfied by routing paths using bidirectional asymmetric links= ./application-specific routing requirements may also be satisfied by routin= g paths using bidirectional asymmetric links. =C2=A0 =C2=A0 I found just on= e mention of anything related to asymmetry (in rfc5673)...so I think adding= "also" is important.

[minor] "For this purpose, [I-D.thubert-roll-a= symlink] described bidirectional asymmetric links for RPL [RFC6550] with Pa= ired DODAGs, for which the DAG root (DODAGID) is common for two Instances.= =C2=A0 This can satisfy application-specific routing requirements for bidir= ectional asymmetric links in core RPL [RFC6550]." =C2=A0 =C2=A0I think= that mention to this draft is unnecessary and may be confusing to readers:= the work seems to have been abandoned, and if it satisfies the requirement= s, then why do we need something else? =C2=A0;-)

[minor] I would also take out this= sentence: "Using P2P-RPL twice..."

[minor] Expand MoP on first use.=C2= =A0 BTW, rfc6550 uses MOP (not MoP), please be consistent.

[minor] "Both disc= overed routes (upward and downward) meet the application specific metrics a= nd constraints that are defined in the Objective Function for each Instance= [RFC6552]." =C2=A0 I didn't find any talk of application specific= metrics in rfc6552.


...
170 2.=C2=A0 Terminology

172 =C2=A0 The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
173 =C2=A0 "SHOULD", "SHOULD NOT", "RECOMMEN= DED", "NOT RECOMMENDED", "MAY", and
174 =C2=A0 "OPTIONAL" in this document are to be interpret= ed as described in
175 =C2=A0 [RFC2119], [RFC8174].=C2= =A0 This document uses the following terms:
=
[major] Please use the rfc8174 template= without modifications.


...
264 3.=C2=A0 Overview of AODV-RPL

[minor] It would be very nice if this overview h= ad forward references to where the behavior is specified.

266 =C2=A0 With AODV-RPL, routes = from OrigNode to TargNode within the LLN
267= =C2=A0 ne= twork are established "on-demand".=C2=A0 In other words, the rout= e
268 =C2=A0 discovery mechanism in AODV-RPL is invoke= d reactively when OrigNode
269 =C2=A0 has data for del= ivery to the TargNode but existing routes do not
270 = =C2=A0 satisfy the application's requirements.=C2=A0 The routes discove= red by
271 =C2=A0 AODV-RPL are not constrained to trav= erse a common ancestor.=C2=A0 Unlike
272 =C2=A0 RPL [R= FC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric
273 =C2=A0 communication paths in networks with bidirectional asymm= etric links.
274 =C2=A0 For this purpose, AODV-RPL ena= bles discovery of two routes: namely,
275 =C2=A0 one f= rom OrigNode to TargNode, and another from TargNode to OrigNode.
276 =C2=A0 When possible, AODV-RPL also enables symmetric route = discovery along
277 =C2=A0 Paired DODAGs (see Section = 5).

[maj= or] I get the impression that this document is an extension to RPL, to be u= sed when the existing routes don't meet specific requirements...at this= point the reactive part would kick in.=C2=A0 Is that a fair characterizati= on?

The = document jumps into talking about the extension, but it says nothing about = how the base RPL is used with it...or even if it is.=C2=A0 Please spend a p= aragraph explaining that relationship.

<= /div>
279 =C2=A0 In AODV-RPL, routes are discovered by first= forming a temporary DAG
280 =C2=A0 rooted at the Orig= Node.=C2=A0 Paired DODAGs (Instances) are constructed
281 =C2=A0 according to the AODV-RPL Mode of Operation (MoP) during route
282 =C2=A0 formation between the OrigNode and TargNode.= =C2=A0 The RREQ-Instance is
283 =C2=A0 formed by rou= te control messages from OrigNode to TargNode whereas
284 =C2=A0 the RREP-Instance is formed by route control messages from TargN= ode
285 =C2=A0 to OrigNode.=C2=A0 Intermediate router= s join the Paired DODAGs based on
286 =C2=A0 the rank = as calculated from the DIO message.=C2=A0 Henceforth in this
287 =C2=A0 document, the RREQ-DIO message means the AODV-RPL mode DI= O message
288 =C2=A0 from OrigNode to TargNode, contai= ning the RREQ option (see
289 =C2=A0 Section 4.1).=C2= =A0 Similarly, the RREP-DIO message means the AODV-RPL
290 =C2=A0 mode DIO message from TargNode to OrigNode, containing the RREP=
291 =C2=A0 option (see Section 4.2).=C2=A0 The route = discovered in the RREQ-Instance
292 =C2=A0 is used for= transmitting data from TargNode to OrigNode, and the
293 =C2=A0 route discovered in RREP-Instance is used for transmitting data = from
294 =C2=A0 OrigNode to TargNode.

[nit] s/rank/Rank/g =C2= =A0 To be consistent with how rfc6550 uses the term.

296 4.=C2=A0 AODV-RPL DIO Options

298 4.1.=C2=A0 AODV-RPL D= IO RREQ Option

300 = =C2=A0 OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO=
301 =C2=A0 message.=C2=A0 A RREQ-DIO message MUST car= ry exactly one RREQ option.

[major] What should a receiver do if more than one RREQ= options are received?

303 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 3
304 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
305 =C2=A0 =C2= =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
306 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 Type =C2=A0 =C2=A0 =C2=A0= | Option Length |S|H|X| Compr | L | =C2=A0 MaxRank =C2=A0 |
307 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
308 =C2=A0 =C2=A0 | =C2=A0Orig SeqNo = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
309 =C2=A0 =C2=A0 +-+-+-+-+-+-+= -+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
310 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
311 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
312 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Address Vector (Optional, Variable Length) =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
313 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
<= div style=3D"margin:0px">314 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
315 =C2=A0 =C2=A0 +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

317 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Figure 1: DIO RREQ option format for AODV-RPL MoP

319 =C2=A0 OrigNode supp= lies the following information in the RREQ option:

321 =C2=A0 Type
322 = =C2=A0 =C2=A0 =C2=A0The type assigned to the RREQ option (see Section 9.2).=

[major]= s/Type/Option Type/g =C2=A0 That is the name in rfc6550.

[minor] Use TBDx so tha= t it matches the IANA Considerations section.=C2=A0 The same applies to oth= er places where TBDx can be used.

=
...
348 =C2=A0 L

350 =C2=A0 =C2=A0 =C2=A02-bit= unsigned integer determining the duration that a node is
351 =C2=A0 =C2=A0 =C2=A0able to belong to the temporary DAG in RREQ-I= nstance, including
352 =C2=A0 =C2=A0 =C2=A0the OrigNod= e and the TargNode.=C2=A0 Once the time is reached, a node
353 =C2=A0 =C2=A0 =C2=A0MUST leave the DAG and stop sending or receiv= ing any more DIOs for
354 =C2=A0 =C2=A0 =C2=A0the temp= orary DODAG.=C2=A0 The definition for the "L" bit is similar to
355 =C2=A0 =C2=A0 =C2=A0that found in [RFC6997], except= that the values are adjusted to
356 =C2=A0 =C2=A0 =C2= =A0enable arbitrarily long route lifetime.
<= br>
[major] "definition for the "L= " bit is similar to that found in [RFC6997], except that..." =C2= =A0 I think that this statement may be confusing to readers...remove it.

358 =C2=A0 =C2=A0 = =C2=A0* =C2=A00x00: No time limit imposed.
3= 59 =C2=A0 = =C2=A0 =C2=A0* =C2=A00x01: 16 seconds
360 =C2=A0 =C2= =A0 =C2=A0* =C2=A00x02: 64 seconds
361 =C2=A0 =C2=A0 = =C2=A0* =C2=A00x03: 256 seconds

363 =C2=A0 =C2=A0 =C2=A0L is independent from the route lifet= ime, which is defined in the
364 =C2=A0 =C2=A0 =C2=A0= DODAG configuration option.=C2=A0 The route entries in hop-by-hop
365 =C2=A0 =C2=A0 =C2=A0routing and states of source routing ca= n still be maintained even
366 =C2=A0 =C2=A0 =C2=A0aft= er the DAG expires.

[??] I don't understand what the last sentence is trying to= say.=C2=A0 It sounds as if the information learned through the DAG can sti= ll be used after the DAG expires...up until the route lifetime expires...is= that it?=C2=A0 Please clarify.


...
373 =C2=A0 Orig SeqNo
374 =C2=A0 =C2=A0 =C2= =A0Sequence Number of OrigNode, defined similarly as in AODV
375 =C2=A0 =C2=A0 =C2=A0[RFC3561].
[major] "similarly as in AODV" = =C2=A0Similarly, or the same??=C2=A0 Note that this reference could require= rfc3561 to be a Normative Reference.

I found this text in =C2=A76.1, which defines= this field.=C2=A0 Which one is correct?=C2=A0 Suggestion: point to =C2=A76= .1.

=C2= =A0 =C2=A0Each node maintains a sequence number, which rolls over like a
=C2=A0 =C2=A0lollipop counter [Perlman83]; ref= er to section 7.2 of [RFC6550] for
=C2=A0 = =C2=A0detailed operation.=C2=A0 When the OrigNode initiates a route discove= ry
=C2=A0 =C2=A0process, it MUST increase it= s own sequence number to avoid conflicts
=C2= =A0 =C2=A0with previously established routes.=C2=A0 The sequence number is = carried
=C2=A0 =C2=A0in the OrigSeqNo field = of the RREQ option.


...
382 =C2=A0 A node MUST NOT join a RREQ instance if its own rank would equal t= o
383 =C2=A0 or higher than MaxRank.=C2=A0 Targnode ca= n join the RREQ instance at a
384 =C2=A0 rank whose in= teger portion is equal to the MaxRank.=C2=A0 A router MUST
385 =C2=A0 discard a received RREQ if the integer part of the adverti= sed rank
386 =C2=A0 equals or exceeds the MaxRank limi= t.=C2=A0 This definition of MaxRank is
387 =C2=A0 the = same as that found in [RFC6997].

<= div style=3D"margin:0px">[minor] s/own rank would equal to/own rank would b= e equal to

[nit] s/Targnode/TargNode

[minor] The second sentence sounds like it contradicts= the first one (where it says that "A node MUST NOT join..."); I = think that inverting the order would help:
<= br>
=C2=A0 =C2=A0TargNode can join the RREQ = instance at a rank whose integer portion is
= =C2=A0 =C2=A0equal to the MaxRank.=C2=A0 Other nodes MUST NOT join a RREQ i= nstance if its
=C2=A0 =C2=A0own rank is equa= l to or higher than MaxRank.


[major] "This= definition of MaxRank is the same as that found in [RFC6997]." =C2=A0= True, for the most part: the context of the definition is different.=C2=A0 = Because the definition are not exactly the same, and MaxRank is defined in = this document, please take the sentence out.=C2=A0 I don't think it add= s anything significant.


389 4.2.=C2=A0 AODV-RPL DIO RREP O= ption

39= 1 =C2=A0 T= argNode sets its IPv6 address in the DODAGID field of the RREP-DIO
392 =C2=A0 message.=C2=A0 A RREP-DIO message MUST carry exactl= y one RREP option.
393 =C2=A0 TargNode supplies the fo= llowing information in the RREP option:

=
[major] What should the receiver do if more= than one RREP option is received?


...
441 =C2=A0 Shift
442 =C2=A0 =C2=A0 =C2=A0= 6-bit unsigned integer.=C2=A0 This field is used to recover the
443 =C2=A0 =C2=A0 =C2=A0original InstanceID (see Section 6.3.3); = 0 indicates that the
444 =C2=A0 =C2=A0 =C2=A0original = InstanceID is used.

[major] s/InstanceID/RPLInstanceID/g

446 =C2=A0 Rsv
447 =C2= =A0 =C2=A0 =C2=A0MUST be initialized to zero and ignored upon reception.

[major] Do= you expect these bits to be assigned by IANA in the future?


...
456 4.3.=C2=A0 AODV-RPL DIO Target = Option

4= 58 =C2=A0 = The AODV-RPL Target (ART) Option is based on the Target Option in
459 =C2=A0 core RPL [RFC6550].=C2=A0 The Flags field is replace= d by the Destination
460 =C2=A0 Sequence Number of the= TargNode and the Prefix Length field is
461= =C2=A0 re= duced to 7 bits so that the value is limited to be no greater than
462 =C2=A0 127.

[minor] What is the name of this option: "AODV-RP= L DIO Target Option" or "AODV-RPL Target Option"?=C2=A0 Plea= se be consistent.

[??] "the Prefix Length field is reduced to 7 bits so that t= he value is limited to be no greater than 127." =C2=A0Why?=C2=A0 Is th= ere an advantage?=C2=A0 Seriously, I'm curious.

464 =C2=A0 A RREQ-DIO message MUST carry = at least one ART Option.=C2=A0 A RREP-DIO
46= 5 =C2=A0 m= essage MUST carry exactly one ART Option.
[major] What should a node do if more tha= n one ART Option is received in a RREP-DIO message?

467 =C2=A0 OrigNode can include multiple = TargNode addresses via multiple AODV-
468 =C2=A0 RPL T= arget Options in the RREQ-DIO, for routes that share the same
469 =C2=A0 constraints.=C2=A0 This reduces the cost to building onl= y one DODAG.
470 =C2=A0 Furthermore, a single Target O= ption can be used for different
471 =C2=A0 TargNode ad= dresses if they share the same prefix; in that case the
472 =C2=A0 use of the destination sequence number is not defined in this<= /div>
473 =C2=A0 document.
[major] To be clear, what are the "c= onstraints"?=C2=A0 Where are they defined/signaled?=C2=A0 Are you talk= ing about the contents of the RREQ Option (S, H, MaxRank...anything else?)?= =C2=A0 If so, please point that out explicitly; "constraints" are= mentioned in different places, but I couldn't find an explicit definit= ion.

[ma= jor] "...in that case the use of the destination sequence number is no= t defined in this document." =C2=A0 Then that means that this last fea= ture is not supported...right?=C2=A0 If that's true, then please don= 9;t mention it.


...
511 = =C2=A0 Target Prefix / Address
512 =C2=A0 =C2=A0 =C2= =A0(variable-length field) An IPv6 destination address or prefix.
513 =C2=A0 =C2=A0 =C2=A0The Prefix Length field contains the nu= mber of valid leading bits
514 =C2=A0 =C2=A0 =C2=A0in = the prefix.=C2=A0 The bits in the Target Prefix / Address field
515 =C2=A0 =C2=A0 =C2=A0after the prefix length (if any) MUST be = set to zero on
516 =C2=A0 =C2=A0 =C2=A0transmission an= d MUST be ignored on receipt.

[major] "The bits in the Target Prefix / Address= field after the prefix length (if any)..." =C2=A0 I can see how this = "is ok" because the receiver knows of these trailing bits from th= e Option Length...*but*, why even allow it?=C2=A0 Why would the Target Pref= ix / Address not simply have a length =3D Prefix Length?

BTW, I know that rfc6550 h= as the same definition.=C2=A0 That doesn't make it right.=C2=A0 Every e= xtra bit has a cost...prefixes are elided, and here extra bits are allowed.=


518 5.=C2=A0 Symmetric and Asymmetric Routes

520 =C2=A0 In Figure 4 and Fig= ure 5, BR is the Border Router, O is the OrigNode,
521 = =C2=A0 R is an intermediate router, and T is the TargNode.=C2=A0 If the RR= EQ-DIO
522 =C2=A0 arrives over an interface that is kn= own to be symmetric, and the 'S'
523= =C2=A0 bi= t is set to 1, then it remains as 1, as illustrated in Figure 4.
524 =C2=A0 If an intermediate router sends out RREQ-DIO with the= 'S' bit set to
525 =C2=A0 1, then all the one= -hop links on the route from the OrigNode O to
526 =C2= =A0 this router meet the requirements of route discovery, and the route
527 =C2=A0 can be used symmetrically.

[nit] A couple of places us= e "S bit", "'S' bit" is used above (and in most= of the document)...please be consistent. =C2=A0 Recommendation: S bit or S= -bit. =C2=A0 [BTW, please apply the same style to the other bits.]


...
552 =C2=A0 Upon receiving a RR= EQ-DIO with the 'S' bit set to 1, a node
553 = =C2=A0 determines whether this one-hop link can be used symmetrically, i.e.= ,
554 =C2=A0 both the two directions meet the requirem= ents of data transmission.
555 =C2=A0 If the RREQ-DIO = arrives over an interface that is not known to be
556 = =C2=A0 symmetric, or is known to be asymmetric, the 'S' bit is set = to 0.=C2=A0 If
557 =C2=A0 the 'S' bit arrives = already set to be '0', it is set to be '0' on
558 =C2=A0 retransmission (Figure 5).=C2=A0 Therefore, for asymmetr= ic route, there is
559 =C2=A0 at least one hop which d= oesn't fulfill the constraints in the two
560 =C2= =A0 directions.=C2=A0 Based on the 'S' bit received in RREQ-DIO, th= e TargNode
561 =C2=A0 T determines whether or not the = route is symmetric before
562 =C2=A0 transmitting the = RREP-DIO message upstream towards the OrigNode O.

[nit] s/for asymmetric route/for = an asymmetric route

564 =C2=A0 The criteria used to determine whether or not each link is sym= metric
565 =C2=A0 is beyond the scope of the document,= and may be implementation-
566 =C2=A0 specific.=C2= =A0 For instance, intermediate routers MAY use local
567 =C2=A0 information (e.g., bit rate, bandwidth, number of cells used in
568 =C2=A0 6tisch), a priori knowledge (e.g. link quali= ty according to previous
569 =C2=A0 communication) or = use averaging techniques as appropriate to the
570 =C2= =A0 application.

[major] s/MAY/may =C2=A0 This may is not Normative because there i= s no specific action (just examples).


...
=
602 6.1.=C2=A0 Route Request Generation
...
614 =C2=A0 Each node maintains a sequen= ce number, which rolls over like a
615 =C2=A0 lollipop= counter [Perlman83]; refer to section 7.2 of [RFC6550] for
616 =C2=A0 detailed operation.=C2=A0 When the OrigNode initiates a ro= ute discovery
617 =C2=A0 process, it MUST increase its= own sequence number to avoid conflicts
618<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 wit= h previously established routes.=C2=A0 The sequence number is carried
=
619 =C2=A0 in the OrigSeqNo field of the RREQ option.
=

[minor] s/Eac= h node maintains a sequence number...detailed operation./Each node maintain= s a sequence number; the operation is specified in section 7.2 of [RFC6550]= .

...and= take the reference to Perlman83 out.=C2=A0 It is enough for the specificat= ion to be done once; rfc6550 already took care of it.

[nit] s/OrigSeqNo/Orig SeqNo<= /div>


...
632 =C2=A0 The transmi= ssion of RREQ-DIO obeys the Trickle timer.=C2=A0 If the
633 =C2=A0 duration specified by the "L" bit has elapsed, the O= rigNode MUST
634 =C2=A0 leave the DODAG and stop sendi= ng RREQ-DIOs in the related
635 =C2=A0 RPLInstance.<= /div>

[minor] = "The transmission of RREQ-DIO obeys the Trickle timer." =C2=A0 A = reference would be nice.


637 6.2.=C2=A0 Receiving and Forw= arding RREQ messages

639 <= /span>6.2.1.=C2=A0 General Processing

641 =C2=A0 Upon receiving a RREQ-DIO, a router which do= es not belong to the
642 =C2=A0 RREQ-instance goes thr= ough the following steps:

[nit] s/RREQ-instance/RREQ-Instance/g

[major] What if you do belo= ng to the instance?=C2=A0 I'm assuming that RREQ can be sent once the D= ODAG is built...or would what require a difference RPLInstance?

644 =C2=A0 Step 1:

646 =C2=A0 =C2=A0 =C2=A0If t= he 'S' bit in the received RREQ-DIO is set to 1, the router
647 =C2=A0 =C2=A0 =C2=A0MUST check the two directions of the = link by which the RREQ-DIO is
648 =C2=A0 =C2=A0 =C2=A0= received.=C2=A0 In case that the downward (i.e. towards the TargNode)
=
649 =C2=A0 =C2=A0 =C2=A0direction of the link can't ful= fill the requirements, the link
650 =C2=A0 =C2=A0 =C2= =A0can't be used symmetrically, thus the 'S' bit of the RREQ-DI= O to
651 =C2=A0 =C2=A0 =C2=A0be sent out MUST be set a= s 0.=C2=A0 If the 'S' bit in the received
652 = =C2=A0 =C2=A0 =C2=A0RREQ-DIO is set to 0, the router only checks into the u= pward
653 =C2=A0 =C2=A0 =C2=A0direction (towards the O= rigNode) of the link.

[major] "the router MUST check the two directions of t= he link" =C2=A0How is the link checked?

[major] "If the 'S' bit..= .is set to 0..." =C2=A0The action for when the S bit is set to 1 was d= efined using MUST...should this action also include Normative Language?

655 =C2=A0 =C2=A0 =C2= =A0If the upward direction of the link can fulfill the requirements
656 =C2=A0 =C2=A0 =C2=A0indicated in the constraint option, a= nd the router's rank would
657 =C2=A0 =C2=A0 =C2= =A0not exceed the MaxRank limit, the router joins the DODAG of the
658 =C2=A0 =C2=A0 =C2=A0RREQ-Instance.=C2=A0 The router that t= ransmitted the received RREQ-DIO
659 =C2=A0 =C2=A0 =C2= =A0is selected as the preferred parent.=C2=A0 Later, other RREQ-DIO
660 =C2=A0 =C2=A0 =C2=A0messages might be received.=C2=A0 How= to maintain the parent set,
661 =C2=A0 =C2=A0 =C2=A0= select the preferred parent, and update the router's rank obeys
662 =C2=A0 =C2=A0 =C2=A0the core RPL and the OFs defined in R= OLL WG.=C2=A0 In case that the
663 =C2=A0 =C2=A0 =C2= =A0constraint or the MaxRank limit is not fulfilled, the router MUST
<= div style=3D"margin:0px">664 =C2=A0 =C2=A0 =C2=A0discard the received RREQ-DIO and MU= ST NOT join the DODAG.

[major] What is the "constraint option"?

[minor] "Ho= w to maintain the parent set, select the preferred parent, and update the r= outer's rank obeys the core RPL and the OFs defined in ROLL WG." = =C2=A0If there's no change, then I think this sentence is not needed.= =C2=A0 If you want to keep it, then please reference specific documents and= don't just point to the WG (in fact, don't point to the WG because= the persistent references are documents).
<= br>

...<= /div>
672 =C2=A0 Step 3:

=
674 =C2=A0 =C2=A0 =C2=A0If the 'H' bit is set= to 1, then the router (TargNode or
675 =C2=A0 =C2=A0 = =C2=A0intermediate) MUST build the upward route entry accordingly.=C2=A0 Th= e
676 =C2=A0 =C2=A0 =C2=A0route entry MUST include at = least the following items: Source
677 =C2=A0 =C2=A0 = =C2=A0Address, InstanceID, Destination Address, Next Hop, Lifetime, and
678 =C2=A0 =C2=A0 =C2=A0Sequence Number.=C2=A0 The Destin= ation Address and the InstanceID can
679 =C2=A0 =C2=A0= =C2=A0be respectively learned from the DODAGID and the RPLInstanceID of
680 =C2=A0 =C2=A0 =C2=A0the RREQ-DIO, and the Source Add= ress is copied from the ART
681 =C2=A0 =C2=A0 =C2=A0= Option.=C2=A0 The next hop is the preferred parent.=C2=A0 The lifetime is
682 =C2=A0 =C2=A0 =C2=A0set according to DODAG configur= ation and can be extended when the
683 =C2=A0 =C2=A0 = =C2=A0route is actually used.=C2=A0 The sequence number represents the
684 =C2=A0 =C2=A0 =C2=A0freshness of the route entry, and = it is copied from the Orig SeqNo
685 =C2=A0 =C2=A0 =C2= =A0field of the RREQ option.=C2=A0 A route entry with same source and
=
686 =C2=A0 =C2=A0 =C2=A0destination address, same InstanceI= D, but stale sequence number,
687 =C2=A0 =C2=A0 =C2=A0= SHOULD be deleted.

[major] "...MUST build the upward route entry accordingly.&= quot; =C2=A0I was going to ask what does "accordingly" mean, but = the next sentence indicates what it has to include.=C2=A0 Instead of having= two sentences trying to specify the same thing, please collapse them into = one.

[mi= nor] This route is to OrigNode, correct?=C2=A0 Please say so.=C2=A0 I know = that it has been mentioned that the RREQ-Instance is used for that -- remin= d the reader.

[major] "...the Source Address is copied from the ART Option.&qu= ot; =C2=A0 What is the "Source Address"?=C2=A0 I ask because I as= sumed that it is the address used by the local router to send data to the O= rigNode, but the only address in the ART Option is the "Target Prefix&= quot;.=C2=A0 What am I missing?

[nit] Please be consistent in how names are used.= =C2=A0 For example, the paragraph above uses both "Next Hop" and = "next hop" to refer to the same thing.

[minor] "The lifetime is set = according to DODAG configuration and can be extended when the route is actu= ally used." =C2=A0I think that this is a little confusing, because you= seem to be talking about route lifetime and not the L (which I interpreted= as lifetime too) value in the RREQ Option, right?=C2=A0 Please be specific= .

[nit] = s/entry with same source/entry with the same source

[major] "A route entry wit= h same source and destination address, same InstanceID, but stale sequence = number, SHOULD be deleted." =C2=A0When would it be ok to not delete th= e entry?=C2=A0 IOW, why is that not a MUST?
=
689 =C2=A0 =C2=A0 =C2=A0If the 'H' bit is= set to 0, an intermediate router MUST include
690 =C2= =A0 =C2=A0 =C2=A0the address of the interface receiving the RREQ-DIO into t= he
691 =C2=A0 =C2=A0 =C2=A0address vector.

[major] Step 3 (a= t least the first paragraph) seems to be about building a route entry.=C2= =A0 What is different if the H bit is set to 0?=C2=A0 How is the route entr= y built?

[minor] This last paragraph talks about forwarding the RREQ, so perhaps it= fits better in the next step.

693 =C2=A0 Step 4:

695 =C2=A0 =C2=A0 =C2=A0An intermediate router transmits a RR= EQ-DIO via link-local
696 =C2=A0 =C2=A0 =C2=A0multicas= t.=C2=A0 TargNode prepares a RREP-DIO.

<= /div>
[minor] "TargNode prepares a RREP-DIO.&= quot; =C2=A0Please add a forward reference to =C2=A76.3.

698 6.2.2.=C2=A0 Additional Processin= g for Multiple Targets

700 =C2=A0 If the OrigNode tries to reach multiple TargNodes in a sin= gle RREQ-
701 =C2=A0 instance, one of the TargNodes ca= n be an intermediate router to the
702 =C2=A0 others, = therefore it SHOULD continue sending RREQ-DIO to reach other
703 =C2=A0 targets.=C2=A0 In this case, before rebroadcasting the RR= EQ-DIO, a
704 =C2=A0 TargNode MUST delete the Target O= ption encapsulating its own address,
705 =C2=A0 so tha= t downstream routers with higher ranks do not try to create a
706 =C2=A0 route to this TargetNode.

[major] "...one of the TargNodes = can be an intermediate router to the others, therefore it SHOULD continue s= ending RREQ-DIO to reach other targets." =C2=A0When would a TargNode c= hoose not to forward the RREQ?=C2=A0 IOW, why is that not a MUST?

708 =C2=A0 An intermediate = router could receive several RREQ-DIOs from routers
709 =C2=A0 with lower ranks in the same RREQ-instance but have different list= s
710 =C2=A0 of Target Options.=C2=A0 When rebroadcast= ing the RREQ-DIO, the
711 =C2=A0 intersection of these= lists SHOULD be included.=C2=A0 For example, suppose
712 =C2=A0 two RREQ-DIOs are received with the same RPLInstance and OrigNod= e.
713 =C2=A0 Suppose further that the first RREQ ha= s (T1, T2) as the targets, and
714 =C2=A0 the second o= ne has (T2, T4) as targets.=C2=A0 Then only T2 needs to be
715 =C2=A0 included in the generated RREQ-DIO.=C2=A0 If the intersect= ion is empty, it
716 =C2=A0 means that all the targets= have been reached, and the router SHOULD
71= 7 =C2=A0 N= OT send out any RREQ-DIO.=C2=A0 Any RREQ-DIO message with different ART
718 =C2=A0 Options coming from a router with higher rank = is ignored.

[major] "...the intersection of these lists SHOULD be included.&qu= ot; =C2=A0When would a node not include the intersection?=C2=A0 IOW, why is= this not a MUST?

[major] "If the intersection is empty...the router SHOULD NO= T send out any RREQ-DIO." =C2=A0When would it be ok to sent the RREQ o= ut?=C2=A0 If there are no targets, then it seems like you would never want = to.=C2=A0 IOW, why is that not a MUST NOT?
<= br>
[minor] I'm not sure about the inter= section logic above...but maybe I'm missing something.=C2=A0 The exampl= e seems to imply that every RREQ should include all outstanding targets (?)= ...so that comparing the first one (T1, T2) with the second (T2, T4), impli= es that T1 has been found...is that correct?=C2=A0 If so, then it looks lik= e T4 is still a valid target, but the intersection wouldn't include it.= =C2=A0 What am I missing?

[minor] Related: =C2=A0The specification above only appli= es to the period of time between receiving the first RREQ and the initial r= ebroadcast, right?=C2=A0 IOW, if a RREQ is received and rebroadcast....and = then a second RREQ is received (with a different list of targets), then the= rebroadcast should not include just the intersection, right?

720 6.3.=C2=A0 Generating Route = Reply (RREP) at TargNode

722 6.3.1.=C2=A0 RREP-DIO for Symmetric route

724 =C2=A0 If a RREQ-DIO arrives at TargN= ode with the 'S' bit set to 1, there is
725 = =C2=A0 a symmetric route along which both directions can fulfill the
<= div style=3D"margin:0px">726 =C2=A0 requirements.=C2=A0 Other RREQ-DIOs might later p= rovide asymmetric upward
727 =C2=A0 routes (i.e.=C2=A0= S=3D0).=C2=A0 Selection between a qualified symmetric route
728 =C2=A0 and an asymmetric route that might have better performanc= e is
729 =C2=A0 implementation-specific and out of sco= pe.=C2=A0 If the implementation uses
730 =C2=A0 the sy= mmetric route, the TargNode MAY delay transmitting the RREP-DIO
731 =C2=A0 for duration RREP_WAIT_TIME to await a better symmetri= c route.

[major] RREP_WAIT_TIME is not defined anywhere.

[major] "...a better symmetri= c route." =C2=A0What makes a route better?

733 =C2=A0 For a symmetric route, the RREP-DI= O message is unicast to the next
734 =C2=A0 hop accord= ing to the accumulated address vector (H=3D0) or the route
735 =C2=A0 entry (H=3D1).=C2=A0 Thus the DODAG in RREP-Instance does = not need to be
736 =C2=A0 built.=C2=A0 The RPLInstance= ID in the RREP-Instance is paired as defined
737 =C2= =A0 in Section 6.3.3.=C2=A0 In case the 'H' bit is set to 0, the ad= dress
738 =C2=A0 vector received in the RREQ-DIO MUST = be included in the RREP-DIO.
739 =C2=A0 TargNode incr= ements its current sequence number and uses the
740 = =C2=A0 incremented result in the Dest SeqNo in the ART option of the RREQ-<= /div>
741 =C2=A0 DIO.=C2=A0 The address of the OrigNode MUST= be encapsulated in the ART
742 =C2=A0 Option and in= cluded in this RREP-DIO message.

<= div style=3D"margin:0px">744 6.3.2.=C2=A0 RREP-DIO for Asymmetric Route

746 =C2=A0 When a RREQ-DIO arriv= es at a TargNode with the 'S' bit set to 0, the
747 =C2=A0 TargNode MUST build a DODAG in the RREP-Instance rooted at its= elf in
748 =C2=A0 order to discover the downstream rou= te from the OrigNode to the
749 =C2=A0 TargNode.=C2= =A0 The RREP-DIO message MUST be re-transmitted via link-local
750 =C2=A0 multicast until the OrigNode is reached or MaxRank is e= xceeded.

[minor] The previous section talked about delaying the RREP.=C2=A0 Should = that be considered here too?

752 =C2=A0 The settings of the fields in RREP option and ART opt= ion are the same
753 =C2=A0 as for the symmetric route= , except for the 'S' bit.

=
755 6.3.3.=C2=A0 RPLInstanceID Pairing

[minor] Pairing only applied = to symmetric routes, right?=C2=A0 Please say so.

757 =C2=A0 Since the RPLInstanceID is assign= ed locally (i.e., there is no
758 =C2=A0 coordination = between routers in the assignment of RPLInstanceID), the
759 <= /span> =C2=A0 tuple (OrigNode, TargNode, RPLInstanceID) is needed to unique= ly
760 =C2=A0 identify a discovered route.=C2=A0 The= upper layer applications may have
761 =C2=A0 differen= t requirements and they can initiate the route discoveries
762 =C2=A0 simultaneously.=C2=A0 Thus between the same pair of OrigNo= de and TargNode,
763 =C2=A0 there can be multiple AODV= -RPL instances.=C2=A0 To avoid any mismatch, the
764 = =C2=A0 RREQ-Instance and the RREP-Instance in the same route discovery MUST=
765 =C2=A0 be paired somehow, e.g. using the RPLInsta= nceID.

[= minor] "The upper layer applications may have different requirements a= nd they can initiate the route discoveries simultaneously." =C2=A0The = applications don't initiate route discovery...=C2=A0 Application requir= ements are mentioned several times in this document, but it is not clear to= me how those requirements are reflected in the RREQ.

[major] "..MUST be paire= d somehow, e.g. using the RPLInstanceID." =C2=A0There is no clear Norm= ative action here. =C2=A0s/MUST/must


...
<= div style=3D"margin:0px">782 6.4.=C2=A0 Receiving and Forwarding Route Reply

[-] Some of the c= omments above apply to this section too.

...
803 =C2=A0 =C2=A0 =C2=A0If the constraints are not fulfi= lled, the router MUST NOT join the
804 =C2=A0 =C2=A0 = =C2=A0DODAG; the router MUST discard the RREQ-DIO, and does not execute
805 =C2=A0 =C2=A0 =C2=A0the remaining steps in this secti= on.

[nit= ] s/and does not execute/and not execute

...
813 =C2=A0 Step 3:

815 =C2=A0 =C2=A0 =C2=A0If the 'H' bit is set t= o 1, then the router (OrigNode or
816 =C2=A0 =C2=A0 = =C2=A0intermediate) MUST build a downward route entry.=C2=A0 The route entr= y
817 =C2=A0 =C2=A0 =C2=A0SHOULD include at least the = following items: OrigNode Address,
818 =C2=A0 =C2=A0 = =C2=A0InstanceID, TargNode Address as destination, Next Hop, Lifetime
=
819 =C2=A0 =C2=A0 =C2=A0and Sequence Number.=C2=A0 For a sy= mmetric route, the next hop in the
820 =C2=A0 =C2=A0 = =C2=A0route entry is the router from which the RREP-DIO is received.
<= div style=3D"margin:0px">821 =C2=A0 =C2=A0 =C2=A0For an asymmetric route, the next ho= p is the preferred parent in
822 =C2=A0 =C2=A0 =C2=A0= the DODAG of RREQ-Instance.=C2=A0 The InstanceID in the route entry
823 =C2=A0 =C2=A0 =C2=A0MUST be the original RPLInstanceID (a= fter subtracting the Shift
824 =C2=A0 =C2=A0 =C2=A0fie= ld value).=C2=A0 The source address is learned from the ART Option,
825 =C2=A0 =C2=A0 =C2=A0and the destination address is learne= d from the DODAGID.=C2=A0 The
826 =C2=A0 =C2=A0 =C2=A0= lifetime is set according to DODAG configuration and can be
827 =C2=A0 =C2=A0 =C2=A0extended when the route is actually used.=C2= =A0 The sequence number
828 =C2=A0 =C2=A0 =C2=A0repres= ents the freshness of the route entry, and is copied from
829 =C2=A0 =C2=A0 =C2=A0the Dest SeqNo field of the ART option of the= RREP-DIO.=C2=A0 A route
830 =C2=A0 =C2=A0 =C2=A0entry= with same source and destination address, same InstanceID,
831 =C2=A0 =C2=A0 =C2=A0but stale sequence number, SHOULD be deleted.=

[major]= The description in =C2=A76.2.1 says that the "route entry MUST includ= e...".=C2=A0 Why is SHOULD used in this case?=C2=A0 When is it ok to n= ot include these items?=C2=A0 Should the same apply to =C2=A76.2.1?


...
851 7.=C2=A0 Gratuitous RREP

[minor] T= his section introduces T and O (instead of TargNode/OrigNode) to explain th= e operation.=C2=A0 That is not a bad thing, but I think that having consist= ent terminology is a really good thing.

=

...
872 =C2=A0 In case of hop-by-hop routing, R MUST unicast = the received RREQ-DIO
873 =C2=A0 hop-by-hop to T.=C2= =A0 The routers along the route SHOULD build new route
874 =C2=A0 entries with the related RPLInstanceID and DODAGID in the downw= ard
875 =C2=A0 direction.=C2=A0 Then T MUST unicast t= he RREP-DIO hop-by-hop to R, and the
876 =C2=A0 router= s along the route SHOULD build new route entries in the upward
877 =C2=A0 direction.=C2=A0 Upon receiving the unicast RREP-DIO, R= sends the
878 =C2=A0 gratuitous RREP-DIO to the OrigN= ode as defined in Section 6.3.

[major] I don't understand how the "routers= along the route" can do anything if the messages are unicast...??

880 8.=C2=A0 Operation= of Trickle Timer

882 =C2=A0 The trickle timer operation to control RREQ-Instance/RREP-Instan= ce
883 =C2=A0 multicast is similar to that in P2P-RP= L [RFC6997].

[major] "The trickle timer operation...is similar to that in P2P-= RPL [RFC6997]." =C2=A0Similar, or the same??

Note that if it is the same, then= rfc6997 would have to be a Normative Reference.

885 9.=C2=A0 IANA Considerations

887 9.1.=C2=A0 New Mode of Oper= ation: AODV-RPL

889 =C2=A0 IANA is required to assign a new Mode of Operation, named "AO= DV-RPL"
890 =C2=A0 for Point-to-Point(P2P) hop-by= -hop routing under the RPL registry.
891 =C2=A0 The va= lue of TBD1 is assigned from the "Mode of Operation" space
<= div style=3D"margin:0px">892 =C2=A0 [RFC6550].

[major] NEW>
=C2=A0 =C2=A0IANA is asked to assign a new Mode of Operation, named "= AODV-RPL"
=C2=A0 =C2=A0for Point-to-Poi= nt(P2P) hop-by-hop routing from the "Mode of Operation"
=C2=A0 =C2=A0Registry [RFC6550].


894 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+----------= -----+---------------+
895 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Value =C2=A0 =C2=A0| =C2=A0Description = =C2=A0| =C2=A0 Reference =C2=A0 |
896 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+---------------+----------= -----+
897 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 TBD1 (5) =C2=A0| =C2=A0 AODV-RPL =C2=A0 =C2=A0| This documen= t |
898 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+-------------+---------------+---------------+

900 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 6: Mode of Operation

902 9.2.=C2=A0 AODV-R= PL Options: RREQ, RREP, and Target

904 =C2=A0 Three entries are required for new AODV-RPL opt= ions "RREQ", "RREP"
905<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 and= "ART" with values of TBD2 (0x0A), TBD3 (0x0B) and TBD4 (0x0C)
906 =C2=A0 from the "RPL Control Message Options&qu= ot; space [RFC6550].

[major] NEW>
=C2=A0 =C2=A0IA= NA is asked to assign three new AODV-RPL options "RREQ", "RR= EP" and
=C2=A0 =C2=A0"ART", a= s described in Figure 7 from the "RPL Control Message Options"
=C2=A0 =C2=A0Registry [RFC6550].

908 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0+-------------+------------------------+---------------+
909 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Value =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0Meaning =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 Reference =C2=A0 |
910 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+-------------+------------------------+---------------+
911 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TBD2 (0x0A) | =C2=A0 = =C2=A0 =C2=A0RREQ Option =C2=A0 =C2=A0 =C2=A0 | This document |
912 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+------------= ------------+---------------+
913 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0| TBD3 (0x0B) | =C2=A0 =C2=A0 =C2=A0RREP Option =C2=A0 =C2=A0= =C2=A0 | This document |
914 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+-------------+------------------------+---------------+
915 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TBD3 (0x0C) | =C2=A0 = =C2=A0 =C2=A0 ART Option =C2=A0 =C2=A0 =C2=A0 | This document |
916 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+------------= ------------+---------------+

918 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Figure 7: AODV-RPL Options

920 10.=C2=A0 Security Considerations
=

922 =C2=A0 The security= mechanisms defined in section 10 of [RFC6550] and
923 = =C2=A0 section 11 of [RFC6997] can also be applied to the control messages=
924 =C2=A0 defined in this specification.=C2=A0 The R= REQ-DIO and RREP-DIO both have a
925 =C2=A0 secure var= iant, which provide integrity and replay protection as well
926 =C2=A0 as optional confidentiality and delay protection.

[major] rfc6997/= =C2=A711 mostly talks about the processing of the new messages defined ther= e.=C2=A0 How does that apply to this document?

[major] rfc6997 says that section &q= uot;10 of [RFC6550] describe RPL's security framework...This security f= ramework can also be used in P2P-RPL after taking into account the constrai= nts specified in Section 11." =C2=A0How does that apply to this docume= nt if both "section 10 of [RFC6550] and section 11 of [RFC6997]" = are mentioned above?

[minor] =C2=A73 talks about the fact that an RREQ-DIO is a DIO= message with the rREQ Option (and there's similar text for the RREP-DI= O).=C2=A0 However, I think it's confusing to the reader to mention that= there are secure variants.=C2=A0 I think that expanding the description (a= t the end of =C2=A73) of what exactly the *-DIO messages are (and that the = definition includes the secure variants) would go a long way.

928 =C2=A0 AODV-RPL can operate= in the three security modes defined in
929<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 [RF= C6550].=C2=A0 AODV-RPL messages SHOULD use a security mode at least as
930 =C2=A0 strong as the security mode used in RPL.
<= div style=3D"margin:0px">
[major] "= AODV-RPL messages SHOULD use a security mode at least as strong as the secu= rity mode used in RPL." =C2=A0What does that mean?=C2=A0 As I asked be= fore, what is the relationship in the network between RPL and AODV-RPL.=C2= =A0 I have been assuming that the Options are simply included as an "a= dd-on" to the base RPL already running, but this statement seems to im= ply that they are completely independent if they can have different securit= y modes. =C2=A0 ??

932 =C2=A0 o =C2=A0Unsecured.=C2=A0 In this mode, RREQ-DIO and RREP-DIO ar= e used without
933 =C2=A0 =C2=A0 =C2=A0any security fi= elds as defined in section 6.1 of [RFC6550].=C2=A0 The
934 =C2=A0 =C2=A0 =C2=A0control messages can be protected by other securit= y mechanisms,
935 =C2=A0 =C2=A0 =C2=A0e.g. link-layer = security.=C2=A0 This mode SHOULD NOT be used when RPL
936 =C2=A0 =C2=A0 =C2=A0is using Preinstalled mode or Authenticated mode (s= ee below).

[major] There is a Normative contradiction: (above) "This mode SHOU= LD NOT be used when RPL is using Preinstalled mode or Authenticated mode (s= ee below)." ...and... (below) "Unsecured messages MUST be dropped= ." =C2=A0It seems to me that maybe s/SHOULD NOT/MUST NOT

[major] Related: =C2= =A0There's no indication on what should be done with unsecured messages= in Authenticated mode.=C2=A0 I'm assuming the same drop action.
<= div style=3D"margin:0px">
938 =C2=A0 o =C2=A0Prein= stalled.=C2=A0 In this mode, AODV-RPL uses secure RREQ-DIO and
939 =C2=A0 =C2=A0 =C2=A0RREP-DIO messages, and a node wishing to j= oin a secured network
940 =C2=A0 =C2=A0 =C2=A0will hav= e been pre-configured with a shared key.=C2=A0 A node can use
941 =C2=A0 =C2=A0 =C2=A0that key to join the AODV-RPL DODAG as a ho= st or a router.
942 =C2=A0 =C2=A0 =C2=A0Unsecured mess= ages MUST be dropped.=C2=A0 This mode SHOULD NOT be used
943 <= /span> =C2=A0 =C2=A0 =C2=A0when RPL is using Authenticated mode.

[major] When is it= ok to use this mode with Authenticated mode?=C2=A0 IOW, why is that not a = MUST NOT?

...
961 11.=C2=A0 Future Work

[minor] This section sounds app= ropriate for an Experimental document and not one in the Standards Track.

[major] I= would expect some of the items below to be specified in a Standards Track = document.=C2=A0 For instance, "the initial state of a link" seems= pretty basic. Put another way, what should be the settings (for the items = mentioned here)?

963 =C2=A0 There has been some discussion about how to determine the initial=
964 =C2=A0 state of a link after an AODV-RPL-based ne= twork has begun operation.
965 =C2=A0 The current draf= t operates as if the links are symmetric until
966 =C2= =A0 additional metric information is collected.=C2=A0 The means for making<= /div>
967 =C2=A0 link metric information is considered out o= f scope for AODV-RPL.=C2=A0 In
968 =C2=A0 the future, = RREQ and RREP messages could be equipped with new fields
969 <= /span> =C2=A0 for use in verifying link metrics.=C2=A0 In particular, it is= possible to
970 =C2=A0 identify unidirectional links;= an RREQ received across a
971 =C2=A0 unidirectional l= ink has to be dropped, since the destination node
972 = =C2=A0 cannot make use of the received DODAG to route packets back to the
973 =C2=A0 source node that originated the route discov= ery operation.=C2=A0 This is
974 =C2=A0 roughly the s= ame as considering a unidirectional link to present an
975 =C2=A0 infinite cost metric that automatically disqualifies it for use= in
976 =C2=A0 the reverse direction.

[major] "The curre= nt draft operates as if the links are symmetric until additional metric inf= ormation is collected." =C2=A0=C2=A76 mandates a check to determine th= e state symmetry.=C2=A0 How is that (unspecified) check related to this tex= t?=C2=A0 It seems to be that it is the same thing; is it?

978 12.=C2=A0 Contributors

[minor] In gene= ral Contributors are listed list before the Author's Address at the bot= tom [rfc7322].


...
1060 App= endix A.=C2=A0 Example: ETX/RSSI Values to select S bit

[minor] Please expand ETX/R= SSI on first mention (=C2=A75).

1062 =C2=A0 We have tested the combination of "RSSI(down= stream)" and "ETX
1063 =C2=A0 (upstream)&qu= ot; to determine whether the link is symmetric or asymmetric
1064 =C2=A0 at the intermediate nodes.=C2=A0 The example of how the = ETX and RSSI
1065 =C2=A0 values are used in conjuction= is explained below:

[style nit] Don't write in the first person ("We have= ...").

[minor] It would be really nice to provide a reference for these tests.=

[minor]= Add references for ETX/RSSI.

[nit] s/conjuction/conjunction


...
1083 =C2=A0 We tested the operations in this= specification by making the
1084 =C2=A0 following exp= eriment, using the above parameters.=C2=A0 In our experiment,
1085 =C2=A0 a communication link is considered as symmetric if the = ETX value of
1086 =C2=A0 NodeA->NodeB and NodeB->= ;NodeA (See Figure.8) are, say, within 1:3
1= 087 =C2=A0= ratio.=C2=A0 This ratio should be taken as a notional metric for deciding<= /div>
1088 =C2=A0 link symmetric/asymmetric nature, and prec= ise definition of the ratio
1089 =C2=A0 is beyond the= scope of the draft.=C2=A0 In general, NodeA can only know
1090 =C2=A0 the ETX value in the direction of NodeA -> NodeB but i= t has no direct
1091 =C2=A0 way of knowing the value o= f ETX from NodeB->NodeA.=C2=A0 Using physical
1092 = =C2=A0 testbed experiments and realistic wireless channel propagation
=
1093 =C2=A0 models, one can determine a relationship betwee= n RSSI and ETX
1094 =C2=A0 representable as an express= ion or a mapping table.=C2=A0 Such a
1095 =C2=A0 relat= ionship in turn can be used to estimate ETX value at nodeA for
1096 =C2=A0 link NodeB--->NodeA from the received RSSI from Nod= eB.=C2=A0 Whenever
1097 =C2=A0 nodeA determines that t= he link towards the nodeB is bi-directional
= 1098 =C2= =A0 asymmetric then the "S" bit is set to "S=3D0".=C2= =A0 Later on, the link from
1099 =C2=A0 NodeA to Dest= ination is asymmetric with "S" bit remains to "0".

[nit] s/Figu= re.8/Figure 8

[nit] s/within 1:3 ratio/within 1:3 a ratio

[nit] s/, and precise definition = of the ratio is beyond the scope of the draft./. =C2=A0 =C2=A0Not needed, t= his is just an example.

1101 Appendix B.=C2=A0 Changelog

[nit] Add a note to the RFC Editor to remove = this section before publication.


--0000000000009fed5c058f0f6947-- From nobody Wed Aug 7 05:09:44 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99B912001A; Wed, 7 Aug 2019 05:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsvct-amAe7h; Wed, 7 Aug 2019 05:09:34 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 650CE120018; Wed, 7 Aug 2019 05:09:34 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id d17so103348337oth.5; Wed, 07 Aug 2019 05:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5qH5wn4oQ1TQ+2rlZAmbaw7BXH/2RhouSL43c4aEnZ4=; b=m8ZKv3vecfV2PSotBRQxzzYZsA4OIqz4U/J6ZbvJ1QQts15XeUG3/cb5uHieOnxPF+ QfnHHHMs5zgQtLIDyMs5F+oUaP09ARPAJpqJjDTabcImC9oy14GGmRwU/y2fgHp3PCcn xZDOJTvkEpmYscogzE1fO4SinImf1MVmcYgDCRZydQD/uUC6eGyFGSsCKqSVRdiTFE8Z vbokEWRKNHlo27G/leo1OknF7k28med3vLJJbaZTa1OHfOznVerOn6zTo6WvTWZuAPBe LQhUF+bA/xpiiRD0uBjhsHJ3Yz8mGaYSibbZjMt2SFWwC67CdbH0kTaKfI3HAYijc910 i4tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5qH5wn4oQ1TQ+2rlZAmbaw7BXH/2RhouSL43c4aEnZ4=; b=DAuAW9dV6LTKhB/kGZzl6OVOs6s2BOER5f0As1v07fNdEvEnT2S6ZH8A9CtOJHIpuY IiSdS1fUzPvACQAX5GzXj0dXksz2GrjjZSddIHAoCAk4dNZQC31W0+VoceZl4HPp4UWf 68/RZKMG/nObL9d5fQ6vBcm52IbH+fWKCyW5JJ41zz3tWVlnUZPgirtKHQZAFvSJ67Ip xM52w+5F/mAEmaEKFsm+B3KLntlUbob20IrA4Ktgaawfg5BP71LyC9Xv0+tea4lBmqi+ uXHiptAM0s89pFr+tmK19m7RSf5/kSGRRPurFvGc5dZ2rMz7U2tV8bmlW/WqkI8cVW3D NCnQ== X-Gm-Message-State: APjAAAUm6XU/t36Q2AbDHTfmn03cLYZiAlBEpDn2rEv57t2EmrixmZ2n Kh4+eTskrVAfmo2rYLmofMPREz9lw4FDrAzqQC8= X-Google-Smtp-Source: APXvYqw3kf+ZXO+ViN16pUJMYGOUxyhQuuYAlMrqlVj8B5bduTnHlyZX2867hWcNap4KdUs22Ag/bysk+1YkYe38kB0= X-Received: by 2002:a5d:8a06:: with SMTP id w6mr9209283iod.267.1565179773112; Wed, 07 Aug 2019 05:09:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Wed, 7 Aug 2019 15:09:20 +0300 Message-ID: To: Alvaro Retana Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll , roll-chairs Content-Type: multipart/alternative; boundary="00000000000062d8a9058f85d0d0" Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 12:09:42 -0000 --00000000000062d8a9058f85d0d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Alvaro for the review, The tickets #194, #195, #196, #197, #198 were created to address the issues [1]. Related to ticket #195 (Document Status), we are going to discuss it into the ML. Best regards, Ines. [1] https://trac.ietf.org/trac/roll/report/2 On Thu, Aug 1, 2019 at 5:54 PM Alvaro Retana wrote= : > Dear authors: > > I just finished reading this document. I am excited about the new > functionality, but I have several significant issues/questions about the > document, and a lot of comments (in-line below). > > (1) What is AODV-RPL? > > Reading the document, my impression of AODV-RPL varies between an > enhancement to RPL for Reactive Route Discovery (*maybe* in addition to t= he > usual proactive routing), to ships-in-the-night reactive-only protocol th= at > uses some of the RPL concepts (but not exactly sure which ones). The > different MOP indicates that it is different from "base" RPL (rfc6550), b= ut > it is not clear what the assumptions are...and which parts are "inherited= " > from the "base" and which ones are not used. > > Another way to ask the same question is: What is the relationship of > AODV-RPL to RPL? What mechanisms are not applicable with the new MOP? I= s > it expected that an instance of RPL will also be running in the network? > > Please be clear early in the document. To quote Charlie: "AODV-RPL is a > variation on RPL" [1]. What remains, what changes, etc.. > > > (2) Document Status (for the Chairs/Shepherd) > > I didn't find a specific discussion in the archive about the status of > this document. Did one take place? At this point I am mostly curious > given the similarities with rfc6997 (Experimental) and the fact that > "Future Work" is discussed -- not typical in a Standards Track document. > IOW, why is this document intended to be a Proposed Standard and not > Experimental? > > > (3) Replacing rfc6997?? > > This document uses some of the features from rfc6997 (see some comments > about that in-line), which is fine. The Introduction falls just short of > saying that this work replaces rfc6997. Should it be considered a > replacement? I ask mostly in the context of rfc7733 (RPL in Home and > Building) which mandates (MUST) the use of rfc6997. Should rfc7733 be > Updated? [I'm just asking the question for it to be considered...I am no= t > sure of deployments which conform to rfc7733 or rfc6997...or the impact > this would have.] > > > (4) Link checks > > The operation of AODV-RPL depend on link checks (=C2=A76.2.1/=C2=A76.4) t= o determine > symmetry and whether it can "fulfill the requirements". But these checks > are not explained or defined anywhere (are they?) beyond an *example* in > the Appendix. I think defining the checks is a critical part of the > specification of the mechanism...specially for a Standards Track protocol= . > > > > Please take a look at the comments below. I will wait for the major > points to be addressed before starting the IETF Last Call. > > Thanks!! > > Alvaro. > > [1] https://mailarchive.ietf.org/arch/msg/roll/PoQQBOmWZ2XFRWVK13Q5Z4W9x-= s > > > [Line numbers from idnits.] > > ... > 14 Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) > > [minor] This is not the clearest title I've ever seen. Suggestion: > Reactive Route Discovery using RPL (AODV-RPL) ...or something like tha= t. > > 15 draft-ietf-roll-aodv-rpl-07 > > 17 Abstract > > 19 Route discovery for symmetric and asymmetric Point-to-Point (P2P) > 20 traffic flows is a desirable feature in Low power and Lossy Networks > 21 (LLNs). For that purpose, this document specifies a reactive P2P > 22 route discovery mechanism for both hop-by-hop routing and source > 23 routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL > 24 protocol. Paired Instances are used to construct directional paths, > 25 in case some of the links between source and target node are > 26 asymmetric. > > [minor] s/(AODV) based RPL protocol/(AODV) based RPL protocol (AODV-RPL) > > > ... > 100 1. Introduction > > [general comment] Avoid mentioning the "negative" of other proposals and > focus on why this work is needed. IOW, the justification should not be > "because others can't do it". > > [nit] Some of the paragraphs throughout the document are very long and > could be split to better convey the ideas. > > 102 RPL[RFC6550] (Routing Protocol for LLNs (Low-Power and Lossy > 103 Networks)) is a IPv6 distance vector routing protocol designed to > 104 support multiple traffic flows through a root-based Destination- > 105 Oriented Directed Acyclic Graph (DODAG). Typically, a router does > 106 not have routing information for most other routers. Consequently, > 107 for traffic between routers within the DODAG (i.e., Point-to-Point > 108 (P2P) traffic) data packets either have to traverse the root in non= - > 109 storing mode, or traverse a common ancestor in storing mode. Such > 110 P2P traffic is thereby likely to traverse longer routes and may > 111 suffer severe congestion near the DAG root (for more information se= e > 112 [RFC6997], [RFC6998]). > > [nit] s/RPL[RFC6550]/RPL [RFC6550] > > [minor] s/Routing Protocol for LLNs (Low-Power and Lossy Networks)/Routin= g > Protocol for Low-Power and Lossy Networks That's the name of the > protocol. > > [nit] s/is a IPv6/is an IPv6 > > [minor] "Such P2P traffic is thereby likely to traverse longer routes and > may suffer severe congestion near the DAG root (for more information see > [RFC6997], [RFC6998])." I see that those other RFCs also make the > statement that congestion is possible, and even longer routes...but I don= 't > see more information there. Did I miss it? If not, then I don't see the > value of those references at this point. > > 114 To discover better paths for P2P traffic flows in RPL, P2P-RPL > 115 [RFC6997] specifies a temporary DODAG where the source acts as a > 116 temporary root. The source initiates DIOs encapsulating the P2P > 117 Route Discovery option (P2P-RDO) with an address vector for both > hop- > 118 by-hop mode (H=3D1) and source routing mode (H=3D0). Subsequently,= each > 119 intermediate router adds its IP address and multicasts the P2P mode > 120 DIOs, until the message reaches the Target Node, which then sends > the > 121 "Discovery Reply" object. P2P-RPL is efficient for source routing, > 122 but much less efficient for hop-by-hop routing due to the extra > 123 address vector overhead. However, for symmetric links, when the P2= P > 124 mode DIO message is being multicast from the source hop-by-hop, > 125 receiving nodes can infer a next hop towards the source. When the > 126 Target Node subsequently replies to the source along the establishe= d > 127 forward route, receiving nodes determine the next hop towards the > 128 Target Node. For hop-by-hop routes (H=3D1) over symmetric links, t= his > 129 would allow efficient use of routing tables for P2P-RDO messages > 130 instead of the "Address Vector". > > [minor] Expand DIO on first use. > > [minor] The description above of P2P-RPL seems to include too much > (unnecessary for this document) detail. It also seems to propose > enhancements (in the last couple of sentences). Consider simplifying to > something like this: > > To discover better paths for P2P traffic flows in RPL, P2P-RPL > [RFC6997] specifies a temporary DODAG where the source acts as a > temporary root. P2P-RPL is efficient for source routing, > but can be much less efficient for hop-by-hop routing due to the > extra address vector overhead. > > > 132 RPL and P2P-RPL both specify the use of a single DODAG in networks > of > 133 symmetric links, where the two directions of a link MUST both > satisfy > 134 the constraints of the objective function. This disallows the use > of > 135 asymmetric links which are qualified in one direction. But, > 136 application-specific routing requirements as defined in IETF ROLL > 137 Working Group [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may be > 138 satisfied by routing paths using bidirectional asymmetric links. > For > 139 this purpose, [I-D.thubert-roll-asymlink] described bidirectional > 140 asymmetric links for RPL [RFC6550] with Paired DODAGs, for which th= e > 141 DAG root (DODAGID) is common for two Instances. This can satisfy > 142 application-specific routing requirements for bidirectional > 143 asymmetric links in core RPL [RFC6550]. Using P2P-RPL twice with > 144 Paired DODAGs, on the other hand, requires two roots: one for the > 145 source and another for the target node due to temporary DODAG > 146 formation. For networks composed of bidirectional asymmetric links > 147 (see Section 5), AODV-RPL specifies P2P route discovery, utilizing > 148 RPL with a new MoP. AODV-RPL makes use of two multicast messages t= o > 149 discover possibly asymmetric routes. This provides higher route > 150 diversity and can find suitable routes that might otherwise go > 151 undetected by RPL. AODV-RPL eliminates the need for address vector > 152 overhead in hop-by-hop mode. This significantly reduces the contro= l > 153 packet size, which is important for Constrained LLN networks. Both > 154 discovered routes (upward and downward) meet the application > specific > 155 metrics and constraints that are defined in the Objective Function > 156 for each Instance [RFC6552]. On the other hand, the point-to-point > 157 nature of routes discovered by AODV-RPL can reduce interference nea= r > 158 the root nodes and also provide routes with fewer hops, likely > 159 improving performance in the network. > > [major] "RPL and P2P-RPL both specify the use of a single DODAG in > networks of symmetric links, where the two directions of a link MUST both > satisfy the constraints of the objective function." s/MUST/must Becaus= e > you are referring to RPL/P2P-RPL, the MUST is not Normative. > > [minor] s/as defined in IETF ROLL Working Group [RFC5548]/as defined in > [RFC5548] > > [minor] s/application-specific routing requirements...may be satisfied by > routing paths using bidirectional asymmetric links./application-specific > routing requirements may also be satisfied by routing paths using > bidirectional asymmetric links. I found just one mention of anything > related to asymmetry (in rfc5673)...so I think adding "also" is important= . > > [minor] "For this purpose, [I-D.thubert-roll-asymlink] described > bidirectional asymmetric links for RPL [RFC6550] with Paired DODAGs, for > which the DAG root (DODAGID) is common for two Instances. This can satis= fy > application-specific routing requirements for bidirectional asymmetric > links in core RPL [RFC6550]." I think that mention to this draft is > unnecessary and may be confusing to readers: the work seems to have been > abandoned, and if it satisfies the requirements, then why do we need > something else? ;-) > > [minor] I would also take out this sentence: "Using P2P-RPL twice..." > > [minor] Expand MoP on first use. BTW, rfc6550 uses MOP (not MoP), please > be consistent. > > [minor] "Both discovered routes (upward and downward) meet the applicatio= n > specific metrics and constraints that are defined in the Objective Functi= on > for each Instance [RFC6552]." I didn't find any talk of application > specific metrics in rfc6552. > > > ... > 170 2. Terminology > > 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", an= d > 174 "OPTIONAL" in this document are to be interpreted as described in > 175 [RFC2119], [RFC8174]. This document uses the following terms: > > [major] Please use the rfc8174 template without modifications. > > > ... > 264 3. Overview of AODV-RPL > > [minor] It would be very nice if this overview had forward references to > where the behavior is specified. > > 266 With AODV-RPL, routes from OrigNode to TargNode within the LLN > 267 network are established "on-demand". In other words, the route > 268 discovery mechanism in AODV-RPL is invoked reactively when OrigNode > 269 has data for delivery to the TargNode but existing routes do not > 270 satisfy the application's requirements. The routes discovered by > 271 AODV-RPL are not constrained to traverse a common ancestor. Unlike > 272 RPL [RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric > 273 communication paths in networks with bidirectional asymmetric links= . > 274 For this purpose, AODV-RPL enables discovery of two routes: namely, > 275 one from OrigNode to TargNode, and another from TargNode to > OrigNode. > 276 When possible, AODV-RPL also enables symmetric route discovery alon= g > 277 Paired DODAGs (see Section 5). > > [major] I get the impression that this document is an extension to RPL, t= o > be used when the existing routes don't meet specific requirements...at th= is > point the reactive part would kick in. Is that a fair characterization? > > The document jumps into talking about the extension, but it says nothing > about how the base RPL is used with it...or even if it is. Please spend = a > paragraph explaining that relationship. > > 279 In AODV-RPL, routes are discovered by first forming a temporary DAG > 280 rooted at the OrigNode. Paired DODAGs (Instances) are constructed > 281 according to the AODV-RPL Mode of Operation (MoP) during route > 282 formation between the OrigNode and TargNode. The RREQ-Instance is > 283 formed by route control messages from OrigNode to TargNode whereas > 284 the RREP-Instance is formed by route control messages from TargNode > 285 to OrigNode. Intermediate routers join the Paired DODAGs based on > 286 the rank as calculated from the DIO message. Henceforth in this > 287 document, the RREQ-DIO message means the AODV-RPL mode DIO message > 288 from OrigNode to TargNode, containing the RREQ option (see > 289 Section 4.1). Similarly, the RREP-DIO message means the AODV-RPL > 290 mode DIO message from TargNode to OrigNode, containing the RREP > 291 option (see Section 4.2). The route discovered in the RREQ-Instanc= e > 292 is used for transmitting data from TargNode to OrigNode, and the > 293 route discovered in RREP-Instance is used for transmitting data fro= m > 294 OrigNode to TargNode. > > [nit] s/rank/Rank/g To be consistent with how rfc6550 uses the term. > > 296 4. AODV-RPL DIO Options > > 298 4.1. AODV-RPL DIO RREQ Option > > 300 OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO > 301 message. A RREQ-DIO message MUST carry exactly one RREQ option. > > [major] What should a receiver do if more than one RREQ options are > received? > > 303 0 1 2 3 > 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 306 | Type | Option Length |S|H|X| Compr | L | MaxRank | > 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 308 | Orig SeqNo | | > 309 +-+-+-+-+-+-+-+-+ | > 310 | | > 311 | | > 312 | Address Vector (Optional, Variable Length) | > 313 | | > 314 | | > 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 317 Figure 1: DIO RREQ option format for AODV-RPL MoP > > 319 OrigNode supplies the following information in the RREQ option: > > 321 Type > 322 The type assigned to the RREQ option (see Section 9.2). > > [major] s/Type/Option Type/g That is the name in rfc6550. > > [minor] Use TBDx so that it matches the IANA Considerations section. The > same applies to other places where TBDx can be used. > > ... > 348 L > > 350 2-bit unsigned integer determining the duration that a node is > 351 able to belong to the temporary DAG in RREQ-Instance, including > 352 the OrigNode and the TargNode. Once the time is reached, a node > 353 MUST leave the DAG and stop sending or receiving any more DIOs > for > 354 the temporary DODAG. The definition for the "L" bit is similar > to > 355 that found in [RFC6997], except that the values are adjusted to > 356 enable arbitrarily long route lifetime. > > [major] "definition for the "L" bit is similar to that found in [RFC6997]= , > except that..." I think that this statement may be confusing to > readers...remove it. > > 358 * 0x00: No time limit imposed. > 359 * 0x01: 16 seconds > 360 * 0x02: 64 seconds > 361 * 0x03: 256 seconds > > 363 L is independent from the route lifetime, which is defined in th= e > 364 DODAG configuration option. The route entries in hop-by-hop > 365 routing and states of source routing can still be maintained eve= n > 366 after the DAG expires. > > [??] I don't understand what the last sentence is trying to say. It > sounds as if the information learned through the DAG can still be used > after the DAG expires...up until the route lifetime expires...is that it? > Please clarify. > > > ... > 373 Orig SeqNo > 374 Sequence Number of OrigNode, defined similarly as in AODV > 375 [RFC3561]. > > [major] "similarly as in AODV" Similarly, or the same?? Note that this > reference could require rfc3561 to be a Normative Reference. > > I found this text in =C2=A76.1, which defines this field. Which one is > correct? Suggestion: point to =C2=A76.1. > > Each node maintains a sequence number, which rolls over like a > lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for > detailed operation. When the OrigNode initiates a route discovery > process, it MUST increase its own sequence number to avoid conflicts > with previously established routes. The sequence number is carried > in the OrigSeqNo field of the RREQ option. > > > ... > 382 A node MUST NOT join a RREQ instance if its own rank would equal to > 383 or higher than MaxRank. Targnode can join the RREQ instance at a > 384 rank whose integer portion is equal to the MaxRank. A router MUST > 385 discard a received RREQ if the integer part of the advertised rank > 386 equals or exceeds the MaxRank limit. This definition of MaxRank is > 387 the same as that found in [RFC6997]. > > [minor] s/own rank would equal to/own rank would be equal to > > [nit] s/Targnode/TargNode > > [minor] The second sentence sounds like it contradicts the first one > (where it says that "A node MUST NOT join..."); I think that inverting th= e > order would help: > > TargNode can join the RREQ instance at a rank whose integer portion is > equal to the MaxRank. Other nodes MUST NOT join a RREQ instance if it= s > own rank is equal to or higher than MaxRank. > > > [major] "This definition of MaxRank is the same as that found in > [RFC6997]." True, for the most part: the context of the definition is > different. Because the definition are not exactly the same, and MaxRank = is > defined in this document, please take the sentence out. I don't think it > adds anything significant. > > > 389 4.2. AODV-RPL DIO RREP Option > > 391 TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO > 392 message. A RREP-DIO message MUST carry exactly one RREP option. > 393 TargNode supplies the following information in the RREP option: > > [major] What should the receiver do if more than one RREP option is > received? > > > ... > 441 Shift > 442 6-bit unsigned integer. This field is used to recover the > 443 original InstanceID (see Section 6.3.3); 0 indicates that the > 444 original InstanceID is used. > > [major] s/InstanceID/RPLInstanceID/g > > 446 Rsv > 447 MUST be initialized to zero and ignored upon reception. > > [major] Do you expect these bits to be assigned by IANA in the future? > > > ... > 456 4.3. AODV-RPL DIO Target Option > > 458 The AODV-RPL Target (ART) Option is based on the Target Option in > 459 core RPL [RFC6550]. The Flags field is replaced by the Destination > 460 Sequence Number of the TargNode and the Prefix Length field is > 461 reduced to 7 bits so that the value is limited to be no greater tha= n > 462 127. > > [minor] What is the name of this option: "AODV-RPL DIO Target Option" or > "AODV-RPL Target Option"? Please be consistent. > > [??] "the Prefix Length field is reduced to 7 bits so that the value is > limited to be no greater than 127." Why? Is there an advantage? > Seriously, I'm curious. > > 464 A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO > 465 message MUST carry exactly one ART Option. > > [major] What should a node do if more than one ART Option is received in = a > RREP-DIO message? > > 467 OrigNode can include multiple TargNode addresses via multiple AODV- > 468 RPL Target Options in the RREQ-DIO, for routes that share the same > 469 constraints. This reduces the cost to building only one DODAG. > 470 Furthermore, a single Target Option can be used for different > 471 TargNode addresses if they share the same prefix; in that case the > 472 use of the destination sequence number is not defined in this > 473 document. > > [major] To be clear, what are the "constraints"? Where are they > defined/signaled? Are you talking about the contents of the RREQ Option > (S, H, MaxRank...anything else?)? If so, please point that out explicitl= y; > "constraints" are mentioned in different places, but I couldn't find an > explicit definition. > > [major] "...in that case the use of the destination sequence number is no= t > defined in this document." Then that means that this last feature is no= t > supported...right? If that's true, then please don't mention it. > > > ... > 511 Target Prefix / Address > 512 (variable-length field) An IPv6 destination address or prefix. > 513 The Prefix Length field contains the number of valid leading bit= s > 514 in the prefix. The bits in the Target Prefix / Address field > 515 after the prefix length (if any) MUST be set to zero on > 516 transmission and MUST be ignored on receipt. > > [major] "The bits in the Target Prefix / Address field after the prefix > length (if any)..." I can see how this "is ok" because the receiver kno= ws > of these trailing bits from the Option Length...*but*, why even allow it? > Why would the Target Prefix / Address not simply have a length =3D Prefix > Length? > > BTW, I know that rfc6550 has the same definition. That doesn't make it > right. Every extra bit has a cost...prefixes are elided, and here extra > bits are allowed. > > > 518 5. Symmetric and Asymmetric Routes > > 520 In Figure 4 and Figure 5, BR is the Border Router, O is the > OrigNode, > 521 R is an intermediate router, and T is the TargNode. If the RREQ-DI= O > 522 arrives over an interface that is known to be symmetric, and the 'S= ' > 523 bit is set to 1, then it remains as 1, as illustrated in Figure 4. > 524 If an intermediate router sends out RREQ-DIO with the 'S' bit set t= o > 525 1, then all the one-hop links on the route from the OrigNode O to > 526 this router meet the requirements of route discovery, and the route > 527 can be used symmetrically. > > [nit] A couple of places use "S bit", "'S' bit" is used above (and in mos= t > of the document)...please be consistent. Recommendation: S bit or S-bit= . > [BTW, please apply the same style to the other bits.] > > > ... > 552 Upon receiving a RREQ-DIO with the 'S' bit set to 1, a node > 553 determines whether this one-hop link can be used symmetrically, > i.e., > 554 both the two directions meet the requirements of data transmission. > 555 If the RREQ-DIO arrives over an interface that is not known to be > 556 symmetric, or is known to be asymmetric, the 'S' bit is set to 0. > If > 557 the 'S' bit arrives already set to be '0', it is set to be '0' on > 558 retransmission (Figure 5). Therefore, for asymmetric route, there > is > 559 at least one hop which doesn't fulfill the constraints in the two > 560 directions. Based on the 'S' bit received in RREQ-DIO, the TargNod= e > 561 T determines whether or not the route is symmetric before > 562 transmitting the RREP-DIO message upstream towards the OrigNode O. > > [nit] s/for asymmetric route/for an asymmetric route > > 564 The criteria used to determine whether or not each link is symmetri= c > 565 is beyond the scope of the document, and may be implementation- > 566 specific. For instance, intermediate routers MAY use local > 567 information (e.g., bit rate, bandwidth, number of cells used in > 568 6tisch), a priori knowledge (e.g. link quality according to previou= s > 569 communication) or use averaging techniques as appropriate to the > 570 application. > > [major] s/MAY/may This may is not Normative because there is no specifi= c > action (just examples). > > > ... > 602 6.1. Route Request Generation > ... > 614 Each node maintains a sequence number, which rolls over like a > 615 lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] for > 616 detailed operation. When the OrigNode initiates a route discovery > 617 process, it MUST increase its own sequence number to avoid conflict= s > 618 with previously established routes. The sequence number is carried > 619 in the OrigSeqNo field of the RREQ option. > > [minor] s/Each node maintains a sequence number...detailed operation./Eac= h > node maintains a sequence number; the operation is specified in section 7= .2 > of [RFC6550]. > > ...and take the reference to Perlman83 out. It is enough for the > specification to be done once; rfc6550 already took care of it. > > [nit] s/OrigSeqNo/Orig SeqNo > > > ... > 632 The transmission of RREQ-DIO obeys the Trickle timer. If the > 633 duration specified by the "L" bit has elapsed, the OrigNode MUST > 634 leave the DODAG and stop sending RREQ-DIOs in the related > 635 RPLInstance. > > [minor] "The transmission of RREQ-DIO obeys the Trickle timer." A > reference would be nice. > > > 637 6.2. Receiving and Forwarding RREQ messages > > 639 6.2.1. General Processing > > 641 Upon receiving a RREQ-DIO, a router which does not belong to the > 642 RREQ-instance goes through the following steps: > > [nit] s/RREQ-instance/RREQ-Instance/g > > [major] What if you do belong to the instance? I'm assuming that RREQ ca= n > be sent once the DODAG is built...or would what require a difference > RPLInstance? > > 644 Step 1: > > 646 If the 'S' bit in the received RREQ-DIO is set to 1, the router > 647 MUST check the two directions of the link by which the RREQ-DIO > is > 648 received. In case that the downward (i.e. towards the TargNode) > 649 direction of the link can't fulfill the requirements, the link > 650 can't be used symmetrically, thus the 'S' bit of the RREQ-DIO to > 651 be sent out MUST be set as 0. If the 'S' bit in the received > 652 RREQ-DIO is set to 0, the router only checks into the upward > 653 direction (towards the OrigNode) of the link. > > [major] "the router MUST check the two directions of the link" How is th= e > link checked? > > [major] "If the 'S' bit...is set to 0..." The action for when the S bit > is set to 1 was defined using MUST...should this action also include > Normative Language? > > 655 If the upward direction of the link can fulfill the requirements > 656 indicated in the constraint option, and the router's rank would > 657 not exceed the MaxRank limit, the router joins the DODAG of the > 658 RREQ-Instance. The router that transmitted the received RREQ-DI= O > 659 is selected as the preferred parent. Later, other RREQ-DIO > 660 messages might be received. How to maintain the parent set, > 661 select the preferred parent, and update the router's rank obeys > 662 the core RPL and the OFs defined in ROLL WG. In case that the > 663 constraint or the MaxRank limit is not fulfilled, the router MUS= T > 664 discard the received RREQ-DIO and MUST NOT join the DODAG. > > [major] What is the "constraint option"? > > [minor] "How to maintain the parent set, select the preferred parent, and > update the router's rank obeys the core RPL and the OFs defined in ROLL > WG." If there's no change, then I think this sentence is not needed. If > you want to keep it, then please reference specific documents and don't > just point to the WG (in fact, don't point to the WG because the persiste= nt > references are documents). > > > ... > 672 Step 3: > > 674 If the 'H' bit is set to 1, then the router (TargNode or > 675 intermediate) MUST build the upward route entry accordingly. Th= e > 676 route entry MUST include at least the following items: Source > 677 Address, InstanceID, Destination Address, Next Hop, Lifetime, an= d > 678 Sequence Number. The Destination Address and the InstanceID can > 679 be respectively learned from the DODAGID and the RPLInstanceID o= f > 680 the RREQ-DIO, and the Source Address is copied from the ART > 681 Option. The next hop is the preferred parent. The lifetime is > 682 set according to DODAG configuration and can be extended when th= e > 683 route is actually used. The sequence number represents the > 684 freshness of the route entry, and it is copied from the Orig > SeqNo > 685 field of the RREQ option. A route entry with same source and > 686 destination address, same InstanceID, but stale sequence number, > 687 SHOULD be deleted. > > [major] "...MUST build the upward route entry accordingly." I was going > to ask what does "accordingly" mean, but the next sentence indicates what > it has to include. Instead of having two sentences trying to specify the > same thing, please collapse them into one. > > [minor] This route is to OrigNode, correct? Please say so. I know that > it has been mentioned that the RREQ-Instance is used for that -- remind t= he > reader. > > [major] "...the Source Address is copied from the ART Option." What is > the "Source Address"? I ask because I assumed that it is the address use= d > by the local router to send data to the OrigNode, but the only address in > the ART Option is the "Target Prefix". What am I missing? > > [nit] Please be consistent in how names are used. For example, the > paragraph above uses both "Next Hop" and "next hop" to refer to the same > thing. > > [minor] "The lifetime is set according to DODAG configuration and can be > extended when the route is actually used." I think that this is a little > confusing, because you seem to be talking about route lifetime and not th= e > L (which I interpreted as lifetime too) value in the RREQ Option, right? > Please be specific. > > [nit] s/entry with same source/entry with the same source > > [major] "A route entry with same source and destination address, same > InstanceID, but stale sequence number, SHOULD be deleted." When would it > be ok to not delete the entry? IOW, why is that not a MUST? > > 689 If the 'H' bit is set to 0, an intermediate router MUST include > 690 the address of the interface receiving the RREQ-DIO into the > 691 address vector. > > [major] Step 3 (at least the first paragraph) seems to be about building = a > route entry. What is different if the H bit is set to 0? How is the rou= te > entry built? > > [minor] This last paragraph talks about forwarding the RREQ, so perhaps i= t > fits better in the next step. > > 693 Step 4: > > 695 An intermediate router transmits a RREQ-DIO via link-local > 696 multicast. TargNode prepares a RREP-DIO. > > [minor] "TargNode prepares a RREP-DIO." Please add a forward reference t= o > =C2=A76.3. > > 698 6.2.2. Additional Processing for Multiple Targets > > 700 If the OrigNode tries to reach multiple TargNodes in a single RREQ- > 701 instance, one of the TargNodes can be an intermediate router to the > 702 others, therefore it SHOULD continue sending RREQ-DIO to reach othe= r > 703 targets. In this case, before rebroadcasting the RREQ-DIO, a > 704 TargNode MUST delete the Target Option encapsulating its own > address, > 705 so that downstream routers with higher ranks do not try to create a > 706 route to this TargetNode. > > [major] "...one of the TargNodes can be an intermediate router to the > others, therefore it SHOULD continue sending RREQ-DIO to reach other > targets." When would a TargNode choose not to forward the RREQ? IOW, wh= y > is that not a MUST? > > 708 An intermediate router could receive several RREQ-DIOs from routers > 709 with lower ranks in the same RREQ-instance but have different lists > 710 of Target Options. When rebroadcasting the RREQ-DIO, the > 711 intersection of these lists SHOULD be included. For example, > suppose > 712 two RREQ-DIOs are received with the same RPLInstance and OrigNode. > 713 Suppose further that the first RREQ has (T1, T2) as the targets, an= d > 714 the second one has (T2, T4) as targets. Then only T2 needs to be > 715 included in the generated RREQ-DIO. If the intersection is empty, > it > 716 means that all the targets have been reached, and the router SHOULD > 717 NOT send out any RREQ-DIO. Any RREQ-DIO message with different ART > 718 Options coming from a router with higher rank is ignored. > > [major] "...the intersection of these lists SHOULD be included." When > would a node not include the intersection? IOW, why is this not a MUST? > > [major] "If the intersection is empty...the router SHOULD NOT send out an= y > RREQ-DIO." When would it be ok to sent the RREQ out? If there are no > targets, then it seems like you would never want to. IOW, why is that no= t > a MUST NOT? > > [minor] I'm not sure about the intersection logic above...but maybe I'm > missing something. The example seems to imply that every RREQ should > include all outstanding targets (?)...so that comparing the first one (T1= , > T2) with the second (T2, T4), implies that T1 has been found...is that > correct? If so, then it looks like T4 is still a valid target, but the > intersection wouldn't include it. What am I missing? > > [minor] Related: The specification above only applies to the period of > time between receiving the first RREQ and the initial rebroadcast, right? > IOW, if a RREQ is received and rebroadcast....and then a second RREQ is > received (with a different list of targets), then the rebroadcast should > not include just the intersection, right? > > 720 6.3. Generating Route Reply (RREP) at TargNode > > 722 6.3.1. RREP-DIO for Symmetric route > > 724 If a RREQ-DIO arrives at TargNode with the 'S' bit set to 1, there > is > 725 a symmetric route along which both directions can fulfill the > 726 requirements. Other RREQ-DIOs might later provide asymmetric upwar= d > 727 routes (i.e. S=3D0). Selection between a qualified symmetric rout= e > 728 and an asymmetric route that might have better performance is > 729 implementation-specific and out of scope. If the implementation > uses > 730 the symmetric route, the TargNode MAY delay transmitting the > RREP-DIO > 731 for duration RREP_WAIT_TIME to await a better symmetric route. > > [major] RREP_WAIT_TIME is not defined anywhere. > > [major] "...a better symmetric route." What makes a route better? > > 733 For a symmetric route, the RREP-DIO message is unicast to the next > 734 hop according to the accumulated address vector (H=3D0) or the rout= e > 735 entry (H=3D1). Thus the DODAG in RREP-Instance does not need to be > 736 built. The RPLInstanceID in the RREP-Instance is paired as defined > 737 in Section 6.3.3. In case the 'H' bit is set to 0, the address > 738 vector received in the RREQ-DIO MUST be included in the RREP-DIO. > 739 TargNode increments its current sequence number and uses the > 740 incremented result in the Dest SeqNo in the ART option of the RREQ- > 741 DIO. The address of the OrigNode MUST be encapsulated in the ART > 742 Option and included in this RREP-DIO message. > > 744 6.3.2. RREP-DIO for Asymmetric Route > > 746 When a RREQ-DIO arrives at a TargNode with the 'S' bit set to 0, th= e > 747 TargNode MUST build a DODAG in the RREP-Instance rooted at itself i= n > 748 order to discover the downstream route from the OrigNode to the > 749 TargNode. The RREP-DIO message MUST be re-transmitted via > link-local > 750 multicast until the OrigNode is reached or MaxRank is exceeded. > > [minor] The previous section talked about delaying the RREP. Should that > be considered here too? > > 752 The settings of the fields in RREP option and ART option are the > same > 753 as for the symmetric route, except for the 'S' bit. > > 755 6.3.3. RPLInstanceID Pairing > > [minor] Pairing only applied to symmetric routes, right? Please say so. > > 757 Since the RPLInstanceID is assigned locally (i.e., there is no > 758 coordination between routers in the assignment of RPLInstanceID), > the > 759 tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely > 760 identify a discovered route. The upper layer applications may have > 761 different requirements and they can initiate the route discoveries > 762 simultaneously. Thus between the same pair of OrigNode and > TargNode, > 763 there can be multiple AODV-RPL instances. To avoid any mismatch, > the > 764 RREQ-Instance and the RREP-Instance in the same route discovery MUS= T > 765 be paired somehow, e.g. using the RPLInstanceID. > > [minor] "The upper layer applications may have different requirements and > they can initiate the route discoveries simultaneously." The application= s > don't initiate route discovery... Application requirements are mentioned > several times in this document, but it is not clear to me how those > requirements are reflected in the RREQ. > > [major] "..MUST be paired somehow, e.g. using the RPLInstanceID." There > is no clear Normative action here. s/MUST/must > > > ... > 782 6.4. Receiving and Forwarding Route Reply > > [-] Some of the comments above apply to this section too. > > > ... > 803 If the constraints are not fulfilled, the router MUST NOT join > the > 804 DODAG; the router MUST discard the RREQ-DIO, and does not execut= e > 805 the remaining steps in this section. > > [nit] s/and does not execute/and not execute > > > ... > 813 Step 3: > > 815 If the 'H' bit is set to 1, then the router (OrigNode or > 816 intermediate) MUST build a downward route entry. The route entr= y > 817 SHOULD include at least the following items: OrigNode Address, > 818 InstanceID, TargNode Address as destination, Next Hop, Lifetime > 819 and Sequence Number. For a symmetric route, the next hop in the > 820 route entry is the router from which the RREP-DIO is received. > 821 For an asymmetric route, the next hop is the preferred parent in > 822 the DODAG of RREQ-Instance. The InstanceID in the route entry > 823 MUST be the original RPLInstanceID (after subtracting the Shift > 824 field value). The source address is learned from the ART Option= , > 825 and the destination address is learned from the DODAGID. The > 826 lifetime is set according to DODAG configuration and can be > 827 extended when the route is actually used. The sequence number > 828 represents the freshness of the route entry, and is copied from > 829 the Dest SeqNo field of the ART option of the RREP-DIO. A route > 830 entry with same source and destination address, same InstanceID, > 831 but stale sequence number, SHOULD be deleted. > > [major] The description in =C2=A76.2.1 says that the "route entry MUST > include...". Why is SHOULD used in this case? When is it ok to not > include these items? Should the same apply to =C2=A76.2.1? > > > ... > 851 7. Gratuitous RREP > > [minor] This section introduces T and O (instead of TargNode/OrigNode) to > explain the operation. That is not a bad thing, but I think that having > consistent terminology is a really good thing. > > > ... > 872 In case of hop-by-hop routing, R MUST unicast the received RREQ-DIO > 873 hop-by-hop to T. The routers along the route SHOULD build new rout= e > 874 entries with the related RPLInstanceID and DODAGID in the downward > 875 direction. Then T MUST unicast the RREP-DIO hop-by-hop to R, and > the > 876 routers along the route SHOULD build new route entries in the upwar= d > 877 direction. Upon receiving the unicast RREP-DIO, R sends the > 878 gratuitous RREP-DIO to the OrigNode as defined in Section 6.3. > > [major] I don't understand how the "routers along the route" can do > anything if the messages are unicast...?? > > 880 8. Operation of Trickle Timer > > 882 The trickle timer operation to control RREQ-Instance/RREP-Instance > 883 multicast is similar to that in P2P-RPL [RFC6997]. > > [major] "The trickle timer operation...is similar to that in P2P-RPL > [RFC6997]." Similar, or the same?? > > Note that if it is the same, then rfc6997 would have to be a Normative > Reference. > > 885 9. IANA Considerations > > 887 9.1. New Mode of Operation: AODV-RPL > > 889 IANA is required to assign a new Mode of Operation, named "AODV-RPL= " > 890 for Point-to-Point(P2P) hop-by-hop routing under the RPL registry. > 891 The value of TBD1 is assigned from the "Mode of Operation" space > 892 [RFC6550]. > > [major] NEW> > IANA is asked to assign a new Mode of Operation, named "AODV-RPL" > for Point-to-Point(P2P) hop-by-hop routing from the "Mode of Operation= " > Registry [RFC6550]. > > > 894 +-------------+---------------+---------------+ > 895 | Value | Description | Reference | > 896 +-------------+---------------+---------------+ > 897 | TBD1 (5) | AODV-RPL | This document | > 898 +-------------+---------------+---------------+ > > 900 Figure 6: Mode of Operation > > 902 9.2. AODV-RPL Options: RREQ, RREP, and Target > > 904 Three entries are required for new AODV-RPL options "RREQ", "RREP" > 905 and "ART" with values of TBD2 (0x0A), TBD3 (0x0B) and TBD4 (0x0C) > 906 from the "RPL Control Message Options" space [RFC6550]. > > [major] NEW> > IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and > "ART", as described in Figure 7 from the "RPL Control Message Options" > Registry [RFC6550]. > > 908 +-------------+------------------------+---------------+ > 909 | Value | Meaning | Reference | > 910 +-------------+------------------------+---------------+ > 911 | TBD2 (0x0A) | RREQ Option | This document | > 912 +-------------+------------------------+---------------+ > 913 | TBD3 (0x0B) | RREP Option | This document | > 914 +-------------+------------------------+---------------+ > 915 | TBD3 (0x0C) | ART Option | This document | > 916 +-------------+------------------------+---------------+ > > 918 Figure 7: AODV-RPL Options > > 920 10. Security Considerations > > 922 The security mechanisms defined in section 10 of [RFC6550] and > 923 section 11 of [RFC6997] can also be applied to the control messages > 924 defined in this specification. The RREQ-DIO and RREP-DIO both have > a > 925 secure variant, which provide integrity and replay protection as > well > 926 as optional confidentiality and delay protection. > > [major] rfc6997/=C2=A711 mostly talks about the processing of the new mes= sages > defined there. How does that apply to this document? > > [major] rfc6997 says that section "10 of [RFC6550] describe RPL's securit= y > framework...This security framework can also be used in P2P-RPL after > taking into account the constraints specified in Section 11." How does > that apply to this document if both "section 10 of [RFC6550] and section = 11 > of [RFC6997]" are mentioned above? > > [minor] =C2=A73 talks about the fact that an RREQ-DIO is a DIO message wi= th the > rREQ Option (and there's similar text for the RREP-DIO). However, I thin= k > it's confusing to the reader to mention that there are secure variants. = I > think that expanding the description (at the end of =C2=A73) of what exac= tly the > *-DIO messages are (and that the definition includes the secure variants) > would go a long way. > > 928 AODV-RPL can operate in the three security modes defined in > 929 [RFC6550]. AODV-RPL messages SHOULD use a security mode at least a= s > 930 strong as the security mode used in RPL. > > [major] "AODV-RPL messages SHOULD use a security mode at least as strong > as the security mode used in RPL." What does that mean? As I asked > before, what is the relationship in the network between RPL and AODV-RPL. > I have been assuming that the Options are simply included as an "add-on" = to > the base RPL already running, but this statement seems to imply that they > are completely independent if they can have different security modes. ?= ? > > 932 o Unsecured. In this mode, RREQ-DIO and RREP-DIO are used without > 933 any security fields as defined in section 6.1 of [RFC6550]. The > 934 control messages can be protected by other security mechanisms, > 935 e.g. link-layer security. This mode SHOULD NOT be used when RPL > 936 is using Preinstalled mode or Authenticated mode (see below). > > [major] There is a Normative contradiction: (above) "This mode SHOULD NOT > be used when RPL is using Preinstalled mode or Authenticated mode (see > below)." ...and... (below) "Unsecured messages MUST be dropped." It seem= s > to me that maybe s/SHOULD NOT/MUST NOT > > [major] Related: There's no indication on what should be done with > unsecured messages in Authenticated mode. I'm assuming the same drop > action. > > 938 o Preinstalled. In this mode, AODV-RPL uses secure RREQ-DIO and > 939 RREP-DIO messages, and a node wishing to join a secured network > 940 will have been pre-configured with a shared key. A node can use > 941 that key to join the AODV-RPL DODAG as a host or a router. > 942 Unsecured messages MUST be dropped. This mode SHOULD NOT be use= d > 943 when RPL is using Authenticated mode. > > [major] When is it ok to use this mode with Authenticated mode? IOW, why > is that not a MUST NOT? > > ... > 961 11. Future Work > > [minor] This section sounds appropriate for an Experimental document and > not one in the Standards Track. > > [major] I would expect some of the items below to be specified in a > Standards Track document. For instance, "the initial state of a link" > seems pretty basic. Put another way, what should be the settings (for the > items mentioned here)? > > 963 There has been some discussion about how to determine the initial > 964 state of a link after an AODV-RPL-based network has begun operation= . > 965 The current draft operates as if the links are symmetric until > 966 additional metric information is collected. The means for making > 967 link metric information is considered out of scope for AODV-RPL. I= n > 968 the future, RREQ and RREP messages could be equipped with new field= s > 969 for use in verifying link metrics. In particular, it is possible t= o > 970 identify unidirectional links; an RREQ received across a > 971 unidirectional link has to be dropped, since the destination node > 972 cannot make use of the received DODAG to route packets back to the > 973 source node that originated the route discovery operation. This is > 974 roughly the same as considering a unidirectional link to present an > 975 infinite cost metric that automatically disqualifies it for use in > 976 the reverse direction. > > [major] "The current draft operates as if the links are symmetric until > additional metric information is collected." =C2=A76 mandates a check to > determine the state symmetry. How is that (unspecified) check related to > this text? It seems to be that it is the same thing; is it? > > 978 12. Contributors > > [minor] In general Contributors are listed list before the Author's > Address at the bottom [rfc7322]. > > > ... > 1060 Appendix A. Example: ETX/RSSI Values to select S bit > > [minor] Please expand ETX/RSSI on first mention (=C2=A75). > > 1062 We have tested the combination of "RSSI(downstream)" and "ETX > 1063 (upstream)" to determine whether the link is symmetric or > asymmetric > 1064 at the intermediate nodes. The example of how the ETX and RSSI > 1065 values are used in conjuction is explained below: > > [style nit] Don't write in the first person ("We have..."). > > [minor] It would be really nice to provide a reference for these tests. > > [minor] Add references for ETX/RSSI. > > [nit] s/conjuction/conjunction > > > ... > 1083 We tested the operations in this specification by making the > 1084 following experiment, using the above parameters. In our > experiment, > 1085 a communication link is considered as symmetric if the ETX value o= f > 1086 NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, within 1:3 > 1087 ratio. This ratio should be taken as a notional metric for > deciding > 1088 link symmetric/asymmetric nature, and precise definition of the > ratio > 1089 is beyond the scope of the draft. In general, NodeA can only know > 1090 the ETX value in the direction of NodeA -> NodeB but it has no > direct > 1091 way of knowing the value of ETX from NodeB->NodeA. Using physical > 1092 testbed experiments and realistic wireless channel propagation > 1093 models, one can determine a relationship between RSSI and ETX > 1094 representable as an expression or a mapping table. Such a > 1095 relationship in turn can be used to estimate ETX value at nodeA fo= r > 1096 link NodeB--->NodeA from the received RSSI from NodeB. Whenever > 1097 nodeA determines that the link towards the nodeB is bi-directional > 1098 asymmetric then the "S" bit is set to "S=3D0". Later on, the link > from > 1099 NodeA to Destination is asymmetric with "S" bit remains to "0". > > [nit] s/Figure.8/Figure 8 > > [nit] s/within 1:3 ratio/within 1:3 a ratio > > [nit] s/, and precise definition of the ratio is beyond the scope of the > draft./. Not needed, this is just an example. > > 1101 Appendix B. Changelog > > [nit] Add a note to the RFC Editor to remove this section before > publication. > > > --00000000000062d8a9058f85d0d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Alvaro for the review,

The tickets #194, #195, #196, #197= , #198=C2=A0 were created to address the issues [1].

Rel= ated to ticket #195 (Document Status), we are going to discuss it into the ML.
=

Best regards,

Ines.
=

On Thu, = Aug 1, 2019 at 5:54 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:
= Dear authors:

I just finished reading this document.=C2=A0 I am excited about the n= ew functionality, but I have several significant issues/questions about the= document, and a lot of comments (in-line below).

(1) What is AODV-RPL?

Reading the documen= t, my impression of AODV-RPL varies between an enhancement to RPL for React= ive Route Discovery (*maybe* in addition to the usual proactive routing), t= o ships-in-the-night reactive-only protocol that uses some of the RPL conce= pts (but not exactly sure which ones).=C2=A0 The different MOP indicates th= at it is different from "base" RPL (rfc6550), but it is not clear= what the assumptions are...and which parts are "inherited" from = the "base" and which ones are not used.

Another way to ask the same quest= ion is: What is the relationship of AODV-RPL to RPL?=C2=A0 What mechanisms = are not applicable with the new MOP?=C2=A0 Is it expected that an instance = of RPL will also be running in the network?
=
Please be clear early in the document.= =C2=A0 To quote Charlie: "AODV-RPL is a variation on RPL" [1].=C2= =A0 What remains, what changes, etc..


(2) Docum= ent Status (for the Chairs/Shepherd)

I didn't find a specific discussion in the= archive about the status of this document.=C2=A0 Did one take place?=C2=A0= At this point I am mostly curious given the similarities with rfc6997 (Exp= erimental) and the fact that "Future Work" is discussed -- not ty= pical in a Standards Track document.=C2=A0 IOW, why is this document intend= ed to be a Proposed Standard and not Experimental?


(3) Replacing rfc6997??

This document uses some of the features from rfc6997 (s= ee some comments about that in-line), which is fine.=C2=A0 The Introduction= falls just short of saying that this work replaces rfc6997.=C2=A0 Should i= t be considered a replacement?=C2=A0 I ask mostly in the context of rfc7733= (RPL in Home and Building) which mandates (MUST) the use of rfc6997.=C2=A0= Should rfc7733 be Updated? =C2=A0[I'm just asking the question for it = to be considered...I am not sure of deployments which conform to rfc7733 or= rfc6997...or the impact this would have.]
<= br>

(4) = Link checks

The operation of AODV-RPL depend on link checks (=C2=A76.2.1/=C2=A76.4)= to determine symmetry and whether it can "fulfill the requirements&qu= ot;.=C2=A0 But these checks are not explained or defined anywhere (are they= ?) beyond an *example* in the Appendix.=C2=A0 I think defining the checks i= s a critical part of the specification of the mechanism...specially for a S= tandards Track protocol.



Please take a look at the comments below.=C2=A0 I will wait= for the major points to be addressed before starting the IETF Last Call.

Thanks!!<= /div>

Alvaro.<= /div>



[Line numbers from idni= ts.]

...=
14 =C2=A0 =C2=A0 Asy= mmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)

[minor] This is not the= clearest title I've ever seen. =C2=A0 Suggestion: Reactive Route Disco= very using RPL (AODV-RPL) =C2=A0 =C2=A0...or something like that.

15= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0draft-ietf-roll-aodv-rpl-07

17 Abstract

19 <= /span> =C2=A0 Route discovery for symmetric and asymmetric Point-to-Point (= P2P)
20 =C2=A0 traffi= c flows is a desirable feature in Low power and Lossy Networks
21 =C2=A0 (LLNs).=C2=A0 For that = purpose, this document specifies a reactive P2P
22 =C2=A0 route discovery mechanism for both hop= -by-hop routing and source
23= =C2=A0 routing: Ad Hoc On-demand Distance Vector Routing (AODV) ba= sed RPL
24 =C2=A0 pro= tocol.=C2=A0 Paired Instances are used to construct directional paths,
25 =C2=A0 in case some of= the links between source and target node are
26 =C2=A0 asymmetric.

[minor] s/(AODV) based RPL protocol/= (AODV) based RPL protocol (AODV-RPL)


...
<= div style=3D"margin:0px">100 1.=C2=A0 Introduction

[general c= omment] Avoid mentioning the "negative" of other proposals and fo= cus on why this work is needed.=C2=A0 IOW, the justification should not be = "because others can't do it".
=
[nit] Some of the paragraphs throughout= the document are very long and could be split to better convey the ideas.<= /div>

102 =C2=A0 RPL[RFC6550] (Routing Protocol for LLNs (Low-Powe= r and Lossy
103 =C2= =A0 Networks)) is a IPv6 distance vector routing protocol designed to
=
104 =C2=A0 support multipl= e traffic flows through a root-based Destination-
105 =C2=A0 Oriented Directed Acyclic Graph (= DODAG).=C2=A0 Typically, a router does
106 =C2=A0 not have routing information for most other ro= uters.=C2=A0 Consequently,
107 =C2=A0 for traffic between routers within the DODAG (i.e., Point-= to-Point
108 =C2=A0 (= P2P) traffic) data packets either have to traverse the root in non-
109 =C2=A0 storing mode, or = traverse a common ancestor in storing mode.=C2=A0 Such
110 =C2=A0 P2P traffic is thereby likely = to traverse longer routes and may
111 =C2=A0 suffer severe congestion near the DAG root (for mor= e information see
112 = =C2=A0 [RFC6997], [RFC6998]).

[nit] s/RPL[RFC6550]/RPL [RFC6550]

[minor] s/Routing Proto= col for LLNs (Low-Power and Lossy Networks)/Routing Protocol for Low-Power = and Lossy Networks =C2=A0 =C2=A0That's the name of the protocol.
<= div style=3D"margin:0px">
[nit] s/is a I= Pv6/is an IPv6

[minor] "Such P2P traffic is thereby likely to traverse longer = routes and may suffer severe congestion near the DAG root (for more informa= tion see [RFC6997], [RFC6998])." =C2=A0I see that those other RFCs als= o make the statement that congestion is possible, and even longer routes...= but I don't see more information there.=C2=A0 Did I miss it?=C2=A0 If n= ot, then I don't see the value of those references at this point.
=

114 =C2=A0 To discover better paths for P2P traffic flows in RPL,= P2P-RPL
115 =C2=A0 [= RFC6997] specifies a temporary DODAG where the source acts as a
116 =C2=A0 temporary root.=C2=A0= The source initiates DIOs encapsulating the P2P
117 =C2=A0 Route Discovery option (P2P-RDO) wit= h an address vector for both hop-
118 =C2=A0 by-hop mode (H=3D1) and source routing mode (H=3D0)= .=C2=A0 Subsequently, each
119 =C2=A0 intermediate router adds its IP address and multicasts the= P2P mode
120 =C2=A0 = DIOs, until the message reaches the Target Node, which then sends the
=
121 =C2=A0 "Discovery= Reply" object.=C2=A0 P2P-RPL is efficient for source routing,
122 =C2=A0 but much less eff= icient for hop-by-hop routing due to the extra
123 =C2=A0 address vector overhead.=C2=A0 However= , for symmetric links, when the P2P
124 =C2=A0 mode DIO message is being multicast from the sour= ce hop-by-hop,
125 = =C2=A0 receiving nodes can infer a next hop towards the source.=C2=A0 When = the
126 =C2=A0 Target= Node subsequently replies to the source along the established
127 =C2=A0 forward route, receivi= ng nodes determine the next hop towards the
= 128 =C2=A0 Target Node.=C2=A0 For hop-by-hop routes = (H=3D1) over symmetric links, this
129 =C2=A0 would allow efficient use of routing tables for P2= P-RDO messages
130 = =C2=A0 instead of the "Address Vector".

[minor] Expand DIO on first use.<= /div>

[minor] = The description above of P2P-RPL seems to include too much (unnecessary for= this document) detail.=C2=A0 It also seems to propose enhancements (in the= last couple of sentences).=C2=A0 Consider simplifying to something like th= is:

=C2= =A0 =C2=A0To discover better paths for P2P traffic flows in RPL, P2P-RPL
=C2=A0 =C2=A0[RFC6997] specifies a temporary D= ODAG where the source acts as a
=C2=A0 =C2= =A0temporary root.=C2=A0 P2P-RPL is efficient for source routing,
=C2=A0 =C2=A0but can be much less efficient for hop-b= y-hop routing due to the
=C2=A0 =C2=A0extra = address vector overhead.


132 =C2=A0 RPL and P2P-RPL both specify the use of a single DODAG in netwo= rks of
133 =C2=A0 sym= metric links, where the two directions of a link MUST both satisfy
134 =C2=A0 the constraints of= the objective function.=C2=A0 This disallows the use of
135 =C2=A0 asymmetric links which are q= ualified in one direction.=C2=A0 But,
136 =C2=A0 application-specific routing requirements as de= fined in IETF ROLL
137 =C2=A0 Working Group [RFC5548], [RFC5673], [RFC5826] and [RFC5867] may be=
138 =C2=A0 satisfied= by routing paths using bidirectional asymmetric links.=C2=A0 For
139 =C2=A0 this purpose, [I-D.= thubert-roll-asymlink] described bidirectional
140 =C2=A0 asymmetric links for RPL [RFC6550] wit= h Paired DODAGs, for which the
141 =C2=A0 DAG root (DODAGID) is common for two Instances.=C2=A0 = This can satisfy
142 = =C2=A0 application-specific routing requirements for bidirectional
143 =C2=A0 asymmetric links i= n core RPL [RFC6550].=C2=A0 Using P2P-RPL twice with
144 =C2=A0 Paired DODAGs, on the other hand= , requires two roots: one for the
145 =C2=A0 source and another for the target node due to tempo= rary DODAG
146 =C2=A0= formation.=C2=A0 For networks composed of bidirectional asymmetric links
147 =C2=A0 (see Sectio= n 5), AODV-RPL specifies P2P route discovery, utilizing
148 =C2=A0 RPL with a new MoP.=C2=A0 AOD= V-RPL makes use of two multicast messages to
149 =C2=A0 discover possibly asymmetric routes.=C2= =A0 This provides higher route
150 =C2=A0 diversity and can find suitable routes that might othe= rwise go
151 =C2=A0 u= ndetected by RPL.=C2=A0 AODV-RPL eliminates the need for address vector
152 =C2=A0 overhead in h= op-by-hop mode.=C2=A0 This significantly reduces the control
153 =C2=A0 packet size, which is im= portant for Constrained LLN networks.=C2=A0 Both
154 =C2=A0 discovered routes (upward and downwa= rd) meet the application specific
155 =C2=A0 metrics and constraints that are defined in the Obj= ective Function
156 = =C2=A0 for each Instance [RFC6552].=C2=A0 On the other hand, the point-to-p= oint
157 =C2=A0 natur= e of routes discovered by AODV-RPL can reduce interference near
158 =C2=A0 the root nodes and al= so provide routes with fewer hops, likely
15= 9 =C2=A0 improving performance in the network.
=

[major] "= ;RPL and P2P-RPL both specify the use of a single DODAG in networks of symm= etric links, where the two directions of a link MUST both satisfy the const= raints of the objective function." =C2=A0s/MUST/must =C2=A0 Because yo= u are referring to RPL/P2P-RPL, the MUST is not Normative.

[minor] s/as defined in= IETF ROLL Working Group [RFC5548]/as defined in [RFC5548]

[minor] s/application-s= pecific routing requirements...may be satisfied by routing paths using bidi= rectional asymmetric links./application-specific routing requirements may a= lso be satisfied by routing paths using bidirectional asymmetric links. =C2= =A0 =C2=A0 I found just one mention of anything related to asymmetry (in rf= c5673)...so I think adding "also" is important.

[minor] "For this = purpose, [I-D.thubert-roll-asymlink] described bidirectional asymmetric lin= ks for RPL [RFC6550] with Paired DODAGs, for which the DAG root (DODAGID) i= s common for two Instances.=C2=A0 This can satisfy application-specific rou= ting requirements for bidirectional asymmetric links in core RPL [RFC6550].= " =C2=A0 =C2=A0I think that mention to this draft is unnecessary and m= ay be confusing to readers: the work seems to have been abandoned, and if i= t satisfies the requirements, then why do we need something else? =C2=A0;-)=

[minor]= I would also take out this sentence: "Using P2P-RPL twice..."

[minor] Ex= pand MoP on first use.=C2=A0 BTW, rfc6550 uses MOP (not MoP), please be con= sistent.

[minor] "Both discovered routes (upward and downward) meet the applic= ation specific metrics and constraints that are defined in the Objective Fu= nction for each Instance [RFC6552]." =C2=A0 I didn't find any talk= of application specific metrics in rfc6552.


..= .
170 2.=C2=A0 Termino= logy

172= =C2=A0 The key words "MUST", "MUST N= OT", "REQUIRED", "SHALL", "SHALL NOT",
173 =C2=A0 "SHOUL= D", "SHOULD NOT", "RECOMMENDED", "NOT RECOMME= NDED", "MAY", and
174 =C2=A0 "OPTIONAL" in this document are to be inte= rpreted as described in
175 <= /span> =C2=A0 [RFC2119], [RFC8174].=C2=A0 This document uses the following = terms:

[= major] Please use the rfc8174 template without modifications.


...
264 3.=C2=A0 Overview of AODV-RPL

[minor] It would be very nice if this overview had = forward references to where the behavior is specified.

266 = =C2=A0 With AODV-RPL, routes from OrigNode to TargNode within the LLN
=
267 =C2=A0 network are est= ablished "on-demand".=C2=A0 In other words, the route
268 =C2=A0 discovery mechanism i= n AODV-RPL is invoked reactively when OrigNode
269 =C2=A0 has data for delivery to the TargNode = but existing routes do not
270 =C2=A0 satisfy the application's requirements.=C2=A0 The rout= es discovered by
271 = =C2=A0 AODV-RPL are not constrained to traverse a common ancestor.=C2=A0 Un= like
272 =C2=A0 RPL [= RFC6550] and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric
273 =C2=A0 communication paths in= networks with bidirectional asymmetric links.
274 =C2=A0 For this purpose, AODV-RPL enables dis= covery of two routes: namely,
275 =C2=A0 one from OrigNode to TargNode, and another from TargNod= e to OrigNode.
276 = =C2=A0 When possible, AODV-RPL also enables symmetric route discovery along=
277 =C2=A0 Paired DO= DAGs (see Section 5).

[major] I get the impression that this document is an exten= sion to RPL, to be used when the existing routes don't meet specific re= quirements...at this point the reactive part would kick in.=C2=A0 Is that a= fair characterization?

The document jumps into talking about the extension, but it= says nothing about how the base RPL is used with it...or even if it is.=C2= =A0 Please spend a paragraph explaining that relationship.

279 =C2=A0 In AODV-RPL, routes are discovered by first forming a temporary = DAG
280 =C2=A0 rooted= at the OrigNode.=C2=A0 Paired DODAGs (Instances) are constructed
281 =C2=A0 according to the AO= DV-RPL Mode of Operation (MoP) during route
= 282 =C2=A0 formation between the OrigNode and TargNo= de.=C2=A0 The RREQ-Instance is
283 =C2=A0 formed by route control messages from OrigNode to Targ= Node whereas
284 =C2= =A0 the RREP-Instance is formed by route control messages from TargNode
285 =C2=A0 to OrigNode.= =C2=A0 Intermediate routers join the Paired DODAGs based on
286 =C2=A0 the rank as calculated fr= om the DIO message.=C2=A0 Henceforth in this
287 =C2=A0 document, the RREQ-DIO message means the= AODV-RPL mode DIO message
288 =C2=A0 from OrigNode to TargNode, containing the RREQ option (see=
289 =C2=A0 Section 4= .1).=C2=A0 Similarly, the RREP-DIO message means the AODV-RPL
290 =C2=A0 mode DIO message from T= argNode to OrigNode, containing the RREP
291= =C2=A0 option (see Section 4.2).=C2=A0 The route di= scovered in the RREQ-Instance
292 =C2=A0 is used for transmitting data from TargNode to OrigNode= , and the
293 =C2=A0 = route discovered in RREP-Instance is used for transmitting data from
<= div style=3D"margin:0px">294 =C2=A0 OrigNode to Targ= Node.

[n= it] s/rank/Rank/g =C2=A0 To be consistent with how rfc6550 uses the term.

296 4.=C2=A0 AODV-RPL DIO Options

298 4.1.=C2=A0= AODV-RPL DIO RREQ Option

300 =C2=A0 OrigNode sets its IPv6 = address in the DODAGID field of the RREQ-DIO
301 =C2=A0 message.=C2=A0 A RREQ-DIO message MUST c= arry exactly one RREQ option.

[major] What should a receiver do if more than one RR= EQ options are received?

303 =C2=A0 =C2=A0 =C2=A00 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
304 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
305 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
306 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 Type =C2=A0 =C2=A0 =C2=A0| Option Length |S|= H|X| Compr | L | =C2=A0 MaxRank =C2=A0 |
307= =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+
308 =C2=A0 =C2=A0 | =C2=A0Orig SeqNo =C2=A0 | =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
<= div style=3D"margin:0px">309 =C2=A0 =C2=A0 +-+-+-+-+= -+-+-+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
310 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
311 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
312 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address Vector (Optional= , Variable Length) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
313 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
314 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
315 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

317 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 Figure 1: DIO RREQ option format for AODV-RPL MoP

319 =C2=A0 OrigNode supplies the following information in the R= REQ option:

321 =C2=A0 Type
3= 22 =C2=A0 =C2=A0 =C2=A0The type assigned to the RREQ= option (see Section 9.2).

[major] s/Type/Option Type/g =C2=A0 That is the name in = rfc6550.

[minor] Use TBDx so that it matches the IANA Considerations section.=C2=A0= The same applies to other places where TBDx can be used.

...
348 =C2=A0 L

350 =C2=A0 = =C2=A0 =C2=A02-bit unsigned integer determining the duration that a node is=
351 =C2=A0 =C2=A0 = =C2=A0able to belong to the temporary DAG in RREQ-Instance, including
=
352 =C2=A0 =C2=A0 =C2=A0th= e OrigNode and the TargNode.=C2=A0 Once the time is reached, a node
353 =C2=A0 =C2=A0 =C2=A0MUST= leave the DAG and stop sending or receiving any more DIOs for
354 =C2=A0 =C2=A0 =C2=A0the tempo= rary DODAG.=C2=A0 The definition for the "L" bit is similar to
355 =C2=A0 =C2=A0 =C2= =A0that found in [RFC6997], except that the values are adjusted to
356 =C2=A0 =C2=A0 =C2=A0enabl= e arbitrarily long route lifetime.

[major] "definition for the "L" b= it is similar to that found in [RFC6997], except that..." =C2=A0 I thi= nk that this statement may be confusing to readers...remove it.

358 = =C2=A0 =C2=A0 =C2=A0* =C2=A00x00: No time limit imposed.
359 =C2=A0 =C2=A0 =C2=A0* =C2= =A00x01: 16 seconds
360 =C2=A0 =C2=A0 =C2=A0* =C2=A00x02: 64 seconds
361 =C2=A0 =C2=A0 =C2=A0* =C2=A00x03: 256 second= s

363 =C2=A0 =C2=A0 =C2=A0L is independent from the route li= fetime, which is defined in the
364 =C2=A0 =C2=A0 =C2=A0DODAG configuration option.=C2=A0 The ro= ute entries in hop-by-hop
365= =C2=A0 =C2=A0 =C2=A0routing and states of source routing can still= be maintained even
366 =C2=A0 =C2=A0 =C2=A0after the DAG expires.

[??] I don't understand what the = last sentence is trying to say.=C2=A0 It sounds as if the information learn= ed through the DAG can still be used after the DAG expires...up until the r= oute lifetime expires...is that it?=C2=A0 Please clarify.


...
373 = =C2=A0 Orig SeqNo
374 = =C2=A0 =C2=A0 =C2=A0Sequence Number of OrigNode, defined similarly as in A= ODV
375 =C2=A0 =C2=A0= =C2=A0[RFC3561].

[major] "similarly as in AODV" =C2=A0Similarly, or the = same??=C2=A0 Note that this reference could require rfc3561 to be a Normati= ve Reference.

I found this text in =C2=A76.1, which defines this field.=C2=A0 Which= one is correct?=C2=A0 Suggestion: point to =C2=A76.1.

=C2=A0 =C2=A0Each node maint= ains a sequence number, which rolls over like a
=C2=A0 =C2=A0lollipop counter [Perlman83]; refer to section 7.2 of [RFC= 6550] for
=C2=A0 =C2=A0detailed operation.= =C2=A0 When the OrigNode initiates a route discovery
=C2=A0 =C2=A0process, it MUST increase its own sequence number to = avoid conflicts
=C2=A0 =C2=A0with previously= established routes.=C2=A0 The sequence number is carried
=C2=A0 =C2=A0in the OrigSeqNo field of the RREQ option.


<= div style=3D"margin:0px">...
382 =C2=A0 A node MUST NOT join a RREQ instance if its own rank wo= uld equal to
383 =C2= =A0 or higher than MaxRank.=C2=A0 Targnode can join the RREQ instance at a<= /div>
384 =C2=A0 rank whose= integer portion is equal to the MaxRank.=C2=A0 A router MUST
385 =C2=A0 discard a received RREQ= if the integer part of the advertised rank
= 386 =C2=A0 equals or exceeds the MaxRank limit.=C2= =A0 This definition of MaxRank is
387 =C2=A0 the same as that found in [RFC6997].

[minor] s/own rank wou= ld equal to/own rank would be equal to

<= /div>
[nit] s/Targnode/TargNode

[minor] The second sentenc= e sounds like it contradicts the first one (where it says that "A node= MUST NOT join..."); I think that inverting the order would help:

=C2=A0 =C2= =A0TargNode can join the RREQ instance at a rank whose integer portion is
=C2=A0 =C2=A0equal to the MaxRank.=C2=A0 Othe= r nodes MUST NOT join a RREQ instance if its
=C2=A0 =C2=A0own rank is equal to or higher than MaxRank.


[major] "This definition of MaxRank is the same as that f= ound in [RFC6997]." =C2=A0True, for the most part: the context of the = definition is different.=C2=A0 Because the definition are not exactly the s= ame, and MaxRank is defined in this document, please take the sentence out.= =C2=A0 I don't think it adds anything significant.


389 4.2.=C2=A0 AODV-RPL DIO RREP Option
=

391 =C2=A0 TargNode sets its IPv6 address in the DODAGID field of= the RREP-DIO
392 =C2= =A0 message.=C2=A0 A RREP-DIO message MUST carry exactly one RREP option.
393 =C2=A0 TargNode su= pplies the following information in the RREP option:

[major] What should the receiv= er do if more than one RREP option is received?


...
441 =C2=A0 Shift=
442 =C2=A0 =C2=A0 = =C2=A06-bit unsigned integer.=C2=A0 This field is used to recover the
=
443 =C2=A0 =C2=A0 =C2=A0or= iginal InstanceID (see Section 6.3.3); 0 indicates that the
444 =C2=A0 =C2=A0 =C2=A0original Ins= tanceID is used.

[major] s/InstanceID/RPLInstanceID/g

446 =C2=A0 Rsv=
447 =C2=A0 =C2=A0 = =C2=A0MUST be initialized to zero and ignored upon reception.

[major] Do you expect= these bits to be assigned by IANA in the future?


...
456 4.3.=C2=A0 = AODV-RPL DIO Target Option

458 =C2=A0 The AODV-RPL Target (A= RT) Option is based on the Target Option in
= 459 =C2=A0 core RPL [RFC6550].=C2=A0 The Flags field= is replaced by the Destination
460 =C2=A0 Sequence Number of the TargNode and the Prefix Length= field is
461 =C2=A0 = reduced to 7 bits so that the value is limited to be no greater than
<= div style=3D"margin:0px">462 =C2=A0 127.

[minor] What is the= name of this option: "AODV-RPL DIO Target Option" or "AODV-= RPL Target Option"?=C2=A0 Please be consistent.

[??] "the Prefix Length f= ield is reduced to 7 bits so that the value is limited to be no greater tha= n 127." =C2=A0Why?=C2=A0 Is there an advantage?=C2=A0 Seriously, I'= ;m curious.

464 =C2=A0 A RREQ-DIO message MUST carry at leas= t one ART Option.=C2=A0 A RREP-DIO
465 =C2=A0 message MUST carry exactly one ART Option.

[major] What sh= ould a node do if more than one ART Option is received in a RREP-DIO messag= e?

467 =C2=A0 OrigNode can include multiple TargNode address= es via multiple AODV-
468 =C2=A0 RPL Target Options in the RREQ-DIO, for routes that share the s= ame
469 =C2=A0 constr= aints.=C2=A0 This reduces the cost to building only one DODAG.
470 =C2=A0 Furthermore, a single = Target Option can be used for different
471<= span class=3D"gmail-m_-3794167211467299691Apple-tab-span" style=3D"white-sp= ace:pre-wrap"> =C2=A0 TargNode addresses if they share the same pre= fix; in that case the
472 =C2=A0 use of the destination sequence number is not defined in this
473 =C2=A0 document.

[major] T= o be clear, what are the "constraints"?=C2=A0 Where are they defi= ned/signaled?=C2=A0 Are you talking about the contents of the RREQ Option (= S, H, MaxRank...anything else?)?=C2=A0 If so, please point that out explici= tly; "constraints" are mentioned in different places, but I could= n't find an explicit definition.

[major] "...in that case the use of the d= estination sequence number is not defined in this document." =C2=A0 Th= en that means that this last feature is not supported...right?=C2=A0 If tha= t's true, then please don't mention it.


...
511 =C2=A0 Targe= t Prefix / Address
512 =C2=A0 =C2=A0 =C2=A0(variable-length field) An IPv6 destination address o= r prefix.
513 =C2=A0 = =C2=A0 =C2=A0The Prefix Length field contains the number of valid leading b= its
514 =C2=A0 =C2=A0= =C2=A0in the prefix.=C2=A0 The bits in the Target Prefix / Address field
515 =C2=A0 =C2=A0 =C2= =A0after the prefix length (if any) MUST be set to zero on
516 =C2=A0 =C2=A0 =C2=A0transmission= and MUST be ignored on receipt.

<= div style=3D"margin:0px">[major] "The bits in the Target Prefix / Addr= ess field after the prefix length (if any)..." =C2=A0 I can see how th= is "is ok" because the receiver knows of these trailing bits from= the Option Length...*but*, why even allow it?=C2=A0 Why would the Target P= refix / Address not simply have a length =3D Prefix Length?

BTW, I know that rfc655= 0 has the same definition.=C2=A0 That doesn't make it right.=C2=A0 Ever= y extra bit has a cost...prefixes are elided, and here extra bits are allow= ed.


=
518 5.=C2=A0 Symmetri= c and Asymmetric Routes

520 =C2=A0 In Figure 4 and Figure 5,= BR is the Border Router, O is the OrigNode,
521 =C2=A0 R is an intermediate router, and T is th= e TargNode.=C2=A0 If the RREQ-DIO
522 =C2=A0 arrives over an interface that is known to be symme= tric, and the 'S'
523= =C2=A0 bit is set to 1, then it remains as 1, as illustrated in Fi= gure 4.
524 =C2=A0 If= an intermediate router sends out RREQ-DIO with the 'S' bit set to<= /div>
525 =C2=A0 1, then al= l the one-hop links on the route from the OrigNode O to
526 =C2=A0 this router meet the requirem= ents of route discovery, and the route
527 =C2=A0 can be used symmetrically.

[nit] A couple of places us= e "S bit", "'S' bit" is used above (and in most= of the document)...please be consistent. =C2=A0 Recommendation: S bit or S= -bit. =C2=A0 [BTW, please apply the same style to the other bits.]


...
552 <= /span> =C2=A0 Upon receiving a RREQ-DIO with the 'S' bit set to 1, = a node
553 =C2=A0 det= ermines whether this one-hop link can be used symmetrically, i.e.,
554 =C2=A0 both the two direc= tions meet the requirements of data transmission.
555 =C2=A0 If the RREQ-DIO arrives over an i= nterface that is not known to be
556 =C2=A0 symmetric, or is known to be asymmetric, the 'S&= #39; bit is set to 0.=C2=A0 If
557 =C2=A0 the 'S' bit arrives already set to be '0&#= 39;, it is set to be '0' on
558 =C2=A0 retransmission (Figure 5).=C2=A0 Therefore, for a= symmetric route, there is
559= =C2=A0 at least one hop which doesn't fulfill the constraints = in the two
560 =C2=A0= directions.=C2=A0 Based on the 'S' bit received in RREQ-DIO, the T= argNode
561 =C2=A0 T = determines whether or not the route is symmetric before
562 =C2=A0 transmitting the RREP-DIO mes= sage upstream towards the OrigNode O.

[nit] s/for asymmetric route/for an asymmetri= c route

= 564 =C2=A0 The criteria used to determine whether or= not each link is symmetric
565 =C2=A0 is beyond the scope of the document, and may be impleme= ntation-
566 =C2=A0 s= pecific.=C2=A0 For instance, intermediate routers MAY use local
567 =C2=A0 information (e.g., bi= t rate, bandwidth, number of cells used in
5= 68 =C2=A0 6tisch), a priori knowledge (e.g. link qua= lity according to previous
569 =C2=A0 communication) or use averaging techniques as appropriate = to the
570 =C2=A0 app= lication.

[major] s/MAY/may =C2=A0 This may is not Normative because there is no sp= ecific action (just examples).


...
602 6.1.=C2=A0 Route Request Gener= ation
...
614= =C2=A0 Each node maintains a sequence number, which= rolls over like a
615 =C2=A0 lollipop counter [Perlman83]; refer to section 7.2 of [RFC6550] fo= r
616 =C2=A0 detailed= operation.=C2=A0 When the OrigNode initiates a route discovery
617 =C2=A0 process, it MUST incr= ease its own sequence number to avoid conflicts
618 =C2=A0 with previously established routes.= =C2=A0 The sequence number is carried
619 =C2=A0 in the OrigSeqNo field of the RREQ option.

[minor] s/Ea= ch node maintains a sequence number...detailed operation./Each node maintai= ns a sequence number; the operation is specified in section 7.2 of [RFC6550= ].

...an= d take the reference to Perlman83 out.=C2=A0 It is enough for the specifica= tion to be done once; rfc6550 already took care of it.

[nit] s/OrigSeqNo/Orig SeqNo=


...
632 =C2=A0 The transmission of RREQ-DIO obeys the Trickle timer= .=C2=A0 If the
633 = =C2=A0 duration specified by the "L" bit has elapsed, the OrigNod= e MUST
634 =C2=A0 lea= ve the DODAG and stop sending RREQ-DIOs in the related
635 =C2=A0 RPLInstance.

[minor] "The trans= mission of RREQ-DIO obeys the Trickle timer." =C2=A0 A reference would= be nice.


637 6.2.=C2=A0 = Receiving and Forwarding RREQ messages

<= /div>
639 6.2.1.=C2=A0 Gener= al Processing

641 =C2=A0 Upon receiving a RREQ-DIO, a rout= er which does not belong to the
642 =C2=A0 RREQ-instance goes through the following steps:
=

[nit] s/RREQ-= instance/RREQ-Instance/g

[major] What if you do belong to the instance?=C2=A0 I'= ;m assuming that RREQ can be sent once the DODAG is built...or would what r= equire a difference RPLInstance?

<= div style=3D"margin:0px">644 =C2=A0 Step 1:

646 =C2=A0 =C2=A0 =C2=A0If the 'S' bit in the received RRE= Q-DIO is set to 1, the router
647 =C2=A0 =C2=A0 =C2=A0MUST check the two directions of the link = by which the RREQ-DIO is
648 = =C2=A0 =C2=A0 =C2=A0received.=C2=A0 In case that the downward (i.e.= towards the TargNode)
649 =C2=A0 =C2=A0 =C2=A0direction of the link can't fulfill the requi= rements, the link
650 = =C2=A0 =C2=A0 =C2=A0can't be used symmetrically, thus the 'S' = bit of the RREQ-DIO to
651 =C2=A0 =C2=A0 =C2=A0be sent out MUST be set as 0.=C2=A0 If the 'S= ' bit in the received
652= =C2=A0 =C2=A0 =C2=A0RREQ-DIO is set to 0, the router only checks i= nto the upward
653 = =C2=A0 =C2=A0 =C2=A0direction (towards the OrigNode) of the link.

[major] "the= router MUST check the two directions of the link" =C2=A0How is the li= nk checked?

[major] "If the 'S' bit...is set to 0..." =C2=A0The a= ction for when the S bit is set to 1 was defined using MUST...should this a= ction also include Normative Language?

<= /div>
655 =C2=A0 =C2=A0 =C2= =A0If the upward direction of the link can fulfill the requirements
656 =C2=A0 =C2=A0 =C2=A0indi= cated in the constraint option, and the router's rank would
657 =C2=A0 =C2=A0 =C2=A0not exce= ed the MaxRank limit, the router joins the DODAG of the
658 =C2=A0 =C2=A0 =C2=A0RREQ-Instance.= =C2=A0 The router that transmitted the received RREQ-DIO
659 =C2=A0 =C2=A0 =C2=A0is selected as = the preferred parent.=C2=A0 Later, other RREQ-DIO
660 =C2=A0 =C2=A0 =C2=A0messages might be re= ceived.=C2=A0 How to maintain the parent set,
661 =C2=A0 =C2=A0 =C2=A0select the preferred paren= t, and update the router's rank obeys
66= 2 =C2=A0 =C2=A0 =C2=A0the core RPL and the OFs defin= ed in ROLL WG.=C2=A0 In case that the
663 =C2=A0 =C2=A0 =C2=A0constraint or the MaxRank limit is= not fulfilled, the router MUST
664 =C2=A0 =C2=A0 =C2=A0discard the received RREQ-DIO and MUST N= OT join the DODAG.

[major] What is the "constraint option"?

[minor] "How to = maintain the parent set, select the preferred parent, and update the router= 's rank obeys the core RPL and the OFs defined in ROLL WG." =C2=A0= If there's no change, then I think this sentence is not needed.=C2=A0 I= f you want to keep it, then please reference specific documents and don'= ;t just point to the WG (in fact, don't point to the WG because the per= sistent references are documents).


...
672 =C2=A0 Step 3:

674= =C2=A0 =C2=A0 =C2=A0If the 'H' bit is set to 1, then the r= outer (TargNode or
675 =C2=A0 =C2=A0 =C2=A0intermediate) MUST build the upward route entry accor= dingly.=C2=A0 The
676 = =C2=A0 =C2=A0 =C2=A0route entry MUST include at least the following items:= Source
677 =C2=A0 = =C2=A0 =C2=A0Address, InstanceID, Destination Address, Next Hop, Lifetime, = and
678 =C2=A0 =C2=A0= =C2=A0Sequence Number.=C2=A0 The Destination Address and the InstanceID ca= n
679 =C2=A0 =C2=A0 = =C2=A0be respectively learned from the DODAGID and the RPLInstanceID of
680 =C2=A0 =C2=A0 =C2=A0= the RREQ-DIO, and the Source Address is copied from the ART
681 =C2=A0 =C2=A0 =C2=A0Option.=C2= =A0 The next hop is the preferred parent.=C2=A0 The lifetime is
682 =C2=A0 =C2=A0 =C2=A0set acco= rding to DODAG configuration and can be extended when the
683 =C2=A0 =C2=A0 =C2=A0route is act= ually used.=C2=A0 The sequence number represents the
684 =C2=A0 =C2=A0 =C2=A0freshness of the ro= ute entry, and it is copied from the Orig SeqNo
685 =C2=A0 =C2=A0 =C2=A0field of the RREQ option= .=C2=A0 A route entry with same source and
6= 86 =C2=A0 =C2=A0 =C2=A0destination address, same Ins= tanceID, but stale sequence number,
687 =C2=A0 =C2=A0 =C2=A0SHOULD be deleted.

[major] "...MUST b= uild the upward route entry accordingly." =C2=A0I was going to ask wha= t does "accordingly" mean, but the next sentence indicates what i= t has to include.=C2=A0 Instead of having two sentences trying to specify t= he same thing, please collapse them into one.

[minor] This route is to OrigNode, co= rrect?=C2=A0 Please say so.=C2=A0 I know that it has been mentioned that th= e RREQ-Instance is used for that -- remind the reader.

[major] "...the Source = Address is copied from the ART Option." =C2=A0 What is the "Sourc= e Address"?=C2=A0 I ask because I assumed that it is the address used = by the local router to send data to the OrigNode, but the only address in t= he ART Option is the "Target Prefix".=C2=A0 What am I missing?

[nit] Plea= se be consistent in how names are used.=C2=A0 For example, the paragraph ab= ove uses both "Next Hop" and "next hop" to refer to the= same thing.

[minor] "The lifetime is set according to DODAG configuration and= can be extended when the route is actually used." =C2=A0I think that = this is a little confusing, because you seem to be talking about route life= time and not the L (which I interpreted as lifetime too) value in the RREQ = Option, right?=C2=A0 Please be specific.
[nit] s/entry with same source/entry with = the same source

[major] "A route entry with same source and destination addres= s, same InstanceID, but stale sequence number, SHOULD be deleted." =C2= =A0When would it be ok to not delete the entry?=C2=A0 IOW, why is that not = a MUST?

= 689 =C2=A0 =C2=A0 =C2=A0If the 'H' bit is se= t to 0, an intermediate router MUST include
= 690 =C2=A0 =C2=A0 =C2=A0the address of the interface= receiving the RREQ-DIO into the
691 =C2=A0 =C2=A0 =C2=A0address vector.

[major] Step 3 (at least the fi= rst paragraph) seems to be about building a route entry.=C2=A0 What is diff= erent if the H bit is set to 0?=C2=A0 How is the route entry built?

[minor] This la= st paragraph talks about forwarding the RREQ, so perhaps it fits better in = the next step.

693 =C2=A0 Step 4:

695 =C2=A0= =C2=A0 =C2=A0An intermediate router transmits a RREQ-DIO via link-local
696 =C2=A0 =C2=A0 =C2= =A0multicast.=C2=A0 TargNode prepares a RREP-DIO.

[minor] "TargNode prepares a= RREP-DIO." =C2=A0Please add a forward reference to =C2=A76.3.

698 6.2.2.=C2=A0 Additional Processing for Multiple Targets

700 =C2=A0 If the OrigNode tries to reach multiple TargNodes in a = single RREQ-
701 =C2= =A0 instance, one of the TargNodes can be an intermediate router to the
702 =C2=A0 others, there= fore it SHOULD continue sending RREQ-DIO to reach other
703 =C2=A0 targets.=C2=A0 In this case, = before rebroadcasting the RREQ-DIO, a
704 =C2=A0 TargNode MUST delete the Target Option encapsul= ating its own address,
705 =C2=A0 so that downstream routers with higher ranks do not try to cre= ate a
706 =C2=A0 rout= e to this TargetNode.

[major] "...one of the TargNodes can be an intermediat= e router to the others, therefore it SHOULD continue sending RREQ-DIO to re= ach other targets." =C2=A0When would a TargNode choose not to forward = the RREQ?=C2=A0 IOW, why is that not a MUST?

708 =C2=A0 An i= ntermediate router could receive several RREQ-DIOs from routers
709 =C2=A0 with lower ranks in t= he same RREQ-instance but have different lists
710 =C2=A0 of Target Options.=C2=A0 When rebroadc= asting the RREQ-DIO, the
711 = =C2=A0 intersection of these lists SHOULD be included.=C2=A0 For ex= ample, suppose
712 = =C2=A0 two RREQ-DIOs are received with the same RPLInstance and OrigNode.
713 =C2=A0 Suppose fur= ther that the first RREQ has (T1, T2) as the targets, and
714 =C2=A0 the second one has (T2, T= 4) as targets.=C2=A0 Then only T2 needs to be
715 =C2=A0 included in the generated RREQ-DIO.=C2= =A0 If the intersection is empty, it
716 =C2=A0 means that all the targets have been reached, an= d the router SHOULD
717 =C2=A0 NOT send out any RREQ-DIO.=C2=A0 Any RREQ-DIO message with differ= ent ART
718 =C2=A0 Op= tions coming from a router with higher rank is ignored.

[major] "...the inters= ection of these lists SHOULD be included." =C2=A0When would a node not= include the intersection?=C2=A0 IOW, why is this not a MUST?

[major] "If the = intersection is empty...the router SHOULD NOT send out any RREQ-DIO." = =C2=A0When would it be ok to sent the RREQ out?=C2=A0 If there are no targe= ts, then it seems like you would never want to.=C2=A0 IOW, why is that not = a MUST NOT?

[minor] I'm not sure about the intersection logic above...but maybe= I'm missing something.=C2=A0 The example seems to imply that every RRE= Q should include all outstanding targets (?)...so that comparing the first = one (T1, T2) with the second (T2, T4), implies that T1 has been found...is = that correct?=C2=A0 If so, then it looks like T4 is still a valid target, b= ut the intersection wouldn't include it.=C2=A0 What am I missing?
=

[minor] Relat= ed: =C2=A0The specification above only applies to the period of time betwee= n receiving the first RREQ and the initial rebroadcast, right?=C2=A0 IOW, i= f a RREQ is received and rebroadcast....and then a second RREQ is received = (with a different list of targets), then the rebroadcast should not include= just the intersection, right?

720 6.3.=C2=A0 Generating Rout= e Reply (RREP) at TargNode

722 6.3.1.=C2=A0 RREP-DIO for Symm= etric route

724 =C2=A0 If a RREQ-DIO arrives at TargNode wit= h the 'S' bit set to 1, there is
725= =C2=A0 a symmetric route along which both direction= s can fulfill the
726 = =C2=A0 requirements.=C2=A0 Other RREQ-DIOs might later provide asymmetric = upward
727 =C2=A0 rou= tes (i.e.=C2=A0 S=3D0).=C2=A0 Selection between a qualified symmetric route=
728 =C2=A0 and an as= ymmetric route that might have better performance is
729 =C2=A0 implementation-specific and out = of scope.=C2=A0 If the implementation uses
7= 30 =C2=A0 the symmetric route, the TargNode MAY dela= y transmitting the RREP-DIO
731 =C2=A0 for duration RREP_WAIT_TIME to await a better symmetric= route.

= [major] RREP_WAIT_TIME is not defined anywhere.

[major] "...a better symmetric= route." =C2=A0What makes a route better?

733 =C2=A0 Fo= r a symmetric route, the RREP-DIO message is unicast to the next
734 =C2=A0 hop according to the= accumulated address vector (H=3D0) or the route
735 =C2=A0 entry (H=3D1).=C2=A0 Thus the DODAG = in RREP-Instance does not need to be
736 =C2=A0 built.=C2=A0 The RPLInstanceID in the RREP-Insta= nce is paired as defined
737 = =C2=A0 in Section 6.3.3.=C2=A0 In case the 'H' bit is set t= o 0, the address
738 = =C2=A0 vector received in the RREQ-DIO MUST be included in the RREP-DIO.
739 =C2=A0 TargNode inc= rements its current sequence number and uses the
740 =C2=A0 incremented result in the Dest SeqNo= in the ART option of the RREQ-
741 =C2=A0 DIO.=C2=A0 The address of the OrigNode MUST be encaps= ulated in the ART
742 = =C2=A0 Option and included in this RREP-DIO message.

744 6.3= .2.=C2=A0 RREP-DIO for Asymmetric Route

=
746 =C2=A0 When a RR= EQ-DIO arrives at a TargNode with the 'S' bit set to 0, the
747 =C2=A0 TargNode MUST bui= ld a DODAG in the RREP-Instance rooted at itself in
748 =C2=A0 order to discover the downstream = route from the OrigNode to the
749 =C2=A0 TargNode.=C2=A0 The RREP-DIO message MUST be re-transm= itted via link-local
750 =C2=A0 multicast until the OrigNode is reached or MaxRank is exceeded.<= /div>

[minor] = The previous section talked about delaying the RREP.=C2=A0 Should that be c= onsidered here too?

752 =C2=A0 The settings of the fields in= RREP option and ART option are the same
753= =C2=A0 as for the symmetric route, except for the &= #39;S' bit.

755 6.3.3.=C2=A0 RPLInstanceID Pairing
<= div style=3D"margin:0px">
[minor] Pairin= g only applied to symmetric routes, right?=C2=A0 Please say so.

757 = =C2=A0 Since the RPLInstanceID is assigned locally (i.e., there is = no
758 =C2=A0 coordin= ation between routers in the assignment of RPLInstanceID), the
759 =C2=A0 tuple (OrigNode, TargN= ode, RPLInstanceID) is needed to uniquely
76= 0 =C2=A0 identify a discovered route.=C2=A0 The uppe= r layer applications may have
761 =C2=A0 different requirements and they can initiate the route = discoveries
762 =C2= =A0 simultaneously.=C2=A0 Thus between the same pair of OrigNode and TargNo= de,
763 =C2=A0 there = can be multiple AODV-RPL instances.=C2=A0 To avoid any mismatch, the
<= div style=3D"margin:0px">764 =C2=A0 RREQ-Instance an= d the RREP-Instance in the same route discovery MUST
765 =C2=A0 be paired somehow, e.g. using th= e RPLInstanceID.

[minor] "The upper layer applications may have different requ= irements and they can initiate the route discoveries simultaneously." = =C2=A0The applications don't initiate route discovery...=C2=A0 Applicat= ion requirements are mentioned several times in this document, but it is no= t clear to me how those requirements are reflected in the RREQ.

[major] "..MUS= T be paired somehow, e.g. using the RPLInstanceID." =C2=A0There is no = clear Normative action here. =C2=A0s/MUST/must


= ...
782 6.4.=C2=A0 Rec= eiving and Forwarding Route Reply

=
[-] Some of the comments above apply to this sect= ion too.


...
803= =C2=A0 =C2=A0 =C2=A0If the constraints are not fulf= illed, the router MUST NOT join the
804 =C2=A0 =C2=A0 =C2=A0DODAG; the router MUST discard the R= REQ-DIO, and does not execute
805 =C2=A0 =C2=A0 =C2=A0the remaining steps in this section.
=

[nit] s/and d= oes not execute/and not execute


...
813 =C2=A0 Step 3:

815 =C2=A0 =C2=A0 =C2=A0If the 'H' bit is set to 1, then the rout= er (OrigNode or
816 = =C2=A0 =C2=A0 =C2=A0intermediate) MUST build a downward route entry.=C2=A0 = The route entry
817 = =C2=A0 =C2=A0 =C2=A0SHOULD include at least the following items: OrigNode A= ddress,
818 =C2=A0 = =C2=A0 =C2=A0InstanceID, TargNode Address as destination, Next Hop, Lifetim= e
819 =C2=A0 =C2=A0 = =C2=A0and Sequence Number.=C2=A0 For a symmetric route, the next hop in the=
820 =C2=A0 =C2=A0 = =C2=A0route entry is the router from which the RREP-DIO is received.
<= div style=3D"margin:0px">821 =C2=A0 =C2=A0 =C2=A0For= an asymmetric route, the next hop is the preferred parent in
822 =C2=A0 =C2=A0 =C2=A0the DODAG = of RREQ-Instance.=C2=A0 The InstanceID in the route entry
823 =C2=A0 =C2=A0 =C2=A0MUST be the = original RPLInstanceID (after subtracting the Shift
824 =C2=A0 =C2=A0 =C2=A0field value).=C2=A0 = The source address is learned from the ART Option,
825 =C2=A0 =C2=A0 =C2=A0and the destination = address is learned from the DODAGID.=C2=A0 The
826 =C2=A0 =C2=A0 =C2=A0lifetime is set according= to DODAG configuration and can be
827 =C2=A0 =C2=A0 =C2=A0extended when the route is actually u= sed.=C2=A0 The sequence number
828 =C2=A0 =C2=A0 =C2=A0represents the freshness of the route ent= ry, and is copied from
829 =C2=A0 =C2=A0 =C2=A0the Dest SeqNo field of the ART option of the RRE= P-DIO.=C2=A0 A route
830 =C2=A0 =C2=A0 =C2=A0entry with same source and destination address, sam= e InstanceID,
831 =C2= =A0 =C2=A0 =C2=A0but stale sequence number, SHOULD be deleted.

[major] The descript= ion in =C2=A76.2.1 says that the "route entry MUST include...".= =C2=A0 Why is SHOULD used in this case?=C2=A0 When is it ok to not include = these items?=C2=A0 Should the same apply to =C2=A76.2.1?


...
851 7.= =C2=A0 Gratuitous RREP

[minor] This section introduces T and O (instead of TargNod= e/OrigNode) to explain the operation.=C2=A0 That is not a bad thing, but I = think that having consistent terminology is a really good thing.


...
872 =C2=A0 In case of hop-by-hop routing, R MUST unicast the received RREQ= -DIO
873 =C2=A0 hop-b= y-hop to T.=C2=A0 The routers along the route SHOULD build new route
<= div style=3D"margin:0px">874 =C2=A0 entries with the= related RPLInstanceID and DODAGID in the downward
875 =C2=A0 direction.=C2=A0 Then T MUST unic= ast the RREP-DIO hop-by-hop to R, and the
87= 6 =C2=A0 routers along the route SHOULD build new ro= ute entries in the upward
877= =C2=A0 direction.=C2=A0 Upon receiving the unicast RREP-DIO, R sen= ds the
878 =C2=A0 gra= tuitous RREP-DIO to the OrigNode as defined in Section 6.3.

[major] I don't und= erstand how the "routers along the route" can do anything if the = messages are unicast...??

880 8.=C2=A0 Operation of Trickle T= imer

882= =C2=A0 The trickle timer operation to control RREQ-= Instance/RREP-Instance
883 =C2=A0 multicast is similar to that in P2P-RPL [RFC6997].

[major] "The t= rickle timer operation...is similar to that in P2P-RPL [RFC6997]." =C2= =A0Similar, or the same??

Note that if it is the same, then rfc6997 would have to b= e a Normative Reference.

885 9.=C2=A0 IANA Considerations

887 9.1.=C2=A0 New Mode of Operation: AODV-RPL

889 =C2=A0 IANA is required to assign a new Mode of Operation, named "= AODV-RPL"
890 = =C2=A0 for Point-to-Point(P2P) hop-by-hop routing under the RPL registry.
891 =C2=A0 The value o= f TBD1 is assigned from the "Mode of Operation" space
892 =C2=A0 [RFC6550].

[major] NEW>
=C2=A0 =C2=A0IANA is asked to assign a new Mod= e of Operation, named "AODV-RPL"
= =C2=A0 =C2=A0for Point-to-Point(P2P) hop-by-hop routing from the "Mode= of Operation"
=C2=A0 =C2=A0Registry [R= FC6550].


894 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+---------------+------= ---------+
895 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Value =C2=A0 =C2= =A0| =C2=A0Description =C2=A0| =C2=A0 Reference =C2=A0 |
896 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+-------------+---------------+---------------+
897 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 TBD1 (5) =C2=A0| =C2=A0 AODV-RPL =C2=A0 =C2=A0| T= his document |
898 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+------------= ---+---------------+

900 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 6: Mode of Operation=

902 9.2.=C2=A0 AODV-RPL Options: RREQ, RREP, and Target

904 =C2=A0 Three entries are required for new AODV-RPL options &= quot;RREQ", "RREP"
905 =C2=A0 and "ART" with values of TBD2 (0x0A), TBD= 3 (0x0B) and TBD4 (0x0C)
906 = =C2=A0 from the "RPL Control Message Options" space [RFC6= 550].

[m= ajor] NEW>
=C2=A0 =C2=A0IANA is asked to = assign three new AODV-RPL options "RREQ", "RREP" and
=C2=A0 =C2=A0"ART", as described in = Figure 7 from the "RPL Control Message Options"
=C2=A0 =C2=A0Registry [RFC6550].

908 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+------------------------+--------= -------+
909 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0Value =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0Meaning =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 Reference =C2= =A0 |
910 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0+-------------+------------------------+-----------= ----+
911 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| TBD2 (0x0A) | =C2=A0 =C2=A0 =C2=A0RREQ Option =C2= =A0 =C2=A0 =C2=A0 | This document |
912 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+-------= -----------------+---------------+
913 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TBD3 (0x0B) | =C2=A0 = =C2=A0 =C2=A0RREP Option =C2=A0 =C2=A0 =C2=A0 | This document |
914 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+-------------+------------------------+---------------+
915 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| TBD3 (0x0C) | =C2=A0 =C2=A0 =C2=A0 ART Option =C2=A0 =C2=A0 =C2=A0 = | This document |
916 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+------------------------+= ---------------+

918 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 7: AODV-RPL Options

920 10.=C2=A0 Security Considerations

922 =C2=A0 = The security mechanisms defined in section 10 of [RFC6550] and
923 =C2=A0 section 11 of [RFC6997= ] can also be applied to the control messages
924 =C2=A0 defined in this specification.=C2=A0 Th= e RREQ-DIO and RREP-DIO both have a
925 =C2=A0 secure variant, which provide integrity and repla= y protection as well
926 =C2=A0 as optional confidentiality and delay protection.

[major] rfc6997/=C2=A7= 11 mostly talks about the processing of the new messages defined there.=C2= =A0 How does that apply to this document?
[major] rfc6997 says that section "1= 0 of [RFC6550] describe RPL's security framework...This security framew= ork can also be used in P2P-RPL after taking into account the constraints s= pecified in Section 11." =C2=A0How does that apply to this document if= both "section 10 of [RFC6550] and section 11 of [RFC6997]" are m= entioned above?

[minor] =C2=A73 talks about the fact that an RREQ-DIO is a DIO mess= age with the rREQ Option (and there's similar text for the RREP-DIO).= =C2=A0 However, I think it's confusing to the reader to mention that th= ere are secure variants.=C2=A0 I think that expanding the description (at t= he end of =C2=A73) of what exactly the *-DIO messages are (and that the def= inition includes the secure variants) would go a long way.

928 =C2=A0 AODV-RPL can operate in the three security modes defined in
929 =C2=A0 [RFC6550].=C2= =A0 AODV-RPL messages SHOULD use a security mode at least as
930 =C2=A0 strong as the security m= ode used in RPL.

[major] "AODV-RPL messages SHOULD use a security mode at leas= t as strong as the security mode used in RPL." =C2=A0What does that me= an?=C2=A0 As I asked before, what is the relationship in the network betwee= n RPL and AODV-RPL.=C2=A0 I have been assuming that the Options are simply = included as an "add-on" to the base RPL already running, but this= statement seems to imply that they are completely independent if they can = have different security modes. =C2=A0 ??
932 =C2=A0 o =C2=A0= Unsecured.=C2=A0 In this mode, RREQ-DIO and RREP-DIO are used without
=
933 =C2=A0 =C2=A0 =C2=A0an= y security fields as defined in section 6.1 of [RFC6550].=C2=A0 The
934 =C2=A0 =C2=A0 =C2=A0cont= rol messages can be protected by other security mechanisms,
935 =C2=A0 =C2=A0 =C2=A0e.g. link-la= yer security.=C2=A0 This mode SHOULD NOT be used when RPL
936 =C2=A0 =C2=A0 =C2=A0is using Pre= installed mode or Authenticated mode (see below).

[major] There is a Normative cont= radiction: (above) "This mode SHOULD NOT be used when RPL is using Pre= installed mode or Authenticated mode (see below)." ...and... (below) &= quot;Unsecured messages MUST be dropped." =C2=A0It seems to me that ma= ybe s/SHOULD NOT/MUST NOT

[major] Related: =C2=A0There's no indication on what = should be done with unsecured messages in Authenticated mode.=C2=A0 I'm= assuming the same drop action.

938 =C2=A0 o =C2=A0Preinstal= led.=C2=A0 In this mode, AODV-RPL uses secure RREQ-DIO and
939 =C2=A0 =C2=A0 =C2=A0RREP-DIO mes= sages, and a node wishing to join a secured network
940 =C2=A0 =C2=A0 =C2=A0will have been pre-c= onfigured with a shared key.=C2=A0 A node can use
941 =C2=A0 =C2=A0 =C2=A0that key to join the= AODV-RPL DODAG as a host or a router.
942 =C2=A0 =C2=A0 =C2=A0Unsecured messages MUST be droppe= d.=C2=A0 This mode SHOULD NOT be used
943 =C2=A0 =C2=A0 =C2=A0when RPL is using Authenticated mo= de.

[maj= or] When is it ok to use this mode with Authenticated mode?=C2=A0 IOW, why = is that not a MUST NOT?

...
961 11.=C2=A0 Future Work

[minor] This section sounds appropriate for an Experimental= document and not one in the Standards Track.

[major] I would expect some of the it= ems below to be specified in a Standards Track document.=C2=A0 For instance= , "the initial state of a link" seems pretty basic. Put another w= ay, what should be the settings (for the items mentioned here)?

963 = =C2=A0 There has been some discussion about how to determine the in= itial
964 =C2=A0 stat= e of a link after an AODV-RPL-based network has begun operation.
965 =C2=A0 The current draft op= erates as if the links are symmetric until
9= 66 =C2=A0 additional metric information is collected= .=C2=A0 The means for making
967 =C2=A0 link metric information is considered out of scope for = AODV-RPL.=C2=A0 In
968 =C2=A0 the future, RREQ and RREP messages could be equipped with new fiel= ds
969 =C2=A0 for use= in verifying link metrics.=C2=A0 In particular, it is possible to
970 =C2=A0 identify unidirect= ional links; an RREQ received across a
971 =C2=A0 unidirectional link has to be dropped, since t= he destination node
972 =C2=A0 cannot make use of the received DODAG to route packets back to th= e
973 =C2=A0 source n= ode that originated the route discovery operation.=C2=A0 This is
974 =C2=A0 roughly the same as = considering a unidirectional link to present an
975 =C2=A0 infinite cost metric that automatical= ly disqualifies it for use in
976 =C2=A0 the reverse direction.
<= br>
[major] "The current draft operates= as if the links are symmetric until additional metric information is colle= cted." =C2=A0=C2=A76 mandates a check to determine the state symmetry.= =C2=A0 How is that (unspecified) check related to this text?=C2=A0 It seems= to be that it is the same thing; is it?
978 12.=C2=A0 Contri= butors

[= minor] In general Contributors are listed list before the Author's Addr= ess at the bottom [rfc7322].


...
1060 Appendix A.=C2=A0 Example: ETX/= RSSI Values to select S bit

[minor] Please expand ETX/RSSI on first mention (=C2=A7= 5).

1062= =C2=A0 We have tested the combination of "RSSI= (downstream)" and "ETX
1063 =C2=A0 (upstream)" to determine whether the link is s= ymmetric or asymmetric
1064 <= /span> =C2=A0 at the intermediate nodes.=C2=A0 The example of how the ETX a= nd RSSI
1065 =C2=A0 v= alues are used in conjuction is explained below:

[style nit] Don't write in the= first person ("We have...").

=
[minor] It would be really nice to provide = a reference for these tests.

[minor] Add references for ETX/RSSI.

[nit] s/conjuction/conj= unction

=
...
1083= =C2=A0 We tested the operations in this specificati= on by making the
1084 = =C2=A0 following experiment, using the above parameters.=C2=A0 In our expe= riment,
1085 =C2=A0 a= communication link is considered as symmetric if the ETX value of
1086 =C2=A0 NodeA->NodeB a= nd NodeB->NodeA (See Figure.8) are, say, within 1:3
1087 =C2=A0 ratio.=C2=A0 This ratio shoul= d be taken as a notional metric for deciding
1088 =C2=A0 link symmetric/asymmetric nature, and p= recise definition of the ratio
1089 =C2=A0 is beyond the scope of the draft.=C2=A0 In general, N= odeA can only know
1090 =C2=A0 the ETX value in the direction of NodeA -> NodeB but it has no= direct
1091 =C2=A0 w= ay of knowing the value of ETX from NodeB->NodeA.=C2=A0 Using physical
1092 =C2=A0 testbed ex= periments and realistic wireless channel propagation
1093 =C2=A0 models, one can determine a rel= ationship between RSSI and ETX
1094 =C2=A0 representable as an expression or a mapping table.=C2= =A0 Such a
1095 =C2= =A0 relationship in turn can be used to estimate ETX value at nodeA for
1096 =C2=A0 link NodeB--= ->NodeA from the received RSSI from NodeB.=C2=A0 Whenever
1097 =C2=A0 nodeA determines that t= he link towards the nodeB is bi-directional
= 1098 =C2=A0 asymmetric then the "S" bit is= set to "S=3D0".=C2=A0 Later on, the link from
1099 =C2=A0 NodeA to Destination is asy= mmetric with "S" bit remains to "0".

[nit] s/Figure.8/Figure 8<= /div>

[nit] s/= within 1:3 ratio/within 1:3 a ratio

[nit] s/, and precise definition of the ratio i= s beyond the scope of the draft./. =C2=A0 =C2=A0Not needed, this is just an= example.

1101 Appendix B.=C2=A0 Changelog

[nit] Add a note to the RF= C Editor to remove this section before publication.


--00000000000062d8a9058f85d0d0-- From nobody Thu Aug 8 06:13:41 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C9112013D for ; Thu, 8 Aug 2019 06:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OZm2_CHZbaa for ; Thu, 8 Aug 2019 06:13:28 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 D1D7C1201C5 for ; Thu, 8 Aug 2019 06:13:28 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id l15so118326694otn.9 for ; Thu, 08 Aug 2019 06:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CE55PK3XMuhag9qVU4NyYNV3rF6+ouumtNuXNqV5d7M=; b=QW3PJsoFODyGlqofW1mumMYJGEmtz267+ZXczmUY1JhiJH0TVVLjVNAV/t3KFOu3Rh ag//wIaOWiwdgDOj5Y6Pf6cM8JkZu0C/skUKiQgbjnOF2VbaZkirhUyNl2P7xt7IwvsE Z4wmaJFduFQJ/c5uPUGNqTcS2EP9SdN7M3vhQHhxD3Qe5iudd6iI+qyZleOLbx395aS5 0pcz709RzP52g6AvJk7hs114LzzdcN64uqNOsDvGOH6axnID9gCqQvArV0xp0ruzlToN /nDkl/vhzQMEwak05Mj1eHUbHF4rfUl73eQalEA2dc4t9qIKufcMvUQe9q5yIl2jp5yn /O7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CE55PK3XMuhag9qVU4NyYNV3rF6+ouumtNuXNqV5d7M=; b=hvztxB8DjsXsMR2dM4ckUMxe5D5gZBGzde0PPLBOgDpjRw7qY7cy/r4+RG0aqcI7HF 0QYJs4j4tBcDBux2dTOGcEiVCeHodLup7+LZaqQBRDmASSdSyYYnlOJoiWkyEDaXUxcK sN1VHnxFCjaN0UfC+P3MlSb5xTIvAM/2gqytNNAV/vGMmIYWg0E+pz0nagBcJ7/ZGecX IHL2aVO+S/6JAZU+/Cx2l9QOKecfSEg6nqsYJa0shfxXD1+qLN2Uw6UaVX+C6499HphU ExlWgSHPEoui5TxWmGiSWxOVzPnI4tw0ONGnKdnXKGCp+CtLD5W/qQjJF/ogTsx5OLA1 mj+Q== X-Gm-Message-State: APjAAAWBac6gVmdDdIL05Z3SNEMD8QgA1ch+sa4vkLafDTOCCSbN56Rr NeS53gDSbjKKVKzYxIFW6zB/xm+uOnh7+AVC6KU= X-Google-Smtp-Source: APXvYqwRUmi0Bh1QhV4O76lwTLkXPBbnOfDFpn5FErU7V3SW6mBTP/7QLCSrY1bKinzYnaciB4VMzu8kILSibx834/s= X-Received: by 2002:a5d:9550:: with SMTP id a16mr15087621ios.106.1565270007942; Thu, 08 Aug 2019 06:13:27 -0700 (PDT) MIME-Version: 1.0 References: <2B6FD9B0-2DE2-4A62-999A-4A4289E27E47@cisco.com> In-Reply-To: <2B6FD9B0-2DE2-4A62-999A-4A4289E27E47@cisco.com> From: Ines Robles Date: Thu, 8 Aug 2019 16:13:16 +0300 Message-ID: To: "Rahul Arvind Jadhav (Rahul Arvind Jadhav, 2012 Labs)" Cc: "rahul.ietf@gmail.com" , peter van der Stok , Routing Over Low power and Lossy networks , "rahul.ietf@gmail.com" Content-Type: multipart/alternative; boundary="000000000000cd122b058f9ad289" Archived-At: Subject: Re: [Roll] WGAdoption for draft-rahul-roll-mop-ext X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 13:13:40 -0000 --000000000000cd122b058f9ad289 Content-Type: text/plain; charset="UTF-8" Hi Rahul, The document presents consensus. Could you please submit a new version as an IETF ROLL WG document? Thank you, Ines and Peter. > > *From: *Roll on behalf of Ines Robles > > *Reply-To: *Routing Over Low power and Lossy networks > *Date: *Thursday, July 25, 2019 at 3:06 AM > *To: *roll > *Subject: *[Roll] WGAdoption for draft-rahul-roll-mop-ext > > > > Dear all, > > > > This is a WG adoption call for draft-rahul-roll-mop-ext from 24-07-2019 to > 07-08-2019. > > > > Please let us know your comments, > > > > Thanks, > > > > Ines and Peter > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000cd122b058f9ad289 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rahul,

The document= presents consensus. Could you please submit a new version as an IETF ROLL = WG document?

Thank you,

I= nes and Peter.


=C2= =A0

From: = Roll <roll-bounces@ietf.org>= ; on behalf of Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org<= /a>>
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
Date: Thursday, July 25, 2019 at 3:06 AM
To: roll <roll= @ietf.org>
Subject: [Roll] WGAdoption for draft-rahul-roll-mop-ext

=C2=A0

Dear all,

=C2=A0

This is a WG adoption call for=C2=A0draft-rahul-roll= -mop-ext from 24-07-2019 to 07-08-2019.

=C2=A0

Please let us know your comments,

=C2=A0

Thanks,

=C2=A0

Ines and Peter

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000cd122b058f9ad289-- From nobody Thu Aug 8 06:19:52 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4993D120044 for ; Thu, 8 Aug 2019 06:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HsBUgJ3a2uC for ; Thu, 8 Aug 2019 06:19:49 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 DB0A012001B for ; Thu, 8 Aug 2019 06:19:48 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id r6so118375359oti.3 for ; Thu, 08 Aug 2019 06:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=tzf6ctM//QIjOJPx0mdEc46AiWAGJVogFQJbDzv11h8=; b=PdO1siAqBEl+TCmfnsh3EFRrACXnejWzw9laD1SaBZp2nkI2yMJoxT2ZC0PE2TgqFg OjYrIClxLSyjNOulannf9g85o6sbn6+OGWlzqTkKRNSb+JCS7EjBUELnWS59bO2X22FB wDttCOv1WBey2rb6y1AwtspxJow5rc7aj1iJyjD4Fbb46rWxwLTp3YSs2NGo/5RpGj/v ZLeCUWDYdIGWUV+H1Vta3hIc1lEa+rqtKeJojZQ45dFQsFn+hRhubWrgLSIo9LwL8RfC dAxVEmUAm2YcFEKe2XmIi29GtWIAsPF3e4I0LY1axWQrmcC4qqk7lFB08b24GH21OC4h ZmOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=tzf6ctM//QIjOJPx0mdEc46AiWAGJVogFQJbDzv11h8=; b=kLdJVqb+DONKZszXXzb2dI5Oz/lVLZfhllK3vch9foxJrDpv8uhp5L9Zn95fBbIpPR X2HuLEFzLR+CBsX28Hqo8OtBQVUlGRI1saHPc/XsymgN9Pyuk07veaNhRV9fgJF6+BnU +2Sai3e5MaSlD5mxa6yvP6GkJT1Vhv0HtznT8kr747xX+vMa3J5zpcpY1JQ/h+M3WWri SMdGcO7XQfJWR4LRaK2A6pC9SC0CR6Ky0yl4Ic9eav16X4LLDC7CWS4MpFCIRcImT5ES OWNTuO+v4RsiwSx6Pi9779kryxDm1yHnRzT/gwlEOgXUUlgIToX2WF1+TGRQ3VHI33sJ 1G2Q== X-Gm-Message-State: APjAAAUTKs1vkBc67DTFsjrzY5QMhJq4P5yzS3WWUSwgKU7zSkDi3fz9 Mh9G9Gs2+XpFYqrQfk1LiAcY/3eJwf+znfe3TbjdkWe/ X-Google-Smtp-Source: APXvYqwCDYxKBP18K5jDmFCTXwLLmPtySENTmjc2NNBXrJuEiy8r6g34xh6wXDuNx++V/8wwitjIUb6pUOqxV4pFLPk= X-Received: by 2002:a5e:d817:: with SMTP id l23mr14941454iok.282.1565270387842; Thu, 08 Aug 2019 06:19:47 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Thu, 8 Aug 2019 16:19:36 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000071e4d5058f9ae9ff" Archived-At: Subject: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 13:19:51 -0000 --00000000000071e4d5058f9ae9ff Content-Type: text/plain; charset="UTF-8" Dear all, This is a call for WG adoption of the draft draft-richardson-6tisch-roll-enrollment-priority-02. The call starts today 08-08-2019 until 08-22-2019. Please let us know your opinion on this. Thank you in advance, Ines and Peter. --00000000000071e4d5058f9ae9ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

This is a call for WG adoptio= n of the draft=C2=A0draft-richardson-6tisch-roll-enrollment-priority-02.

The call starts today 08-08-2019 until 08-22-2019.

Please let us know your opinion on this.
=
Thank you in advance,

Ines and Pete= r.
--00000000000071e4d5058f9ae9ff-- From nobody Thu Aug 8 13:55:03 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5568A120294 for ; Thu, 8 Aug 2019 13:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTZb2Xg9VOIx for ; Thu, 8 Aug 2019 13:54:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C401202CA for ; Thu, 8 Aug 2019 13:54:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DB4073818F for ; Thu, 8 Aug 2019 16:53:53 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 76308CC for ; Thu, 8 Aug 2019 16:54:32 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 20:55:02 -0000 --=-=-= Content-Type: text/plain Hi, I have pushed a new version of this document. The datatracker has locked into the "6tisch" part of the filename and announced to a different list though: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG of the IETF. > > Title : Enabling secure network enrollment in RPL networks > Author : Michael Richardson > Filename : draft-richardson-6tisch-roll-enrollment-priority-03.txt > Pages : 6 > Date : 2019-08-08 >Abstract: > [I-D.ietf-6tisch-enrollment-enhanced-beacon] defines a method by > which a potential [I-D.ietf-6tisch-minimal-security] join proxy can > announce itself as a available for new Pledges to Join a network. > The announcement includes a priority for join. This document > provides a mechanism by which a RPL DODAG root can disable join > announcements, or adjust the base priority for join operation. > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=draft-richardson-6tisch-roll-enrollment-priority-03 The major difference is that 6tisch has adopted the related enhanced-beacon document, so the reference has changed, and the voucher document got published as RFC8366. There are no other changes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1MjAgACgkQgItw+93Q 3WXKdQf/abm9Hu1w+PvNvlHbPm+jER6R6nijPYhKSKWYkTptsH9g2TRO5friCNSK yIVLEU47/+7sELyGey647S6HkVtKYc3eLFUTAOxcDwdabsKHVRK7y5/YUbxfn6Fk 6/Dt9XsW4LXIalwrAb/hDFqshIi76RFV9AxQkGydfoTlFQo0Y/eTFqPLeJXOC6pD iSIvuQcJc0yFbtalb0YciIQj90sxlys0zNEtc0j4Z4t1byr4MldslOH80tMHtD7C +gtwZ1wxaZcT2kChIkyjBeqHhgAkwwAHXd0OKGUEdc7YQ8JAQcbxzYsHmuuvc0gs J1kot09rXmhDYfBNe9yZ6ewe1Nvw8g== =Y7Kp -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 9 00:54:56 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CC11200A4 for ; Fri, 9 Aug 2019 00:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DHq68nzp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=igKmhK/v Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZmQUmvWZa7U for ; Fri, 9 Aug 2019 00:54:51 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FA0120058 for ; Fri, 9 Aug 2019 00:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2620; q=dns/txt; s=iport; t=1565337291; x=1566546891; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BVPWvcBsVqcycU2zGWuZrafpkHSQb7unNqrJSs2XY1k=; b=DHq68nzpNP6WvAZTQybG0XPLSK5CE7wNCXYOSd3D6/4LgioJEV2YWQmN ZOoJffw75cgPFnZGfRYz/aTVYk3AvdXMa/hzMORi8oKSGot81ua05xXLO sSTqoRjyx7VAcvcHqSulWZxIge7vPwm215U1JMLMYzv2/sWBFoC0L/Z+G U=; IronPort-PHdr: =?us-ascii?q?9a23=3AlCmltBC7hAuN2+1dMw8bUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTAAD1JU1d/4YNJK1eCB4BBgcGgVM?= =?us-ascii?q?JCwGBRCknA21VIAQLKoQeg0cDiw5Mgg+XYYEugSQDVAkBAQEMAQEYDQgCAQG?= =?us-ascii?q?BS4J0AheCRiM0CQ4BBAEBBAEBBAEKbYUnDIVLAQEBAgEBARALBhEMAQEsDAQ?= =?us-ascii?q?LAgEIEggCJgICAiULFQIOAgQTIoMAAYFqAw4PAQIMnzQCgTiIYHKBMoJ6AQE?= =?us-ascii?q?FgTcCgQ+CTRiCFAMGgQwoAYtjF4FAP4ERJx+CTD6CYQEBAhiBIiWDCzKCJo8?= =?us-ascii?q?Qjg2OKwkCgh2ULRuYOIMwoiACBAIEBQIOAQEFgVA4gVhwFRohKgGCQYJCOG8?= =?us-ascii?q?BBwgHgjSFFIU/coEpjVEBAQ?= X-IronPort-AV: E=Sophos;i="5.64,364,1559520000"; d="scan'208";a="303210028" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Aug 2019 07:54:50 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x797soPQ028164 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 9 Aug 2019 07:54:50 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 9 Aug 2019 02:54:50 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 9 Aug 2019 02:54:49 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 9 Aug 2019 02:54:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mC0pKthJMywpgwjYlViVUJ2KADwFVJinX1bDai6/dmY5AU/qKwNLPERmo6cjb6vvNayH4JOaY8R+xnQRwMQx12SOoyWMVuHEAqLXLhpoouzqKGC9i3h1CFahkYs19WNnEwBwQiq9CYrwUF36FeVgAeQsZqvOXajAmgTh1xgmmeOi2pLsw9g1of56ZHpEIYcOWQY59h894RKzO1EufLqookdaQKJK2H68HvfxEBQJo6xhVZb0w5ZQ2jUJjGGD2t5EdBpdon1+nBlwiBjneWEDrcT7+dJkm+c735et/pYlhScI74JUH+Q+On3TFTnMPLyoaipcy8+A7evQZXjp9mmpHw== 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=BVPWvcBsVqcycU2zGWuZrafpkHSQb7unNqrJSs2XY1k=; b=gBGCUMvtBjr/K72sUN2hvVTFW8x9X98sD8p82iA36Cf2Npio6/rDYYikgXZe9GBeFQHiqJH3TRlxeveg28FIQLbBS9fjld0FXlugN7y0vlqmHvK7xfVIhmFwHIbxneAP2P9wOqXZ5YJCChGHW9q8I1n22RM3F5f1zsfUg24JxWms9SLSGYVTBWe08oMz+94IyyDPANwKZDe66qaoawSKC91g4SGBNpsQq3//zSUhU2JHSjRnGlRhRFAMaRqz0tx3rYnAa3wwFoGtV3Z7sAsw4mHN23lQ2pkqBbbLnO+Klewp2mxOXHhFIzACrDbnG02bYJl6Kwn6/LUpZhAzwAskeg== 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=BVPWvcBsVqcycU2zGWuZrafpkHSQb7unNqrJSs2XY1k=; b=igKmhK/vkXdrVC7XI13QNVNKbM2wcGklKTdRhjoX2Cd+AatvZs5x1vWtFjsBjI5husuNWH4FVq8BaQI9RMDnEr6AAlH0Lhp35FTRDs1llW6Ue4VNSM/Bq02rLhkzlMbWlv2KCQP02uWFoPZbylQaFDJyRaIHR7p3kUWJ6D+qdKQ= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3984.namprd11.prod.outlook.com (10.255.181.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.16; Fri, 9 Aug 2019 07:54:48 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2136.018; Fri, 9 Aug 2019 07:54:48 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 Thread-Index: AQHVTewCJ90KYocxKUy0UOYm7Zxj1KbxuxwAgAC4etE= Date: Fri, 9 Aug 2019 07:54:48 +0000 Message-ID: <370EA108-F0E8-494B-B4B2-0304D2C26403@cisco.com> References: , <17648.1565297672@localhost> In-Reply-To: <17648.1565297672@localhost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2a01:cb15:26a:cf00:c19c:3c72:87ea:dd77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 78a29f3c-de35-48f5-cbba-08d71c9eda02 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3984; x-ms-traffictypediagnostic: MN2PR11MB3984: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 01244308DF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(39860400002)(366004)(376002)(189003)(199004)(316002)(2616005)(256004)(6306002)(6116002)(478600001)(46003)(446003)(36756003)(11346002)(476003)(6916009)(7736002)(486006)(25786009)(305945005)(186003)(33656002)(5660300002)(966005)(14454004)(6486002)(102836004)(76176011)(76116006)(6506007)(6436002)(14444005)(8936002)(2906002)(66946007)(66556008)(64756008)(86362001)(66446008)(6246003)(6512007)(66574012)(71190400001)(71200400001)(66476007)(229853002)(8676002)(91956017)(81166006)(81156014)(53936002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3984; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kKqE+Xwu/rX8aXN/nTLU/JTFmpCXdp/mLj7BQ3USOTarAnlga53FnCTHPDzROhj7LGjSn9QaJrTvr9vLvHK9HyQnHQxDieLla0ziLOreLQKW7poCOmuvZZDJ/0A7+avuGXke+ixAkS9cO+03EdxvuZqLUEimsxZFeQwkI3dAPVpSojYzde5p5rAZ0v/vSQNUiZyetGKUkGfMXF5Qe+Zr4NT6bpKU6MIUdeGpp9wBWGh7ugWFCu3o+oQD6k1ykL6qnwZ/9Jkg+sIVOMGYfz26dPrvjEDs0jgJznCby8SaEbtspMbe8J7sryqDjkPoS06EL9k8HDPhmpLLAlWQ+ATWo9VdIm2Tm9GQyywnpR9Z8riDU9Us4ndFDq5eFl+PuHiORZOCb0D+nY5DE1bUceFF0Lfe1dEcRXhVY8L7dFUZS04= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 78a29f3c-de35-48f5-cbba-08d71c9eda02 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2019 07:54:48.3052 (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: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3984 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 07:54:55 -0000 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbi4NCg0KVGhpcyBpbXBsZW1lbnRzIGEgbXVjaCBuZWVkZWQg cGllY2Ugb2YgdGhlIG92ZXJhbGwgSW9UIEFyY2hpdGVjdHVyZSB0aGF0IDZ0aXNjaCBkZXZlbG9w ZWQuDQoNCg0KUmVnYXJkcywNCg0KUGFzY2FsDQoNCj4gTGUgOCBhb8O7dCAyMDE5IMOgIDIyOjU1 LCBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4gYSDDqWNyaXQgOg0K PiANCj4gDQo+IEhpLCBJIGhhdmUgcHVzaGVkIGEgbmV3IHZlcnNpb24gb2YgdGhpcyBkb2N1bWVu dC4NCj4gVGhlIGRhdGF0cmFja2VyIGhhcyBsb2NrZWQgaW50byB0aGUgIjZ0aXNjaCIgcGFydCBv ZiB0aGUgZmlsZW5hbWUgYW5kDQo+IGFubm91bmNlZCB0byBhIGRpZmZlcmVudCBsaXN0IHRob3Vn aDoNCj4gDQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiBUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBJUHY2IG92ZXIgdGhlIFRTQ0ggbW9kZSBvZiBJRUVFIDgwMi4xNS40ZSBX RyBvZiB0aGUgSUVURi4NCj4+IA0KPj4gICAgICAgVGl0bGUgICAgICAgICAgIDogRW5hYmxpbmcg c2VjdXJlIG5ldHdvcmsgZW5yb2xsbWVudCBpbiBSUEwgbmV0d29ya3MNCj4+ICAgICAgIEF1dGhv ciAgICAgICAgICA6IE1pY2hhZWwgUmljaGFyZHNvbg0KPj4gICAgRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtcmljaGFyZHNvbi02dGlzY2gtcm9sbC1lbnJvbGxtZW50LXByaW9yaXR5LTAzLnR4dA0K Pj4gICAgUGFnZXMgICAgICAgICAgIDogNg0KPj4gICAgRGF0ZSAgICAgICAgICAgIDogMjAxOS0w OC0wOA0KPiANCj4+IEFic3RyYWN0Og0KPj4gIFtJLUQuaWV0Zi02dGlzY2gtZW5yb2xsbWVudC1l bmhhbmNlZC1iZWFjb25dIGRlZmluZXMgYSBtZXRob2QgYnkNCj4+ICB3aGljaCBhIHBvdGVudGlh bCBbSS1ELmlldGYtNnRpc2NoLW1pbmltYWwtc2VjdXJpdHldIGpvaW4gcHJveHkgY2FuDQo+PiAg YW5ub3VuY2UgaXRzZWxmIGFzIGEgYXZhaWxhYmxlIGZvciBuZXcgUGxlZGdlcyB0byBKb2luIGEg bmV0d29yay4NCj4+ICBUaGUgYW5ub3VuY2VtZW50IGluY2x1ZGVzIGEgcHJpb3JpdHkgZm9yIGpv aW4uICBUaGlzIGRvY3VtZW50DQo+PiAgcHJvdmlkZXMgYSBtZWNoYW5pc20gYnkgd2hpY2ggYSBS UEwgRE9EQUcgcm9vdCBjYW4gZGlzYWJsZSBqb2luDQo+PiAgYW5ub3VuY2VtZW50cywgb3IgYWRq dXN0IHRoZSBiYXNlIHByaW9yaXR5IGZvciBqb2luIG9wZXJhdGlvbi4NCj4+IA0KPj4gQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXJpY2hhcmRzb24tNnRpc2NoLXJvbGwtZW5y b2xsbWVudC1wcmlvcml0eS0wMw0KPiANCj4gVGhlIG1ham9yIGRpZmZlcmVuY2UgaXMgdGhhdCA2 dGlzY2ggaGFzIGFkb3B0ZWQgdGhlIHJlbGF0ZWQgZW5oYW5jZWQtYmVhY29uDQo+IGRvY3VtZW50 LCBzbyB0aGUgcmVmZXJlbmNlIGhhcyBjaGFuZ2VkLCBhbmQgdGhlIHZvdWNoZXIgZG9jdW1lbnQg Z290DQo+IHB1Ymxpc2hlZCBhcyBSRkM4MzY2LiAgVGhlcmUgYXJlIG5vIG90aGVyIGNoYW5nZXMu DQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4s IFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQo+ IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From nobody Fri Aug 9 05:11:37 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A07F6120168; Fri, 9 Aug 2019 05:11:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <156535268161.16137.13697675656692085338@ietfa.amsl.com> Date: Fri, 09 Aug 2019 05:11:21 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-mopex-cap-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 12:11:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Mode of Operation extension and Capabilities Authors : Rahul Arvind Jadhav Pascal Thubert Filename : draft-ietf-roll-mopex-cap-00.txt Pages : 9 Date : 2019-08-09 Abstract: RPL allows different mode of operations which allows nodes to have a consensus on the basic primitives that must be supported to join the network. The MOP field in RFC6550 is of 3 bits and is fast depleting. This document extends the MOP field specification and adds a notion of capabilities using which the nodes can further advertise their support for, possibly optional, capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-mopex-cap/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-mopex-cap-00 https://datatracker.ietf.org/doc/html/draft-ietf-roll-mopex-cap-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 12 14:27:03 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E68120090; Mon, 12 Aug 2019 14:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfAw8H7TzPaM; Mon, 12 Aug 2019 14:26:58 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56E812131B; Mon, 12 Aug 2019 00:08:59 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id EEB4E182CF666; Mon, 12 Aug 2019 07:08:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=7xD6Jn4hPrRp5YvSYf o5eX4lTGHEI7H5JJR68ubxoeY=; b=X8HW9GGlmlEMSnmeV4Zvh8WB3I9NBsLoHm Gl3M/nsVDIeknifsKa/h7C2bM9XZnt0DehJqBWQjn4ZmGcjsQC69l3vTjH8ihn6O +Q/s1YP87BoGrH4DpW8rG1X8e16YwDj1Zfr+8N1121L05FApDYrbz1KjY3P5q2Ft igm1/8xj0= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::::, RULES_HIT:1:41:72:152:355:379:582:599:800:960:962:967:969:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1544:1575:1588:1589:1592:1594:1605:1711:1730:1776:1792:2068:2069:2194:2198:2199:2200:2525:2528:2553:2559:2567:2570:2682:2685:2693:2703:2859:2895:2902:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3421:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4361:4425:5007:6117:6119:6261:7514:7875:7903:7974:8603:9025:9108:9177:10004:11658:12740:13137:13139:13149:13150:13230:13231, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: bells73_6b5170156d233 X-Filterd-Recvd-Size: 10277 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf09.hostedemail.com (Postfix) with ESMTPA; Mon, 12 Aug 2019 07:08:57 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4397e3caca35bde3f399315a4e72c1f0" Date: Mon, 12 Aug 2019 09:08:56 +0200 From: Peter van der Stok To: Ines Robles Cc: Alvaro Retana , draft-ietf-roll-aodv-rpl@ietf.org, roll , roll-chairs Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 21:27:02 -0000 --=_4397e3caca35bde3f399315a4e72c1f0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Alvaro, concerning replacement of RFC6997: I don't see anyone deploying both specifications in one installation. As you remarked RFC6997 was recommended in RFC7733 especially om my request. However, things have advanced since, and more options exist to specify short routes between neighbouring nodes without passing through the root. Consequently, the need for RFC6997 has diminished. Moreover, I find it difficult to answer whether aodv-rpl can replace RFC6997 without any efficiency loss. An answer to the last question may be given directly by aodv-rpl authors based on experience? Cheerio, Peter Ines Robles schreef op 2019-08-07 14:09: > Thank you Alvaro for the review, > > The tickets #194, #195, #196, #197, #198 were created to address the > issues [1 [1]]. > > Related to ticket #195 (Document Status), we are going to discuss it into > the ML. > > Best regards, > > Ines. > > [1] https://trac.ietf.org/trac/roll/report/2 > > On Thu, Aug 1, 2019 at 5:54 PM Alvaro Retana wrote: > >> Dear authors: >> >> I just finished reading this document. I am excited about the new >> functionality, but I have several significant issues/questions about the >> document, and a lot of comments (in-line below). >> >> (1) What is AODV-RPL? >> >> Reading the document, my impression of AODV-RPL varies between an >> enhancement to RPL for Reactive Route Discovery (*maybe* in addition to the >> usual proactive routing), to ships-in-the-night reactive-only protocol that >> uses some of the RPL concepts (but not exactly sure which ones). The >> different MOP indicates that it is different from "base" RPL (rfc6550), but >> it is not clear what the assumptions are...and which parts are "inherited" >> from the "base" and which ones are not used. >> >> Another way to ask the same question is: What is the relationship of >> AODV-RPL to RPL? What mechanisms are not applicable with the new MOP? Is >> it expected that an instance of RPL will also be running in the network? >> >> Please be clear early in the document. To quote Charlie: "AODV-RPL is a >> variation on RPL" [1 [1]]. What remains, what changes, etc.. >> >> (2) Document Status (for the Chairs/Shepherd) >> >> I didn't find a specific discussion in the archive about the status of >> this document. Did one take place? At this point I am mostly curious >> given the similarities with rfc6997 (Experimental) and the fact that >> "Future Work" is discussed -- not typical in a Standards Track document. >> IOW, why is this document intended to be a Proposed Standard and not >> Experimental? >> >> (3) Replacing rfc6997?? >> >> This document uses some of the features from rfc6997 (see some comments >> about that in-line), which is fine. The Introduction falls just short of >> saying that this work replaces rfc6997. Should it be considered a >> replacement? I ask mostly in the context of rfc7733 (RPL in Home and >> Building) which mandates (MUST) the use of rfc6997. Should rfc7733 be >> Updated? [I'm just asking the question for it to be considered...I am not >> sure of deployments which conform to rfc7733 or rfc6997...or the impact >> this would have.] >> >> (4) Link checks >> >> The operation of AODV-RPL depend on link checks (§6.2.1/§6.4) to determine >> symmetry and whether it can "fulfill the requirements". But these checks >> are not explained or defined anywhere (are they?) beyond an *example* in >> the Appendix. I think defining the checks is a critical part of the >> specification of the mechanism...specially for a Standards Track protocol Links: ------ [1] https://trac.ietf.org/trac/roll/report/2 --=_4397e3caca35bde3f399315a4e72c1f0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Alvaro,

concerning replacement of RFC6997:

I don't= see anyone deploying both specifications in one installation.
As you = remarked RFC6997 was recommended in RFC7733 especially om my request.
= However, things have advanced since, and more options exist to specify shor= t routes between neighbouring nodes without passing through the root. Conse= quently, the need for RFC6997 has diminished.
Moreover, I find it diff= icult to answer whether aodv-rpl can replace RFC6997 without any efficiency= loss.
An answer to the last question may be given directly by aodv-rp= l authors based on experience?

Cheerio,

Peter

Ines Robles schreef op 2019-08-07 14:09:

= Thank you Alvaro for the review,

The tickets #194, #195, #196,= #197, #198  were created to address the
issues [= 1].

Related to ticket #195 (Document Status), we are going= to discuss it into
the ML.

Best regards,

I= nes.

[1] https://trac.ietf.org/trac/roll/report= /2


On Thu, Aug 1, 2019 at 5:54 PM Alvaro Retana <= ;aretana.ietf@= gmail.com> wrote:

Dear authors:

I just finished reading thi= s document.  I am excited about the new
functionality, but I hav= e several significant issues/questions about the
document, and a lot = of comments (in-line below).

(1) What is AODV-RPL?

Reading the document, my impression of AODV-RPL varies between an
e= nhancement to RPL for Reactive Route Discovery (*maybe* in addition to the<= br /> usual proactive routing), to ships-in-the-night reactive-only protoco= l that
uses some of the RPL concepts (but not exactly sure which ones= ).  The
different MOP indicates that it is different from "base"= RPL (rfc6550), but
it is not clear what the assumptions are...and wh= ich parts are "inherited"
from the "base" and which ones are not used= =2E

Another way to ask the same question is: What is the relat= ionship of
AODV-RPL to RPL?  What mechanisms are not applicable = with the new MOP?  Is
it expected that an instance of RPL will a= lso be running in the network?

Please be clear early in the do= cument.  To quote Charlie: "AODV-RPL is a
variation on RPL" [1].  What remains, what changes, etc..

(2) Document Status (for the Chairs/Shepherd)

I didn't fi= nd a specific discussion in the archive about the status of
this docu= ment.  Did one take place?  At this point I am mostly curious
given the similarities with rfc6997 (Experimental) and the fact that
"Future Work" is discussed -- not typical in a Standards Track document= =2E
IOW, why is this document intended to be a Proposed Standard and = not
Experimental?


(3) Replacing rfc6997??
<= br /> This document uses some of the features from rfc6997 (see some commen= ts
about that in-line), which is fine.  The Introduction falls j= ust short of
saying that this work replaces rfc6997.  Should it = be considered a
replacement?  I ask mostly in the context of rfc= 7733 (RPL in Home and
Building) which mandates (MUST) the use of rfc6= 997.  Should rfc7733 be
Updated?  [I'm just asking the ques= tion for it to be considered...I am not
sure of deployments which con= form to rfc7733 or rfc6997...or the impact
this would have.]

(4) Link checks

The operation of AODV-RPL depend o= n link checks (§6.2.1/§6.4) to determine
symmetry and wheth= er it can "fulfill the requirements".  But these checks
are not = explained or defined anywhere (are they?) beyond an *example* in
the = Appendix.  I think defining the checks is a critical part of the
= specification of the mechanism...specially for a Standards Track protocol<= /blockquote>
--=_4397e3caca35bde3f399315a4e72c1f0-- From nobody Wed Aug 14 10:19:31 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37E2120C1A for ; Wed, 14 Aug 2019 10:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKbCbCbFjUEI for ; Wed, 14 Aug 2019 10:19:28 -0700 (PDT) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 172B912018B for ; Wed, 14 Aug 2019 10:19:28 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id m206so73995659oib.12 for ; Wed, 14 Aug 2019 10:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=5nhvA9WUycg2HDacAJ1GqXpJSmxpCRPDFgqrRRE3iac=; b=kO/9rMhihsuuMSNot7g0ujIbex+ExRK7sS21NS3ZyQTHG+G8L4dy9iKbVpTVDUuCpn aoITuvvd+gh51z/97HIfmorx7e3J5G6jwtR5jme9KU6BuMGy6xsHt/6PQYJZew6680As w78E4ediirbOQfOl8idincZCzh2uizuE7f384TBQ0rD2OY//QcT//x24KwPmztDGozzs 3KyhsSLfl9LzykquKbXWxhaKyWSWRaZeB67UH3QKwhWUSNjaF+zSiUdDTBc9069OEPR+ o5cuW/TO7QsIM/zFvnlv2Ei8VyytPJ2Ry+cLyZSmxnSll2+VD8vf379xKzT2Z3zarNPG NQDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5nhvA9WUycg2HDacAJ1GqXpJSmxpCRPDFgqrRRE3iac=; b=TihghvrHUC/0NSKwD9+zmgKARw/wYAAgFmhPJ79/zMz86ZLfTINg+dTOcMHGMRh5O3 kYGA+VLUuUylsup36v0csqIvhsuAI8YZxJaZO++GdcKOEkcquJxW7hARbUNYjoPHF5fw vDWRf8psKPkx0GwjPNAB3wxN2pDPqOyEOw8cSqvm3Y8MlUaDmgNylX7Y5xwutHUKhzj4 2rxNQWzCMX8jxkwJ5vikFngMmYMU2di6KCXE9LN899EPDo1/GEcyE0tqGyZ3cGBlRQ9Z +Dp8fhEPPZ+OuiQ/3HkvJyBT52InUMuXAkhvnVT8HTZvzYZv6yexUXdHRUKKUfb7r1Gu ic3A== X-Gm-Message-State: APjAAAX7K6ioQhkT8vwbMVL7s2LD+H+GU3/xTILkfh6H5kDpTawAGHi1 YYdaR4d+akdmKXSDY0hrTgUfJSTdv4jOMFV6rWavaOOCZI4= X-Google-Smtp-Source: APXvYqwNzFMPaMZWGYdA3SnXjCV7QKEHUdcKpJTR+8Z2N5EYm1TYTii7eOmVaRU3XXhHyn9+36xmMT/JhjVzbMLAHhA= X-Received: by 2002:a02:708e:: with SMTP id f136mr389924jac.57.1565803166627; Wed, 14 Aug 2019 10:19:26 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Wed, 14 Aug 2019 20:19:15 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000088fa6e059016f5f7" Archived-At: Subject: [Roll] AODV-RPL should be Standard or Experimental? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 17:19:30 -0000 --00000000000088fa6e059016f5f7 Content-Type: text/plain; charset="UTF-8" Dear all, We would like to know your opinion whether AODV-RPL should be Standard or Experimental Track. Source Ticket: https://trac.ietf.org/trac/roll/ticket/195 - Experimental draft description https://tools.ietf.org/html/rfc2026#section-4.2.1, Standard Track description https://tools.ietf.org/html/rfc2026#section-4.1 - The Experimental RFC 6997 describes an approach for Reactive Discovery of P2P Routes. AODV-RPL specifies an approach for reactive P2P route discovery mechanism for hop-by-hop and source routing. Should these two drafts be aligned as Experimental ones? RFC 6997 was made experimental because its deployment future was uncertain. The same may apply to AODV-RPL. When there are sure commitments for deployment of AODV-RPL, we should like to be informed. Thank you very much in advance, Ines and Peter. --00000000000088fa6e059016f5f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear all,


We would like to know your opinion whether AODV-RPL should be Standard or = Experimental Track. Source Ticket: https://trac.ietf.org/trac/roll/ticket/195

- Experimental draft description https://tools.ietf.org/html/rfc2026#section-4.2.1, Standard Track description http= s://tools.ietf.org/html/rfc2026#section-4.1


- The Experimental RFC 6997 describes an approach for = Reactive Discovery of P2P Routes. AODV-RPL specifies an approach for reacti= ve P2P route discovery mechanism for hop-by-hop=C2=A0 and source routing. S= hould these two drafts be aligned as Experimental ones?


RFC 6997 was made experimental because its deplo= yment future was uncertain. The same may apply to AODV-RPL. When=C2=A0 ther= e are sure commitments for deployment of AODV-RPL, we should like to be inf= ormed.


Thank you very much in= advance,


Ines and Peter.


--00000000000088fa6e059016f5f7-- From nobody Thu Aug 15 08:21:19 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765911200B7; Thu, 15 Aug 2019 08:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw6vyTo4dkFk; Thu, 15 Aug 2019 08:21:15 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 3BA0D120090; Thu, 15 Aug 2019 08:21:15 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id g8so2418337edm.6; Thu, 15 Aug 2019 08:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ScNTU6iAyD62URDuxfcEC4OXLuQh3mW9yrWFXfIJC3g=; b=eaDulx7d6lq/enSaWIMhLe46+M9QixMcSoock4+vxsRxbKi7+/yXyAXRqU5kzGBa69 pCt2TvFNqc8LS0tXJ0CQMCG7SF6TxtW6FNFF4GYuyKa5uz7LHMhUll0v/imQ/OfGAu9Y DEu9kq86cHRAyHeq2hXNyDMrMkiQN6LXK1TQixil2c/mTDabh/o37D3JH2K2xvWjv7Rs CddofUsLctgg1h/Wj1LXVxryqIjGIXh88eg08Fu51PKEpOpXFVqfdvBdehyX19tuiv/X MW/hTJUukKZVFEKnHqw7rr7TH4DIJXOw3aZMP7guAHvtRnQ5jxLZMoGwHuV8Z05gcDMl MLmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ScNTU6iAyD62URDuxfcEC4OXLuQh3mW9yrWFXfIJC3g=; b=h7gGf+xnsfpo6ddpo2X3y7mRj+rNxcprmXQI0G8Zujj0pNdtTtJLOn3YiMS450wrS8 OGJhHGuyjXiIJKQ9b3K728HORlxPhOomVl6wubtTPBsItF5rnnOz05HO6Nctls0fA+js g6ZJvi2x51xzBodcM3l6K9ptP73dx0T2U79ISQFgxbNkcRwPZBCPnn8ComKyoAUmhUwj ukjnlX7216Opr2t5SeIlJwm2Le6G/UyiV1Mp1XYtpFN/7wn35CQibiE3kVhS+l1akShJ SvH34so5Zm0RtYofh0D/+BjzENytIs/mW72jSW7aAW1vdK8lXptbDRYhJFO/4ux06j3X iMOw== X-Gm-Message-State: APjAAAXgQ6J/4VTr/7eWlIpDWY5ZjWTcscqdq4B8eEjRoX9PePsIw3+B zPyG1+a0U8W1FJnsameFHsQcGPmN+bQ/4UVM7jzOr8Bv X-Google-Smtp-Source: APXvYqzafwLKnaUyFcNH8kJMVMdJk3mWAhqmjuj4y6hupokx7wDQLkSAotuCNv4NtEnN/lVjcQNuCs9EC3JGmhj6mUE= X-Received: by 2002:a50:93c3:: with SMTP id o61mr5985819eda.87.1565882473701; Thu, 15 Aug 2019 08:21:13 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 15 Aug 2019 11:21:12 -0400 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 15 Aug 2019 11:21:12 -0400 Message-ID: To: Ines Robles , Peter van der Stok , consultancy@vanderstok.org Cc: roll-chairs , roll , draft-ietf-roll-aodv-rpl@ietf.org Content-Type: multipart/alternative; boundary="0000000000009ae4140590296cf4" Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 15:21:18 -0000 --0000000000009ae4140590296cf4 Content-Type: text/plain; charset="UTF-8" Peter: Thanks for the reply! As I said in the review, I was just asking to make sure it was considered. :-) Thanks! Alvaro. On August 12, 2019 at 3:08:58 AM, Peter van der Stok (stokcons@bbhmail.nl) wrote: concerning replacement of RFC6997: I don't see anyone deploying both specifications in one installation. As you remarked RFC6997 was recommended in RFC7733 especially om my request. However, things have advanced since, and more options exist to specify short routes between neighbouring nodes without passing through the root. Consequently, the need for RFC6997 has diminished. Moreover, I find it difficult to answer whether aodv-rpl can replace RFC6997 without any efficiency loss. An answer to the last question may be given directly by aodv-rpl authors based on experience? Cheerio, Peter --0000000000009ae4140590296cf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Peter:

Thanks for the reply!

As I said in the review, I was just asking to make sure it was c= onsidered. :-)

Than= ks!

Alvaro.<= /div>

On August 12, 2019 at 3:08:58 AM, Peter van der Stok (stokcons@bbhmail.nl) wrote:

concerning replacement of RFC6997:

I don't see anyone deploying both s= pecifications in one installation.
As = you remarked RFC6997 was recommended in RFC7733 especially om my request.
However, things have advanced since, an= d more options exist to specify short routes between neighbouring nodes wit= hout passing through the root. Consequently, the need for RFC6997 has dimin= ished.
Moreover, I find it difficult t= o answer whether aodv-rpl can replace RFC6997 without any efficiency loss.<= /span>
An answer to the last question may be = given directly by aodv-rpl authors based on experience?

Cheerio,

Peter
--0000000000009ae4140590296cf4-- From nobody Mon Aug 19 02:49:10 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D2120045 for ; Mon, 19 Aug 2019 02:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=SzNDit1B; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=S6/CDcgK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA-JUQET4G98 for ; Mon, 19 Aug 2019 02:49:06 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9035D12001B for ; Mon, 19 Aug 2019 02:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9586; q=dns/txt; s=iport; t=1566208146; x=1567417746; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZOSOlkRKisiao2Xqnmy5X9X63BtlttxzQaoeWg4Kopw=; b=SzNDit1BWs3HVpi0Nch0Mn0/dEte9mRhHxnYdOTJFPcJVEyZU85vFinS 8x3k06qI+umPrO1LlxhFgsZhDhyUrOg4p1eYNrId+oj2ykZZEkT15wMI2 k+VB1mc1Aov4ed5jaFOc46Ijuby/KXjoOMCCjcqpZzmR7nvaO0GHzEjR/ o=; IronPort-PHdr: =?us-ascii?q?9a23=3AQtYO6Re3whSeseXqtiRssLg0lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAADOb1pd/4cNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBFS9QA21VIAQLKoQfg0cDhFKGJk2CD5MLhFq?= =?us-ascii?q?BLhSBEANUCQEBAQwBASMKAgEBhD8CF4MLIzQJDgIFAQEEAQEDAQYEbYUnDIV?= =?us-ascii?q?KAQEBAQMSEQoTAQE4DwIBCBEEAQErAgICMB0IAgQTCBqDAYEdTQMdAQIMngg?= =?us-ascii?q?CgTiIYXOBMoJ6AQEFgTIBg00YghQDBoE0AYRzhnUXgUA/gRFGgh4uPoJhAQE?= =?us-ascii?q?CAYEmKBIrgl4ygiaPFYUPiQKOLwkCgh2GaIcPhl2YRJU8kCkCBAIEBQIOAQE?= =?us-ascii?q?FgVA4gVhwFYMngkIMF4NPhRSFP3IBAYEnjGEBAQ?= X-IronPort-AV: E=Sophos;i="5.64,403,1559520000"; d="scan'208,217";a="309405350" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Aug 2019 09:49:04 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x7J9n4xx015931 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Aug 2019 09:49:04 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Aug 2019 04:49:03 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 19 Aug 2019 05:49:02 -0400 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 19 Aug 2019 05:49:02 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eflCMLQMZU+gB2CRjgsX528GebP2cREWa3KOGfw4Z9i6NPCPu8Iz+opHYlewjrIEdtIMBH8NvsQoiyE3yqJaCNXr1WQ9ioja5vlT7fJUzbZO4GixbvnAkAOo4YB5o0If1kwAvM+Y11npQNqTNe7qRbGPW+NXzZ+roaDPcyNmlWsJni7NsVO48q9nsGxXgJpIV9U4/BaECwnaFnsWMLUMTtM1muNU5+jJ9pXXw0b9eLcDg3Z0IG5IwHmxNSgwBWtVebYVeh9YRM0LnrbkKK3z3/BXmzYg/2UDiTn7O+uMSnf3vvR5/VUvozQuRoKBlMBBb1c1vQJTXQYm01iv9MPGuw== 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=ZOSOlkRKisiao2Xqnmy5X9X63BtlttxzQaoeWg4Kopw=; b=axRDrcF2Y9D9V7QMKQClyUpxc+jDnL+gT9X+0nBwc6fpDqP15Pnb1Nhc+dyhFhP8z2eLnGKTM/NE31/nigNNVbPBTkpBS7QBzB31CtYd4VT576mPHIF5kxOF09ZmH1H8onEncdOMaYdPghELH/7zaJ1LLtVyKjGwwjBRJwEKg71AHFa3PpeuA0buYDLZRO1aumsQCOvBGy+9W/ffNOwmFtynAtFU5eF3vwAY44PAlAVHkyHI1xW4hmSe7yR485/58C9ZlhZhwGJcooOIxMRE/oG8fZDTQGosVQVpE9S8BlWw5jvsg290eiA96owbKSblPd+WABoMv1FEJOq+p6P2mQ== 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=ZOSOlkRKisiao2Xqnmy5X9X63BtlttxzQaoeWg4Kopw=; b=S6/CDcgKfoBQ3SwCHDHIdk86AiIdR0wxpujMc2Q2wCruIKMMSYM4fnrnE+PZ9fb7RBsrZcvY1OOS56aFWn/uJAbK1pDDzwm79PZvYguEtSd3gwsheoNyHSpSAC/kZzNGT01pGdIebSHnHYw6DlIWpmcIgI+oa6yhtWvRmgol3fI= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4512.namprd11.prod.outlook.com (52.135.38.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Mon, 19 Aug 2019 09:49:01 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2178.018; Mon, 19 Aug 2019 09:49:01 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] AODV-RPL should be Standard or Experimental? Thread-Index: AQHVUsSMpciQkiOqPEygDuHUTjTpd6cCP8dg Date: Mon, 19 Aug 2019 09:48:33 +0000 Deferred-Delivery: Mon, 19 Aug 2019 09:48:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:8170:98a7:7988:d19d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9345df4c-7a48-4c57-ee36-08d7248a76df x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4512; x-ms-traffictypediagnostic: MN2PR11MB4512: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(39860400002)(366004)(376002)(199004)(189003)(966005)(256004)(14444005)(486006)(99286004)(55016002)(33656002)(86362001)(102836004)(6246003)(9686003)(74316002)(5660300002)(186003)(54896002)(52536014)(6436002)(6306002)(53546011)(6506007)(6916009)(7696005)(25786009)(2906002)(76176011)(236005)(53936002)(446003)(7736002)(476003)(229853002)(790700001)(6116002)(11346002)(46003)(316002)(6666004)(606006)(8936002)(478600001)(76116006)(66446008)(71190400001)(66556008)(64756008)(71200400001)(66946007)(8676002)(81156014)(81166006)(14454004)(66574012)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4512; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 9mX2NPEa/izZezR/hBqdbMf5k5hrX84wW5NPQSXYO88bZfuGGnVxkfIG/T67pbaenH0K8mK/AdHJnvlSaOV8wi+1cdtEh/RkszAYhfkF3HeNRXHs692Xr4RHAsqahzt/qk0HjD0XOWku5rYyxRgAJJ+JoEesr3QPRLHoZi+ueMp3lHuY6S49lyv+/4vQaZu/jnr8hQZF/noMe2hfFUKyU7WvgaVQEM26Y7waR/NRvilN/XVFHmxr8B20RJr05ApJSKwOUqhW5WKQ6/qfNmlxGRW1urcl0bHRQP2bKxNKV5Ht/CiKc36DhnCvzGug4fLMAEMGoiHu1pPN9coGs5aH4JFdtlghwcbJNRzd2+NOJ//cWZRRsgQKE1ebE7gIBq+UanG7dA4DaAxGzdwGmJLwnPVmHi0kdLh3zOlikMO36Is= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356510E471E6418A08F141DDD8A80MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9345df4c-7a48-4c57-ee36-08d7248a76df X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2019 09:49:01.3379 (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: SFof57Z+PFRWUbf9yR2Uc+3pBPGtO7YkPrDO1iSWRxLVHJt3594cIwzaulbmQfIobNiS9O0Hg602Ivwqg8RoFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4512 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Roll] AODV-RPL should be Standard or Experimental? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 09:49:09 -0000 --_000_MN2PR11MB356510E471E6418A08F141DDD8A80MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSW5lczoNCg0KUmVsYXVuY2hpbmcgaW4gdGhpcyBjYWxsIHNpbmNlIHlvdSBkaWQgbm90 IGdldCBhbiBhbnN3ZXIuDQpGb3IgbXkgcGFydCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IHJldHVy biBmcm9tIGltcGxlbWVudGF0aW9uIGFuZCB0aHVzIG9mIGNvbW1pdG1lbnRzIGZvciBkZXBsb3lt ZW50IG9mIEFPRFYtUlBMLg0KSeKAmWQgbGlrZSB0byBoZWFyIHNvbWV0aGluZyBkaWZmZXJlbnQg ZnJvbSBhbm90aGVyIHBhcnR5Pw0KDQpBbGwgdGhlIGJlc3QsDQoNClBhc2NhbA0KDQpGcm9tOiBS b2xsIDxyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBJbmVzIFJvYmxlcw0KU2Vu dDogbWVyY3JlZGkgMTQgYW/Du3QgMjAxOSAxOToxOQ0KVG86IHJvbGwgPHJvbGxAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbUm9sbF0gQU9EVi1SUEwgc2hvdWxkIGJlIFN0YW5kYXJkIG9yIEV4cGVyaW1l bnRhbD8NCg0KDQpEZWFyIGFsbCwNCg0KDQpXZSB3b3VsZCBsaWtlIHRvIGtub3cgeW91ciBvcGlu aW9uIHdoZXRoZXIgQU9EVi1SUEwgc2hvdWxkIGJlIFN0YW5kYXJkIG9yIEV4cGVyaW1lbnRhbCBU cmFjay4gU291cmNlIFRpY2tldDogaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvcm9sbC90aWNr ZXQvMTk1DQoNCg0KLSBFeHBlcmltZW50YWwgZHJhZnQgZGVzY3JpcHRpb24gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzIwMjYjc2VjdGlvbi00LjIuMSwgU3RhbmRhcmQgVHJhY2sgZGVz Y3JpcHRpb24gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIwMjYjc2VjdGlvbi00LjEN Cg0KDQotIFRoZSBFeHBlcmltZW50YWwgUkZDIDY5OTcgZGVzY3JpYmVzIGFuIGFwcHJvYWNoIGZv ciBSZWFjdGl2ZSBEaXNjb3Zlcnkgb2YgUDJQIFJvdXRlcy4gQU9EVi1SUEwgc3BlY2lmaWVzIGFu IGFwcHJvYWNoIGZvciByZWFjdGl2ZSBQMlAgcm91dGUgZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3Ig aG9wLWJ5LWhvcCAgYW5kIHNvdXJjZSByb3V0aW5nLiBTaG91bGQgdGhlc2UgdHdvIGRyYWZ0cyBi ZSBhbGlnbmVkIGFzIEV4cGVyaW1lbnRhbCBvbmVzPw0KDQoNClJGQyA2OTk3IHdhcyBtYWRlIGV4 cGVyaW1lbnRhbCBiZWNhdXNlIGl0cyBkZXBsb3ltZW50IGZ1dHVyZSB3YXMgdW5jZXJ0YWluLiBU aGUgc2FtZSBtYXkgYXBwbHkgdG8gQU9EVi1SUEwuIFdoZW4gIHRoZXJlIGFyZSBzdXJlIGNvbW1p dG1lbnRzIGZvciBkZXBsb3ltZW50IG9mIEFPRFYtUlBMLCB3ZSBzaG91bGQgbGlrZSB0byBiZSBp bmZvcm1lZC4NCg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGluIGFkdmFuY2UsDQoNCg0KSW5lcyBh bmQgUGV0ZXIuDQoNCg== --_000_MN2PR11MB356510E471E6418A08F141DDD8A80MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhlbGxvIEluZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbGF1bmNoaW5n IGluIHRoaXMgY2FsbCBzaW5jZSB5b3UgZGlkIG5vdCBnZXQgYW4gYW5zd2VyLiA8bzpwPg0KPC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIG15IHBhcnQgSeKAmW0gbm90IGF3YXJl IG9mIGFueSByZXR1cm4gZnJvbSBpbXBsZW1lbnRhdGlvbiBhbmQgdGh1cyBvZiBjb21taXRtZW50 cyBmb3IgZGVwbG95bWVudCBvZiBBT0RWLVJQTC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPknigJlkIGxpa2UgdG8gaGVhciBzb21ldGhpbmcgZGlmZmVyZW50IGZyb20gYW5v dGhlciBwYXJ0eT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIHRoZSBiZXN0LDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5QYXNjYWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gUm9sbCAmbHQ7cm9sbC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2Yg PC9iPg0KSW5lcyBSb2JsZXM8YnI+DQo8Yj5TZW50OjwvYj4gbWVyY3JlZGkgMTQgYW/Du3QgMjAx OSAxOToxOTxicj4NCjxiPlRvOjwvYj4gcm9sbCAmbHQ7cm9sbEBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW1JvbGxdIEFPRFYtUlBMIHNob3VsZCBiZSBTdGFuZGFyZCBvciBFeHBl cmltZW50YWw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+RGVhciBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XZSB3b3VsZCBsaWtlIHRvIGtub3cgeW91ciBvcGlu aW9uIHdoZXRoZXIgQU9EVi1SUEwgc2hvdWxkIGJlIFN0YW5kYXJkIG9yIEV4cGVyaW1lbnRhbCBU cmFjay4gU291cmNlIFRpY2tldDoNCjxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L3JvbGwvdGlja2V0LzE5NSI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvcm9sbC90aWNrZXQv MTk1PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+LSBFeHBlcmltZW50YWwgZHJhZnQgZGVzY3JpcHRpb24NCjwvc3Bhbj48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjAyNiNzZWN0aW9uLTQuMi4xIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzIwMjYjc2VjdGlvbi00LjIuMTwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiwgU3RhbmRhcmQg VHJhY2sgZGVzY3JpcHRpb24NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMjAyNiNzZWN0aW9uLTQuMSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMy MDI2I3NlY3Rpb24tNC4xPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+LSBUaGUgRXhwZXJpbWVudGFsIFJGQyA2OTk3IGRlc2NyaWJlcyBhbiBh cHByb2FjaCBmb3IgUmVhY3RpdmUgRGlzY292ZXJ5IG9mIFAyUCBSb3V0ZXMuIEFPRFYtUlBMIHNw ZWNpZmllcyBhbiBhcHByb2FjaCBmb3IgcmVhY3RpdmUgUDJQIHJvdXRlIGRpc2NvdmVyeSBtZWNo YW5pc20gZm9yIGhvcC1ieS1ob3AmbmJzcDsNCiBhbmQgc291cmNlIHJvdXRpbmcuIFNob3VsZCB0 aGVzZSB0d28gZHJhZnRzIGJlIGFsaWduZWQgYXMgRXhwZXJpbWVudGFsIG9uZXM/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SRkMgNjk5NyB3YXMg bWFkZSBleHBlcmltZW50YWwgYmVjYXVzZSBpdHMgZGVwbG95bWVudCBmdXR1cmUgd2FzIHVuY2Vy dGFpbi4gVGhlIHNhbWUgbWF5IGFwcGx5IHRvIEFPRFYtUlBMLiBXaGVuJm5ic3A7IHRoZXJlIGFy ZSBzdXJlIGNvbW1pdG1lbnRzIGZvciBkZXBsb3ltZW50IG9mIEFPRFYtUlBMLA0KIHdlIHNob3Vs ZCBsaWtlIHRvIGJlIGluZm9ybWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+VGhhbmsgeW91IHZlcnkgbXVjaCBpbiBhZHZhbmNlLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SW5lcyBhbmQgUGV0 ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB356510E471E6418A08F141DDD8A80MN2PR11MB3565namp_-- From nobody Tue Aug 20 08:23:27 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AAF120955 for ; Tue, 20 Aug 2019 08:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LMe01HIc-g8a for ; Tue, 20 Aug 2019 08:23:23 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4F5120828 for ; Tue, 20 Aug 2019 08:23:23 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id e12so5375002otp.10 for ; Tue, 20 Aug 2019 08:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZuYNSGgX6TRNwkiHfIGqDFQHzscbuzkYM9lZTmvJ4kY=; b=ZhAT+ruMwzmUte6LTq2Jz7WbyeMhJp+RVzuzyRhyT9CLQPRAoL+ZZTPgmJF7HFG1ir oxoXgVN0e++DY0z36Wjaj1PzEQ7aSxAmqd61Ca4I9b1F+jMBKelamtRzCyf8JAZu87Sb 1ynge3JTs58fwl0UoQuL2ht1PxIiS8Fwm0cyWfhFQVXpcLTIYmMZbM/qXkXk+mkjd/7u qJBoqTvJQOt1xI/coLdoGn65NE7jW1nHTkf4F9PcxuHhusZ98jYs4ZUZNLNjckTbuUpW gZtMD/05WbnynV2njYRAc5U6sFQNYNMSJM077xBJE9sZiijKRVFu0jEjgwrMiXVYwEQ3 5DSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZuYNSGgX6TRNwkiHfIGqDFQHzscbuzkYM9lZTmvJ4kY=; b=eHh3G2fmB6PfupZ7e8/arelMfHEirzL1Y75gHyISs0Zmf0KPNj1Eorvn+nX1sSyI9o +j8Kt2Xe/Wj409w6g8zLo2SkK8DWNqtiS8VYcZS8zJJj3zrt2HYSA1Bw+LYx38nEyFJg UcZLYZwyjX1ohIKARqPiarUMBBPBKO8HW141tEiLsn/DXEjnVInw9b02d7jmbt7BeMaA eS3GVF0i9BG7sidU5bseqOt6Y/TZR5LhosNDyFSMkvom1OUhHZN75TrjLzE+Lmdqlw85 z+EXgTQng9l7wFxIG1pK0jJ1NS3lmInbjB5QnW1Gpz7EIRJ53Y1tmQuillYZSSyrcuRY jHIQ== X-Gm-Message-State: APjAAAWER3g2ERcOw+0FLU22+iZuR/LDsXKE8lgT4Jlq+74920mJsnwY M5NJD2bs6HjPp5/NivF9FsvUx94R1rp8sgT9S9qbvVQaXCQmYg== X-Google-Smtp-Source: APXvYqyv34WGrgUvSZzXunraaHTUq405wl5JSUFl731Rqs5O1iOqUDVFbrxLCGqRiEFdxs2nmp+biICc5wPLYIXIzbE= X-Received: by 2002:a9d:390:: with SMTP id f16mr23477754otf.93.1566314602387; Tue, 20 Aug 2019 08:23:22 -0700 (PDT) MIME-Version: 1.0 From: Qiao Xiang Date: Tue, 20 Aug 2019 23:23:11 +0800 Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary="0000000000007b62f205908e094b" Archived-At: Subject: [Roll] CFP: IEEE VNC 2019, December 4-6, 2019, Los Angeles, California X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 15:23:26 -0000 --0000000000007b62f205908e094b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Colleagues, Please accept our apologies if you receive multiple copies of this CFP. ---------------------------------------------------------------------------= ---------------- CALL FOR PAPERS 2019 IEEE Vehicular Networking Conference (VNC) December 4-6, 2019 Los Angeles, California http://www.ieee-vnc.org/cfp.html All submitted papers will be peer-reviewed. A Best Paper Award will be given to a high-impact paper selected by a committee. Accepted papers will appear in the conference proceedings and will be archived in the IEEE Xplore Digital Library. ---------------------------------------------------------------------------= ---------------- The 2019 IEEE Vehicular Networking Conference (VNC) seeks to bring together researchers, professionals, and practitioners to present and discuss recent developments and challenges in vehicular networking technologies, and their applications. Topics of interest include, but are not limited to: - 5G technologies for connected vehicles - Innovative vehicular network applications (e.g., those in transportation safety, efficiency, and comfort as well as electrical vehicle and power grid integration) and their communication requirements - Communications and networking for automated and semi-automated vehicles (e.g., collective perception, sensor data sharing, cooperative driving, cooperative maneuvering, cooperative intersections and highways= , platooning) - Field measurements and/or real-world deployments of vehicular networks and applications - Impact assessments of vehicular networks on transportation (e.g., safety, efficiency, comfort, environmental sustainability) - Modeling, design, as well as theoretical and empirical analysis of vehicular networks and applications - Hardware and software platforms for the simulation, emulation, prototyping, measurement, and/or real-world deployment of vehicular networks and applications - Emerging V2X communication and networking technologies such as cellular V2X (C-V2X), dynamic spectrum sharing, mmWave, massive MIMO, beamforming, and vehicular visible light communications (VLC) - In-vehicle communication and networking systems (e.g., TSN, FlexRay, TT-CAN, and mmWave) - Vehicular networking architectures and system design - Novel physical layer communication technologies for vehicular networks - Radio propagation aspects of vehicular networks (e.g., channel measurements, propagation models, antenna design) - Vehicular MAC and link layer protocols (e.g., those for URLLC) - Vehicular network layer protocols (e.g., real-time information dissemination) - Transport control and middleware for vehicular network systems (e.g., congestion control, real-time messaging) - Heterogeneous vehicular networking (e.g., multi-radio, multi-channel, multi-application, multi-technology) - Network and QoS management for vehicular networks - Security, privacy, liability, and dependability of vehicular networks - Communications related to electric and hybrid vehicles - Integration of V2C with on-board systems and networks - Edge computing for vehicular applications - Vehicular networks and IoT integration ------------------------------------------------------------ ------------------------------- Important Dates Full/short paper submission deadline:September 15, 2019, 23:59 AOE (Anywhere on Earth, UTC-12) Demo/Poster paper Submission Deadline:September 30, 2019, 23:59 AOE (Anywhere on Earth, UTC-12) Acceptance notification:October 22, 2019 Camera ready paper due:November 4, 2019 Conference:December 4-6, 2019 ------------------------------------------------------------ ------------------------------- Organizing CommitteeGeneral Co-Chairs Danijela Cabric, UCLA, USA Onur Altintas, Toyota InfoTech Labs, USA TPC Co-Chairs Tim Leinmueller, DENSO International Europe, Germany Hongwei Zhang, Iowa State University, USA Poster/Demo and Student Travel Grant Co-Chairs Ashwin Ashok, Georgia State University, USA Miguel Sepulcre, Universidad Miguel Hern=C3=A1ndez de Elche, Spain Panel Chair Jim Lansford, Qualcomm, USA Publication Chair Takamasa Higuchi, Toyota InfoTech Labs, USA Publicity Co-Chairs Sinem Coleri Ergen, Koc University, Turkey Qiao Xiang, Yale University, USA Web Co-Chairs Seyhan Ucar, Toyota InfoTech Labs, USA Enes Krijestorac, UCLA, USA Local Arrangement Co-Chairs Benjamin Domae, UCLA, USA Enes Krijestorac, UCLA, USA Finance Chair Bruce Worthman, IEEE Steering Committee Onur Altintas, Toyota InfoTech Labs, USA Wai Chen, China Mobile Research Institute, China Falko Dressler, University of Paderborn, Germany Geert Heijenk, University of Twente, The Netherlands Thomas Luckenbach, FOKUS, Germany Hyun Seo Oh, ETRI, South Korea Umit Ozguner, Ohio State University, USA Tadao Saito, Professor Emeritus, The University of Tokyo, Japan --=20 Qiao Xiang Associate Research Scientist, Department of Computer Science, Yale University --0000000000007b62f205908e094b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,

Please accept our apologies if you= receive multiple copies of this CFP.
----------------------------------= ---------------------------------------------------------
CALL FOR PAPER= S
2019 IEEE Vehicular Networking Conference (VNC)
December 4-6, 2019<= br>Los Angeles, California
= http://www.ieee-vnc.org/cfp.html

All submitted papers will be pe= er-reviewed. A Best Paper Award will be
given to a high-impact paper sel= ected by a committee. Accepted papers will
appear in the conference proc= eedings and will be archived in the IEEE
Xplore Digital Library.

= ---------------------------------------------------------------------------= ----------------

The 2019 IEEE Vehicular Networking Conference (VNC)= seeks to bring together
researchers, professionals, and practitioners t= o present and discuss recent
developments and challenges in vehicular ne= tworking technologies, and their
applications. Topics of interest includ= e, but are not limited to:

=C2=A0 =C2=A0- 5G technologies for connec= ted vehicles
=C2=A0 =C2=A0- Innovative vehicular network applications (e= .g., those in
=C2=A0 =C2=A0transportation safety, efficiency, and comfor= t as well as electrical
=C2=A0 =C2=A0vehicle and power grid integration)= and their communication requirements
=C2=A0 =C2=A0- Communications and = networking for automated and semi-automated
=C2=A0 =C2=A0vehicles (e.g.,= collective perception, sensor data sharing, cooperative
=C2=A0 =C2=A0dr= iving, cooperative maneuvering, cooperative intersections and highways,
= =C2=A0 =C2=A0platooning)
=C2=A0 =C2=A0- Field measurements and/or real-w= orld deployments of vehicular networks
=C2=A0 =C2=A0and applications
= =C2=A0 =C2=A0- Impact assessments of vehicular networks on transportation (= e.g.,
=C2=A0 =C2=A0safety, efficiency, comfort, environmental sustainabi= lity)
=C2=A0 =C2=A0- Modeling, design, as well as theoretical and empiri= cal analysis of
=C2=A0 =C2=A0vehicular networks and applications
=C2= =A0 =C2=A0- Hardware and software platforms for the simulation, emulation,<= br>=C2=A0 =C2=A0prototyping, measurement, and/or real-world deployment of v= ehicular
=C2=A0 =C2=A0networks and applications
=C2=A0 =C2=A0- Emergi= ng V2X communication and networking technologies such as
=C2=A0 =C2=A0ce= llular V2X (C-V2X), dynamic spectrum sharing, mmWave, massive MIMO,
=C2= =A0 =C2=A0beamforming, and vehicular visible light communications (VLC)
= =C2=A0 =C2=A0- In-vehicle communication and networking systems (e.g., TSN, = FlexRay,
=C2=A0 =C2=A0TT-CAN, and mmWave)
=C2=A0 =C2=A0- Vehicular ne= tworking architectures and system design
=C2=A0 =C2=A0- Novel physical l= ayer communication technologies for vehicular networks
=C2=A0 =C2=A0- Ra= dio propagation aspects of vehicular networks (e.g., channel
=C2=A0 =C2= =A0measurements, propagation models, antenna design)
=C2=A0 =C2=A0- Vehi= cular MAC and link layer protocols (e.g., those for URLLC)
=C2=A0 =C2=A0= - Vehicular network layer protocols (e.g., real-time information
=C2=A0 = =C2=A0dissemination)
=C2=A0 =C2=A0- Transport control and middleware for= vehicular network systems (e.g.,
=C2=A0 =C2=A0congestion control, real-= time messaging)
=C2=A0 =C2=A0- Heterogeneous vehicular networking (e.g.,= multi-radio, multi-channel,
=C2=A0 =C2=A0multi-application, multi-techn= ology)
=C2=A0 =C2=A0- Network and QoS management for vehicular networks<= br>=C2=A0 =C2=A0- Security, privacy, liability, and dependability of vehicu= lar networks
=C2=A0 =C2=A0- Communications related to electric and hybri= d vehicles
=C2=A0 =C2=A0- Integration of V2C with on-board systems and n= etworks
=C2=A0 =C2=A0- Edge computing for vehicular applications
=C2= =A0 =C2=A0- Vehicular networks and IoT integration

-----------------= -------------------------------------------
----------------------------= ---

Important Dates
Full/short paper submission deadline:Septembe= r 15, 2019, 23:59 AOE
(Anywhere on Earth, UTC-12)
Demo/Poster paper S= ubmission Deadline:September 30, 2019, 23:59 AOE
(Anywhere on Earth, UTC= -12)
Acceptance notification:October 22, 2019
Camera ready paper due:= November 4, 2019
Conference:December 4-6, 2019
----------------------= --------------------------------------
-------------------------------Organizing CommitteeGeneral Co-Chairs

Danijela Cabric, UCLA, USAOnur Altintas, Toyota InfoTech Labs, USA
TPC Co-Chairs

Tim Lein= mueller, DENSO International Europe, Germany
Hongwei Zhang, Iowa State U= niversity, USA
Poster/Demo and Student Travel Grant Co-Chairs

Ash= win Ashok, Georgia State University, USA
Miguel Sepulcre, Universidad Mi= guel Hern=C3=A1ndez de Elche, Spain
Panel Chair

Jim Lansford, Qua= lcomm, USA
Publication Chair

Takamasa Higuchi, Toyota InfoTech La= bs, USA
Publicity Co-Chairs

Sinem Coleri Ergen, Koc University, T= urkey
Qiao Xiang, Yale University, USA
Web Co-Chairs

Seyhan Uc= ar, Toyota InfoTech Labs, USA
Enes Krijestorac, UCLA, USA
Local Arran= gement Co-Chairs

Benjamin Domae, UCLA, USA
Enes Krijestorac, UCLA= , USA
Finance Chair

Bruce Worthman, IEEE
Steering Committee
Onur Altintas, Toyota InfoTech Labs, USA
Wai Chen, China Mobile Res= earch Institute, China
Falko Dressler, University of Paderborn, Germany<= br>Geert Heijenk, University of Twente, The Netherlands
Thomas Luckenbac= h, FOKUS, Germany
Hyun Seo Oh, ETRI, South Korea
Umit Ozguner, Ohio S= tate University, USA
Tadao Saito, Professor Emeritus, The University of = Tokyo, Japan



= --
Qiao Xiang
Associate Research Scientist,=C2=A0
=
Department of Computer Science,
Yale University
--0000000000007b62f205908e094b-- From nobody Fri Aug 23 02:43:32 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2B1120132 for ; Fri, 23 Aug 2019 02:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=QHrwrLgi; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AhiFNYIU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA4Xy5GDvt9A for ; Fri, 23 Aug 2019 02:43:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A335120115 for ; Fri, 23 Aug 2019 02:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7244; q=dns/txt; s=iport; t=1566553407; x=1567763007; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1AzAdrcBzjBy8i9y2XosBz86uBIevobtAAyPQ1S17EY=; b=QHrwrLgiYKQMXGDVcLZ7qK0ErDcUGzOzrDIzbXsz1tASlXPKZaC3ISBx omqYuIRrklyeTmLypqg/eAPoimrIQqxqz4NhIw1Z4V/SE4l6tdNtewCDj IcotIYFYi9QYZX3phgwvuAxetIEG+jX7VOSOEzu0+Z3uBrsaUnuwwyfCY w=; IronPort-PHdr: =?us-ascii?q?9a23=3AZZp7shO2EtwydgspjUwl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjMP73ZSEgAOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAABqtF9d/51dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBFS8kLANtViAECyqHZwOEUoYbglyQB4MCA4J?= =?us-ascii?q?aggGBLhSBEANUCQEBAQwBASUIAgEBhD8CgmUjNAkOAgoBAQQBAQMBBgRthS0?= =?us-ascii?q?MhUoBAQEBAxILEBMBATgPAgEIEQQBAS8yHQgBAQQTCBqDAYEdTQMdAQIMn3o?= =?us-ascii?q?CgTiIYYIlgnsBAQWFIRiCFgMGgTQBi24YgUA/gRFGgkw+gmEBAQIBgSYcHiu?= =?us-ascii?q?DEIImlCmXPAkCgh2GaocThl2CMocwjmqVSYxbg1gCBAIEBQIOAQEFgVA4gVh?= =?us-ascii?q?wFYMngkKDcoUUhT9yAYEoiyABAQ?= X-IronPort-AV: E=Sophos;i="5.64,420,1559520000"; d="scan'208,217";a="619985629" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Aug 2019 09:43:26 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x7N9hQJw014037 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Aug 2019 09:43:26 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 23 Aug 2019 04:43:26 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 23 Aug 2019 05:43:25 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 23 Aug 2019 04:43:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MhX+6A4sML62WT1E5YyFd4czbBEP7zPROW0P3s4TUT/VaE04HjgZ0Lf55uUpGxoeVX3hrI8Sd18KvnIWQ/N9M85DFOFYycZRZjkswq3lzLixu4RpKylNRtGGaubC2uE3oR9fvDnijzidXrD6iQYGdtawaNINto93tmp4YnbN+F9Rp6FddB0q/5IHnnoqlreNe6XG0S9YCTwsZY2F+Td7SRiPvXZD/Aju0wi4g94lBwoMXaQJwQZ68UppwOriD94oYR4YHh0lVtyHVvbAW4ERfhvgn5BxnkIfxFniPEwU4kWpBX1ut9VICbMc4QsOsLRb7sweI3yDSN6/uWpEnHQDLQ== 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=bjuKwJmmWKXqgbnJlpAt46jhEfHQbYEBsaD5DzXR6IM=; b=GLdFvUqa7+jt29OlabtNYbasGXKjEe0vLLdA9crHAF87HBW/tC+NvHxr04ldIXoeqrzI4SyZclvWj7bwGPGgfxzRaWdw5YRk6hOraVxCflINp/UPbmcA7py1+bsgbmXXugEx3xbQ+HBp7rVS3ul/HLB3rpuJlqchMp3oV3aC8BwwnfN+O68Kz0p/E+KmlWANLV7MSJhpHYuNROJa24qIEOTKVdU8U6stpiJ7/ZDgqX7BNsjfYfFIVGerOru1CXyA+3nHwDmqoNzYMU5CvwaKSU+L1IHyxnxMJQCxhycuwt+98VnCTxozud1ILfd3WVcSHl6i9GnzGdSBmEb3IZovaQ== 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=bjuKwJmmWKXqgbnJlpAt46jhEfHQbYEBsaD5DzXR6IM=; b=AhiFNYIUISIYpwwgFStL/yMMAn0sCJi3bwdX/IUjZKIlh1ygoiQ9/WVLBzsZGyXFowM7neBWmijhUcNkznY/cxvT8LifFQ0+XaaRmSXQ+YZ3+dQQbCz7MKf96aIHsK37fWVa7kv3ygzxmcS0rtyFY+6M9pT7CRGTqMz7tegFbgE= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3789.namprd11.prod.outlook.com (20.178.252.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.19; Fri, 23 Aug 2019 09:43:23 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2178.020; Fri, 23 Aug 2019 09:43:23 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Add ROVR in DAO? Thread-Index: AdVCahRZPRQ6beNIQb+VlVo9l/YWKAXLCFRQ Date: Fri, 23 Aug 2019 09:43:16 +0000 Deferred-Delivery: Fri, 23 Aug 2019 09:42:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1007::143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e6aeec17-da7d-4b01-f9e2-08d727ae574f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3789; x-ms-traffictypediagnostic: MN2PR11MB3789: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0138CD935C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(346002)(376002)(366004)(199004)(189003)(7736002)(606006)(66476007)(76116006)(53936002)(66946007)(66556008)(64756008)(66446008)(46003)(6246003)(33656002)(446003)(11346002)(229853002)(486006)(476003)(186003)(74316002)(86362001)(71200400001)(14444005)(71190400001)(256004)(6666004)(790700001)(6116002)(6916009)(2906002)(14454004)(8676002)(81156014)(81166006)(3480700005)(76176011)(7696005)(316002)(966005)(8936002)(478600001)(99286004)(53546011)(6506007)(102836004)(52536014)(5660300002)(25786009)(6306002)(9686003)(55016002)(6436002)(54896002)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3789; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QJx9mIz19zY2ZaU0mC50WxvdofH+poBSp1sz0rMcpFBShfDQcXenYM0EZbspjuIfOaxGeR6+lN88ii6E9a9BHHyzssOVaTqVlu9f0IZSNJYsYDtG4pryjZVe1v/U+ZVECqn8LuCgCt66fMB0cpZ4O/WYWQa4i+6NKIk8cCMizfMWaGonLsKAsR1WeUMueNFBUUGDAFFMklzyKX1wXB+AI8JOZZlur98mqW/9eOB2sHX5FptrfZj3XdgeHCrUDfp/tnIafw8jQB+QSRI+lJEXIAlFDK4FHFSIlXc+kxXMM8JuXFiQLhZoy2nsNuW2Kvu1tGbC06C+QgPHDIYmnr6BVYA3XNC2xF7VwDze7ovxS0GjySedRRH0nNWnZL7cXZHRxJQ8R9dHHpSzQc67FacQ2PHef7SPeqXDLSDq9R7g3Cs= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35653048AE54B21CCF055031D8A40MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e6aeec17-da7d-4b01-f9e2-08d727ae574f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2019 09:43:23.7307 (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: ic320HH1UWVGmrzHVJ1brTxrFrE1boAutOUYq7z8pm/VCBU8qQnEch0kphJ3zyknDnAacKTFuwQJC6JF9eWIYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3789 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Roll] Add ROVR in DAO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 09:43:30 -0000 --_000_MN2PR11MB35653048AE54B21CCF055031D8A40MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all As noted below, and discussed at the WG meeting at IETF 105, it would be go= od to convey the ROVR field in the DAO, so if the Root and the 6LBR are dif= ferent entities then the root can build a full EDAR as opposed to the dummy= one. It will also help make RPL more secure in the future. So I'm calling to con= firm the discussion in Montreal and if there is no opposition I'll go ahead= and propose a new option that can be placed with the DAO to transport a RO= VR. We'll also need something in the configuration option to trigger its use. Comments and any hint on how to do that right are welcome. All the best; Pascal From: Roll On Behalf Of Pascal Thubert (pthubert) Sent: mercredi 24 juillet 2019 23:54 To: Routing Over Low power and Lossy networks Subject: [Roll] Add ROVR in DAO? Dear all The only change I foresee in the unaware leaves draft is the addition of th= e RFC 8505 ROVR from the ND EARO into the DAO. After that I'd feel ready to= call for WGLC. The proposed change enables to build a full EDAR message at the root, and a= voids the weird processing of the keep-alive EDAR (see https://tools.ietf.o= rg/html/draft-ietf-roll-unaware-leaves-02#section-7.4) If we do it now we can forget that weird format (all ones ROVR) and never c= ode for it. This may also be useful when we work on securing the DAO using = the AP ND proof of ownership all the way to the root.. Please let me know if there's disagreement to make that change All the best Pascal --_000_MN2PR11MB35653048AE54B21CCF055031D8A40MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all

 

As noted below, and discussed at the WG meeting at I= ETF 105, it would be good to convey the ROVR field in the DAO, so if the Ro= ot and the 6LBR are different entities then the root can build a full EDAR = as opposed to the dummy one.

It will also help make RPL more secure in the future= . So I’m calling to confirm the discussion in Montreal and if there i= s no opposition I’ll go ahead and propose a new option that can be pl= aced with the DAO to transport a ROVR.

We’ll also need something in the configuration= option to trigger its use.

 

Comments and any hint on how to do that right are we= lcome.

 

All the best;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> O= n Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 24 juillet 2019 23:54
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] Add ROVR in DAO?

 

Dear all

 

The only change I foresee in the unaware leaves draf= t is the addition of the RFC 8505 ROVR from the ND EARO into the DAO. After= that I’d feel ready to call for WGLC.

 

The proposed change enables to build a full EDAR mes= sage at the root, and avoids the weird processing of the keep-alive EDAR (s= ee https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-02#section-7.4)

If we do it now we can forget that weird format (all= ones ROVR) and never code for it. This may also be useful when we work on = securing the DAO using the AP ND proof of ownership all the way to the root= ..

 

Please let me know if there’s disagreement to = make that change

 

All the best

 

Pascal

 

 

 

 

 

--_000_MN2PR11MB35653048AE54B21CCF055031D8A40MN2PR11MB3565namp_-- From nobody Fri Aug 23 07:34:25 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090DF12085A for ; Fri, 23 Aug 2019 07:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yUj4o3ZNLp3 for ; Fri, 23 Aug 2019 07:34:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02803120868 for ; Fri, 23 Aug 2019 07:34:19 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 49EE451AAD9075A588CD for ; Fri, 23 Aug 2019 15:34:15 +0100 (IST) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 23 Aug 2019 15:34:14 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.145]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0439.000; Fri, 23 Aug 2019 20:04:06 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: Add ROVR in DAO? Thread-Index: AdVCahRZPRQ6beNIQb+VlVo9l/YWKAXLCFRQAAlc/SA= Date: Fri, 23 Aug 2019 14:34:05 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DFB6CBE@BLREML503-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DFB6CBEBLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Add ROVR in DAO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 14:34:23 -0000 --_000_982B626E107E334DBE601D979F31785C5DFB6CBEBLREML503MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pascal, As I understand the proposal is to: 1. Remove the ROVR generation on the 6LBR on behalf of the 6LN. 2. Use the ROVR from NS(EARO) directly in the DAO. 3. This would eliminate Keep-Alive EDAR/EDAC during initial/first reg= istration. 4. This would eliminate the need for root node to set all ones in the= ROVR field of keep-alive EDAR. This seems optimal. But there is one downside if the DAO is used for such purpose; Adding a 64-= bit ROVR field in DAO would mean that in storing MOP all the parents mainta= in the ROVR field in their routing table. This is an immense overhead, sinc= e it impacts the routing entry size even if the RPL network needs to suppor= t just a single RUL. Another question I have is,... In the Figure 2, EDAR is sent to 6LBR and DA= O is sent to the Root. As I understand the DODAGID in the DIO will be the g= lobal IPv6 address of the Root (and not 6LBR) and thus DAO can be addressed= to the Root. But how does 6LR get the address of the 6LBR to send the EDAR= ? (assuming in this case the Root and 6LBR are different network entities).= Also it would be better to differentiate Root and 6LBR in the terminology = section. Regards, Rahul From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthu= bert) Sent: 23 August 2019 17:43 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Add ROVR in DAO? Dear all As noted below, and discussed at the WG meeting at IETF 105, it would be go= od to convey the ROVR field in the DAO, so if the Root and the 6LBR are dif= ferent entities then the root can build a full EDAR as opposed to the dummy= one. It will also help make RPL more secure in the future.. So I'm calling to co= nfirm the discussion in Montreal and if there is no opposition I'll go ahea= d and propose a new option that can be placed with the DAO to transport a R= OVR. We'll also need something in the configuration option to trigger its use. Comments and any hint on how to do that right are welcome. All the best; Pascal From: Roll > On Behalf = Of Pascal Thubert (pthubert) Sent: mercredi 24 juillet 2019 23:54 To: Routing Over Low power and Lossy networks > Subject: [Roll] Add ROVR in DAO? Dear all The only change I foresee in the unaware leaves draft is the addition of th= e RFC 8505 ROVR from the ND EARO into the DAO. After that I'd feel ready to= call for WGLC. The proposed change enables to build a full EDAR message at the root, and a= voids the weird processing of the keep-alive EDAR (see https://tools.ietf.o= rg/html/draft-ietf-roll-unaware-leaves-02#section-7.4) If we do it now we can forget that weird format (all ones ROVR) and never c= ode for it. This may also be useful when we work on securing the DAO using = the AP ND proof of ownership all the way to the root... Please let me know if there's disagreement to make that change All the best Pascal --_000_982B626E107E334DBE601D979F31785C5DFB6CBEBLREML503MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,<= /span>

 

As I understand the pr= oposal is to:

1.&= nbsp;      Remove the ROV= R generation on the 6LBR on behalf of the 6LN.

2.&= nbsp;      Use the ROVR f= rom NS(EARO) directly in the DAO.

3.&= nbsp;      This would eli= minate Keep-Alive EDAR/EDAC during initial/first registration.

4.&= nbsp;      This would eli= minate the need for root node to set all ones in the ROVR field of keep-ali= ve EDAR.

This seems optimal.

But there is one downs= ide if the DAO is used for such purpose; Adding a 64-bit ROVR field in DAO = would mean that in storing MOP all the parents maintain the ROVR field in their routing = table. This is an immense overhead, since it impacts the routing entry = size even if the RPL network needs to support just a single RUL.=

 

Another question I hav= e is,… In the Figure 2, EDAR is sent to 6LBR and DAO is sent to the R= oot. As I understand the DODAGID in the DIO will be the global IPv6 address= of the Root (and not 6LBR) and thus DAO can be addressed to the Root. But how does 6LR get the address of the 6LBR to = send the EDAR? (assuming in this case the Root and 6LBR are different netwo= rk entities). Also it would be better to differentiate Root and 6LBR in the= terminology section.

 

Regards,

Rahul

 

From: Roll [mailto:roll-bounces@ietf.org] = On Behalf Of Pascal Thubert (pthubert)
Sent: 23 August 2019 17:43
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] Add ROVR in DAO?

 

Dear all

 

As noted below, and discussed at the WG meeting at I= ETF 105, it would be good to convey the ROVR field in the DAO, so if the Ro= ot and the 6LBR are different entities then the root can build a full EDAR = as opposed to the dummy one.

It will also help make RPL more secure in the future= .. So I’m calling to confirm the discussion in Montreal and if there = is no opposition I’ll go ahead and propose a new option that can be p= laced with the DAO to transport a ROVR.

We’ll also need something in the configuration= option to trigger its use.

 

Comments and any hint on how to do that right are we= lcome.

 

All the best;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 24 juillet 2019 23:54
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] Add ROVR in DAO?

 

Dear all

 

The only change I foresee in the unaware leaves draf= t is the addition of the RFC 8505 ROVR from the ND EARO into the DAO. After= that I’d feel ready to call for WGLC.

 

The proposed change enables to build a full EDAR mes= sage at the root, and avoids the weird processing of the keep-alive EDAR (s= ee https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-02#section-7.4)

If we do it now we can forget that weird format (all= ones ROVR) and never code for it. This may also be useful when we work on = securing the DAO using the AP ND proof of ownership all the way to the root= ...

 

Please let me know if there’s disagreement to = make that change

 

All the best

 

Pascal

 

 

 

 

 

--_000_982B626E107E334DBE601D979F31785C5DFB6CBEBLREML503MBXchi_-- From nobody Fri Aug 23 07:56:10 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29D1120840 for ; Fri, 23 Aug 2019 07:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=U3+5y/Mq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HuEIT3HD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPCDps-haq1w for ; Fri, 23 Aug 2019 07:56:05 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43341200E9 for ; Fri, 23 Aug 2019 07:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20713; q=dns/txt; s=iport; t=1566572165; x=1567781765; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=81nbcIjgamw85GqFO21tt8n57PGOf2M7m5421LkAXqo=; b=U3+5y/MqLEYEjCJzq36/8h4L/JsMux8EC+Aen/TadgHLU4hs0nveRhvb YfR4/SW4JWWdZGi7ckzr4Or31kQJwtRofH7Y50KLZAMkZiMouYDxgxH0w 9Fz1S+rceAOvsyBosS16g8OBXtJ5KorNIQCHtFjPdTzNIsAy5oFMg0C3l U=; IronPort-PHdr: =?us-ascii?q?9a23=3AwjBa9BwNdXyFR3rXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAABq/V9d/5RdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVQMBAQEBCwGBFS8kLANtViAECyqHZwOKbU2CD5AHhV+CAYE?= =?us-ascii?q?uFIEQA1QJAQEBDAEBJQgCAQGEPwKCZyM2Bw4CCgEBBAEBAQIBBgRthS0MhUo?= =?us-ascii?q?BAQEEEgsQEwEBOA8CAQgRBAEBIQcHMhQJCAEBBBMIGoMBgR1NAx0BAgygVQK?= =?us-ascii?q?BOIhhgiWCewEBBYUjGIIWAwaBNAGEeYZ1GIFAP4ERRlF9fj6CYQEBAgGBJhg?= =?us-ascii?q?BAQIeKwmDB4ImlC2JCI42CQKCHYZqhxOGYYIyhzCKTYQflVCMYINZAgQCBAU?= =?us-ascii?q?CDgEBBYFXAy6BWHAVgyeCQoNyhRSFP3IBgSiLP4JDAQE?= X-IronPort-AV: E=Sophos;i="5.64,421,1559520000"; d="scan'208,217";a="313277757" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Aug 2019 14:56:04 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x7NEu4kh013382 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Aug 2019 14:56:04 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 23 Aug 2019 09:56:03 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 23 Aug 2019 10:55:55 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 23 Aug 2019 09:55:54 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NcWfQGhlWFG1IG1nBifzr/7hVLA3ydNvoUNWfc/720tfkzyUYWs+lDJK5GytpWu15HTtaGcNfstE/fyhUHJUdGQdl5QUZt3CEXhjAZsk6+pccjS6XHNOVhucueXI3maUsr8kH61RFVKGq4tUCeqq8QHnVgi+8OzkVQ4ckvZxQnWddvlnOie1lnIwof+CuSsafy+iY22MortN/1QFQ/HIcwU1rfnJjZHZlE/VB8BenwJ+99llVFafruomxcH+CRqF2iTCGqc0VegpIk6+CYHQqcLzdl5e2A1UN0j67doVq/iASWxzKieNkx8jyiooz+X7XB/DjR5Ci4xJp+QLQXk6rg== 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=p5l/E9rc4+A7CKPXNopKx7hMTBOVtdu6CT+Z15jwukE=; b=FLVHMdjr+6e1C0CHdKd7v5OEwOm+znvGN7Jo6NqUUStRoWv++m+XPYNhuGt0FeQEW5SunOgr1yTeF5Or9qKSmOhVBxCrlUjMbcoXqq5XD24C3iUQjgZjBVdIj9Z066hkYPOijhZ6THJk9Jxnq1+NzXC0bjq8XqX8gAzlwA56bBnc02zfyC21GyVXhysRTGRcm/qia9ukJbgc2+W1BiwMi3/AZEqnQ2Uojh4WNuiWP8GZA+lYTxRh1Z2kemjIk0mYPjB2xYHoI+JM1VQTMU2Q1VUBq23loHLCGtQ9OELyj4BAYaRzfzVZ3k0l+AfCcfZlDv+86U9vgaIlqQmDaerHhw== 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=p5l/E9rc4+A7CKPXNopKx7hMTBOVtdu6CT+Z15jwukE=; b=HuEIT3HDwX0iCdozLOj/NC8p3XZOfmzC7tSbS8JqYLuP9a2p73dBkmBXzztO29/MjhWduDZ9ACB6HhhSprjXZmm7UYrN1IqaCBkpvHu+f0X9TRg1dXiJnsDf70INNYhpWBoi3WanPKE1LrhBYF2wN730XEzewfB8Jk96El13qEY= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4095.namprd11.prod.outlook.com (20.179.150.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Fri, 23 Aug 2019 14:55:53 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2178.020; Fri, 23 Aug 2019 14:55:53 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Add ROVR in DAO? Thread-Index: AdVCahRZPRQ6beNIQb+VlVo9l/YWKAXLCFRQAAlc/SAAAVIeIA== Date: Fri, 23 Aug 2019 14:55:42 +0000 Deferred-Delivery: Fri, 23 Aug 2019 14:55:28 +0000 Message-ID: References: <982B626E107E334DBE601D979F31785C5DFB6CBE@BLREML503-MBX.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB6CBE@BLREML503-MBX.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1007::143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d33bba29-eb79-44cc-a468-08d727d9ff26 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4095; x-ms-traffictypediagnostic: MN2PR11MB4095: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0138CD935C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(39860400002)(366004)(396003)(189003)(199004)(966005)(66946007)(7736002)(81156014)(8936002)(8676002)(81166006)(6246003)(486006)(54896002)(561944003)(25786009)(6306002)(7696005)(53936002)(6916009)(52536014)(3480700005)(229853002)(14444005)(14454004)(5660300002)(76176011)(2906002)(6506007)(55016002)(790700001)(6436002)(476003)(53546011)(66446008)(64756008)(66556008)(74316002)(102836004)(9686003)(66476007)(71190400001)(256004)(478600001)(71200400001)(6666004)(33656002)(186003)(236005)(446003)(99286004)(316002)(46003)(76116006)(11346002)(86362001)(6116002)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4095; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QOt0ZOH32UqhnrIiJjbjzri4MNdRY/4Teb/m9BEjWvSLV2qDeSjcarFVMTGTgSeEv1iFo1xBmeUaNgN78tEntnSTcQjSDdCA8SE2CqMJrNgc0K6hm1pf99bLK0EpZMYbLDRteb7GbMzpb9ENttLIgGcsyGeWe5V10iTvd4+QSj2pObBSiqmDfgBYa9XfF4dv5et5QaGyBtlIg6EvuWu028YNwOQccoWsVHGugR3zvVNoHcRZivYIGwn4nlmrP4aCsCd+yB3KslWije5WdsF4UTYEj2Vi9NkuXOOj554IbE8MdeWKkPhrnJbq1DJ7H5W14o8TX5JvRi8AG5q0kJqbdGEoeIOQjl2LzTgFyt/QSxKLLNUbErpDolgslgVvIXV6EivaL4BRiTpoqR/PJgJ5PGqqgadsCE0ceDTVtd9Q9rQ= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565FCB9B09EACB427368E96D8A40MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d33bba29-eb79-44cc-a468-08d727d9ff26 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2019 14:55:53.7274 (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: Jso07cckYCWAqodU/jwDw323g44RE+bR9CGhCeE9ye1LuXum0O9pIWVraXYwsTw26WWNm+k3H5k4Nhof/WDUNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4095 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Roll] Add ROVR in DAO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 14:56:09 -0000 --_000_MN2PR11MB3565FCB9B09EACB427368E96D8A40MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rahul and all Please see below As I understand the proposal is to: 1. Remove the ROVR generation on the 6LBR on behalf of the 6LN. ? Not that. The ROVR is never generated by the 6LBR 1. Use the ROVR from NS(EARO) directly in the DAO. 2. This would eliminate Keep-Alive EDAR/EDAC during initial/first regist= ration. ? Actually we keep it in the first because it happens before RPL and pro= vides DAD. But yes for all the subsequent. 1. This would eliminate the need for root node to set all ones in the RO= VR field of keep-alive EDAR. ? Exactly This seems optimal. ? So far But there is one downside if the DAO is used for such purpose; Adding a 64-= bit ROVR field in DAO would mean that in storing MOP all the parents mainta= in the ROVR field in their routing table. This is an immense overhead, sinc= e it impacts the routing entry size even if the RPL network needs to suppor= t just a single RUL. ? Yes. It is an additional 64 to 512 bits which limits the size of the r= outing table. Immense is a use case dependent thing. The value will increas= e if we use it to secure the DAO state. ? In a network with legacy devices, the flows in draft-ietf-roll-unaware= -leaves-02 will have to be supported. I take your mail as a hint that they = are here to stay in case we cannot afford to store the ROVR. Another question I have is,... In the Figure 2, EDAR is sent to 6LBR and DA= O is sent to the Root. As I understand the DODAGID in the DIO will be the g= lobal IPv6 address of the Root (and not 6LBR) and thus DAO can be addressed= to the Root. But how does 6LR get the address of the 6LBR to send the EDAR= ? (assuming in this case the Root and 6LBR are different network entities).= Also it would be better to differentiate Root and 6LBR in the terminology = section. ? That's 6LoWPAN ND. It happens before RPL, and even if there is no ROLL= . See https://tools.ietf.org/html/rfc6775#section-4.3 All the best; Pascal From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthu= bert) Sent: 23 August 2019 17:43 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Add ROVR in DAO? Dear all As noted below, and discussed at the WG meeting at IETF 105, it would be go= od to convey the ROVR field in the DAO, so if the Root and the 6LBR are dif= ferent entities then the root can build a full EDAR as opposed to the dummy= one. It will also help make RPL more secure in the future... So I'm calling to c= onfirm the discussion in Montreal and if there is no opposition I'll go ahe= ad and propose a new option that can be placed with the DAO to transport a = ROVR. We'll also need something in the configuration option to trigger its use. Comments and any hint on how to do that right are welcome. All the best; Pascal From: Roll > On Behalf = Of Pascal Thubert (pthubert) Sent: mercredi 24 juillet 2019 23:54 To: Routing Over Low power and Lossy networks > Subject: [Roll] Add ROVR in DAO? Dear all The only change I foresee in the unaware leaves draft is the addition of th= e RFC 8505 ROVR from the ND EARO into the DAO. After that I'd feel ready to= call for WGLC. The proposed change enables to build a full EDAR message at the root, and a= voids the weird processing of the keep-alive EDAR (see https://tools.ietf.o= rg/html/draft-ietf-roll-unaware-leaves-02#section-7.4) If we do it now we can forget that weird format (all ones ROVR) and never c= ode for it. This may also be useful when we work on securing the DAO using = the AP ND proof of ownership all the way to the root.... Please let me know if there's disagreement to make that change All the best Pascal --_000_MN2PR11MB3565FCB9B09EACB427368E96D8A40MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Rahul and all

 

Please see below

 

As I understand the pr= oposal is to:

  1. Remove the ROVR generation on the 6LBR on behalf of the 6LN.

 

Ø    Not that. The ROVR is never generated by the= 6LBR

 

  1. Use the ROVR from NS(EARO) directly in the DAO.
  2. This would eliminate Keep-Alive EDAR/EDAC during initial/first registration= .

 

Ø    Actually we keep it in the first because it = happens before RPL and provides DAD. But yes for all the subsequent.

 

  1. This would eliminate the need for root node to set all ones in the ROVR fie= ld of keep-alive EDAR.

 

Ø    Exactly

 

This seems optimal.

 

Ø    So far

 

But there is one downs= ide if the DAO is used for such purpose; Adding a 64-bit ROVR field in DAO = would mean that in storing MOP all the parents maintain the ROVR field in their routing = table. This is an immense overhead, since it impacts the routing entry = size even if the RPL network needs to support just a single RUL.=

 

Ø    Yes. It is an additional 64 to 512 bits whic= h limits the size of the routing table. Immense is a use case dependent thi= ng. The value will increase if we use it to secure the DAO state.

Ø    In a network with legacy devices, the flows = in draft-ietf-roll-unaware-leaves-02 will have to be supported. I take your= mail as a hint that they are here to stay in case we cannot afford to stor= e the ROVR.

 

Another question I hav= e is,… In the Figure 2, EDAR is sent to 6LBR and DAO is sent to the R= oot. As I understand the DODAGID in the DIO will be the global IPv6 address= of the Root (and not 6LBR) and thus DAO can be addressed to the Root. But how does 6LR get the address of the 6LBR to = send the EDAR? (assuming in this case the Root and 6LBR are different netwo= rk entities). Also it would be better to differentiate Root and 6LBR in the= terminology section.

 

Ø    That’s 6LoWPAN ND. It happens before R= PL, and even if there is no ROLL. See https://tools.i= etf.org/html/rfc6775#section-4.3

 

All the best;

 

Pascal

 

 

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: 23 August 2019 17:43
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Add ROVR in DAO?

 

Dear all

 

As noted below, and discussed at the WG meeting at I= ETF 105, it would be good to convey the ROVR field in the DAO, so if the Ro= ot and the 6LBR are different entities then the root can build a full EDAR = as opposed to the dummy one.

It will also help make RPL more secure in the future= ... So I’m calling to confirm the discussion in Montreal and if there= is no opposition I’ll go ahead and propose a new option that can be = placed with the DAO to transport a ROVR.

We’ll also need something in the configuration= option to trigger its use.

 

Comments and any hint on how to do that right are we= lcome.

 

All the best;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 24 juillet 2019 23:54
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] Add ROVR in DAO?

 

Dear all

 

The only change I foresee in the unaware leaves draf= t is the addition of the RFC 8505 ROVR from the ND EARO into the DAO. After= that I’d feel ready to call for WGLC.

 

The proposed change enables to build a full EDAR mes= sage at the root, and avoids the weird processing of the keep-alive EDAR (s= ee https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-02#section-7.4)

If we do it now we can forget that weird format (all= ones ROVR) and never code for it. This may also be useful when we work on = securing the DAO using the AP ND proof of ownership all the way to the root= ....

 

Please let me know if there’s disagreement to = make that change

 

All the best

 

Pascal

 

 

 

 

 

--_000_MN2PR11MB3565FCB9B09EACB427368E96D8A40MN2PR11MB3565namp_-- From nobody Fri Aug 23 13:28:31 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E490012025D for ; Fri, 23 Aug 2019 13:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPMU0neSKyfy for ; Fri, 23 Aug 2019 13:28:26 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F077A120232 for ; Fri, 23 Aug 2019 13:28:25 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 4BB431F45E for ; Fri, 23 Aug 2019 20:28:23 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id DDEFF3FB5; Fri, 23 Aug 2019 16:28:50 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 23 Aug 2019 16:28:50 -0400 Message-ID: <14058.1566592130@dooku.sandelman.ca> Archived-At: Subject: [Roll] UNaware leaves X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:28:29 -0000 --=-=-= Content-Type: text/plain I have read draft-ietf-roll-unaware-leaves-02 anew. I have sent a bunch of minor edits to Pascal as a diff against the XML file, and I won't repeat them here. I ask some deep questions in among a few less deep questions. The intro section is a really nice overview of RPL. I rather suggest that we might want to use this text in other places. OLD: In RPL terms, a plain host that does not participate to the routing protocol is called a Leaf. It must be noted that a 6LN could participate to RPL and inject DAO routes to self, but refrain from advertising DIO and get children. In that case, the 6LN is still a host but not a Leaf. NEW: In RPL terms, a plain host that does not contribute forwarding services to the routing protocol is called a Leaf. Such a 6LN would still contribute DAO routes to itself, but would refrain from advertising DIOs, and will not have any children. But, I'm rather unclear about this next part: In that case, the 6LN is still a host but not a Leaf. I think that it should say: In the case where the 6LN does not contribute DAOs to inject routes to itself, then the 6LN is a host but not a Leaf. Would be good to have a reference for the "kinetically powered light switch." I have asked some people for one, because we always talk about them in the abstract. I think that section 3 should be clearer about whether the "R" bit already exists or not. (It is part of 8505). I suggest: - The 'R' flag that is set if the Registering - Node expects that the 6LR ensures reachability for the Registered Address, - e.g., by means of routing or proxying ND. - + This document specifies the use of the existing 'R' flag. It is to be set + if the Registering Node expects that the 6LR is to ensures reachability + for the Registered Address, e.g., by means of routing or proxying ND. + + section 5: The behavior defined in this specification [[whereby the 6LR that processes the registration advertises the Registered Address in DAO messages and bypasses the DAR/DAC process for the renewal of a registration]], is only triggered by an NS(EARO) that has the 'R' flag set. If the 'R' flag is not set, then the Registering Node is expected to be a RAN router that handles the reachability of the Registered Address by itself. Can we just omit the [[]] part? It's really a mouthful. Or give the behaviour a name/section number. Maybe that means a section 3.1? Also I want to be clear that the "This document" in section 5 refer to unware-leaves, and not RFC8505. section 6 is rather all over the place. I'd like subsection points, because we are going to need to refer to the sections, and there will be 6man interaction? Could the whole section be named, "6LN Requirements to be a Unware Leaf". Can we get a 6man reviewer for this sooner? > or not. The flows below are RPL Non-Storing Mode examples. In > Storing Mode, the DAO ACK may not be present, and the DAO messages > cascade from child to parent all the way to the DODAG Root. Actually, isn't the K-flag behaviour this still an open issue in the WG? Or did we resolve this somewhere? Last I recall it was in Rahul's big document, not in something we had adopted. I think that 7.1, if it is general flow, shouldn't try to do storing and non-storing mode. Either have two sections, or omit the differences in the general flow, and deal with the details in subsequent sections. I think that maybe the general flow should omit the backbone registration. Explain it all without a backbone, and then do it again with backbone. > This specification does not alter the operation of a 6LoWPAN ND- > compliant 6LN, which is expected to operate as follows: really... I thought that we were making it able to deal with RPL artifacts, as specified in section 6!!! What is the specific signal that the 6LR can use to know that the host is an RAN rather than a RUL? I suggest that all text like: o Upon each consecutive registration, the 6LN MUST increase the TID field. read like: o As described in RFCXXXX section FOOBAR, upon each consecutive registration, the 6LN MUST increase the TID field. because I think that the point is that there are no changes, right? Except for the InstanceID. Should this specification extend 6tisch-minimal (CoJP) to include a way to set the InstanceID? o A 6LN acting as a RUL MUST set the 'R' flag in the EARO whereas a 6LN acting as a RAN SHOULD NOT set the 'R' flag. wouldn't a 6LN acting as a RAN be a 6LR Leaf, and therefore not a 6LN? Maybe we need another term here. o the 6LN is not expected to be aware of RPL so it is not expected to produce RPL artifacts in the data packets. certainly, it shouldn't do IPIP or RH3. It would be damn useful if it would put the RPI in. Not putting it in means the adjacent 6LR has to IPIP it, address it to the RPL Root. If we put it in, then in the storing case, no further IPIP is needed!! In non-storing the root still has to add the RH3, if it's going back down. If it's window smash alarm, it is probably going to leave the LLN anyway, so no big deal. I want to get rid of the IPIP headers not because they take space, but because the represent code paths not frequently taken. In particular, the hop-by-hop IPIP header just pisses me off. > From then on, the 6LN periodically sends a new NS(EARO) to refresh > the NCE state before the lifetime indicated in the EARO expires, with > TID that is incremented each time till it wraps in a lollipop > fashion. As long as the 'R' flag is set and this router can still lollipop fashion probably needs a reference. What does TID start with? (what's the stick of the lollipop? I guess this is in 8505, but reviewers probably won't know this unless we tell them) I think that "is left to zero" is a bit awkward. I think that "is zero" is better? I think that the Opaque field isn't zero, but is empty? > o the External 'E' flag in the Transit Information Option (TIO) > associated to the Target Option is set to indicate that the 6LR > redistributes an external target into the RPL network. This is > how the Root knows in Non-Storing Mode to use IP-in-IP and > terminate the outters headers at the 6LR that generated the DAO. There are a lot of other circumstances in which the root has to use an IPIP. I think that it would be better to say: } o the External 'E' flag in the Transit Information Option (TIO) } associated to the Target Option is set to indicate that the 6LR } redistributes an external target into the RPL network. When } the Root has to use an IP-in-IP [useofrplinfo], then this flag } indicates the IP-in-IP should be addressed to this node. I think that traffic from the Root to the RAN will not need an IP-IP, just the RH3/RPI, which the RAN will skip. Traffic from elsewhere will have an IPIP in for that Root to add the RH3/RPI. But, since the RAN will skip IPIP, the Root could address traffic. Are there projected DAO interactions where the Root arranges for traffic to go laterally across the DODAG that might need some consideration here? ASIDE: should this document effectively Update UseofRPLINFO? Security Considerations will probably need another page. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl1gTIIACgkQlUzhVv38 QpDDmQf/W/A1o5T5txSrl1WMPVUjIrkho4iB+XI7bvxIUwXJ6+eQ2Bhu9Fx0X81j Rwpu61DQHdOxYgB/Wy6AFzNjHpGbamrsRB+0bmFmKI/64DGtbrJuNcKxjl0g/AsV 9/jgjCokMaYJgGZ4geNZSMsSjUpx0ZHW7Gj8SpgGcFt4o9uImSubzBxeLu5Rm8hd Ln/FU6lnWpRBsHWC/V3fG3LRl7jHbMTwLzDRogg2K7D8HTmoPpaC1+TqVWGpbO5v Ab4zzjBBcWcnldUCURtvyvyTdON5Mu7ZR/eUOUFPmF7Z2QAo6ocyJhgQQMmv2DvX y7krKG06ANGqpVWhIlc0xKc1ZQtDQQ== =3thF -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 23 13:46:54 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2972120119 for ; Fri, 23 Aug 2019 13:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYe0Loaujeyp for ; Fri, 23 Aug 2019 13:46:50 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F921201CE for ; Fri, 23 Aug 2019 13:46:50 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id E9CC61F45E for ; Fri, 23 Aug 2019 20:46:48 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 9C6463FB5; Fri, 23 Aug 2019 16:47:18 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 23 Aug 2019 16:47:18 -0400 Message-ID: <14914.1566593238@dooku.sandelman.ca> Archived-At: Subject: [Roll] comments on mopex-cap-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:46:53 -0000 --=-=-= Content-Type: text/plain 1) If Capabilities and MOD-Extension are mutually independent, why is it in one document? 2) MOP clearly applies to the entire DODAG. I don't know if Capabilities do from the description: REQ3: Optional capabilities handshake. Capabilities are features, possibly optional, which could be handshaked between the nodes and the root within an RPL Instance. Are they things that the root tells nodes, or things that the node tells the root? Are they individualized, or does every node in the LLN have to support a capability before it can be used? 3) I argued before against the Extended-MOP-value being added to the Base MOP. I prefer that the value 7 means *replace* the MOP with the MOPex. Yes, that results in two ways to encode MOP="3", but I think that it leads to far less confusing code. 4) 3.2, if the MOP is not 7, and the MOPex is present, what does this mean? (Nothing, I think it should be ignored) Would we really ever assign a new the value 7? 5) section 4.0: > Note that capabilities and MOPex are mutually exclusive and it is > possible for an implementation to support either or both of the > options. I think that you mean, not mutually exclusive? 4.1: >There are no capability flags defined by this document. that makes it really hard to know how they work :-) 4.2: use of "could" is very non-normative. > Capabilities > advertised by non-root nodes are strictly a subset of the > capabilities advertised by the root. This should be in REQ3. 7.1/7.3. If you take my advance about not adding, but replacing, then this document would Update the Mode of Operation registry, and we would not need a new registry. ==== having done all of this. How will DAO-projection signal itself? It seems like a capability to me. I haven't read that document in a few months. If it uses capability, then this document that creates capabilities SHOULD probably allocate a bit in it's initial table. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl1gUNYACgkQlUzhVv38 QpAA2gf/UWAP+sMVyj+yEHebp4QvWfrJY61PS8qONldX8rUngEBJIaVhG0cNUPYT BIIUj4YTkNjKvmLupKykdmxEiE+/bkATf1cgWBhTEr8fhwxTKc0h4+unZS+VXH5x dIwVw/4+kntXpdpYuE+AopT4Mt0RAOR/84vddvaRfrtkAXr/XOe3Zq7d5StmtImE JNITklTvJAU4Ga7qJwS2Z+Ja3c3vrcCMQwnWdIjki0Jy8VfIYpD18ot/bdy7sNjV XfdRuoAXWVJc+jUytjhuh6b7CBy4zxDAmuO7FrqUKKUkbqBRJK4Rk2o76cQtLQcO Sip/WE4WFPYQ25QIsX5GEdMEBibfYg== =JLjt -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 23 13:52:43 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E591201CE for ; Fri, 23 Aug 2019 13:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZKHZN7P0J0G for ; Fri, 23 Aug 2019 13:52:39 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24556120124 for ; Fri, 23 Aug 2019 13:52:39 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 4F6421F45E for ; Fri, 23 Aug 2019 20:52:37 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 06BD13FB5; Fri, 23 Aug 2019 16:53:07 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: References: Comments: In-reply-to "Pascal Thubert (pthubert)" message dated "Fri, 23 Aug 2019 09:43:16 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 23 Aug 2019 16:53:07 -0400 Message-ID: <15452.1566593587@dooku.sandelman.ca> Archived-At: Subject: Re: [Roll] Add ROVR in DAO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:52:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > As noted below, and discussed at the WG meeting at IETF 105, it would= be good > to convey the ROVR field in the DAO, so if the Root and the 6LBR are > different entities then the root can build a full EDAR as opposed to = the > dummy one. > It will also help make RPL more secure in the future.. So I=E2=80=99m= calling to > confirm the discussion in Montreal and if there is no opposition I=E2= =80=99ll go > ahead and propose a new option that can be placed with the DAO to tra= nsport a > ROVR. So, this will be used by unware-leaves? EARO(ROVR) -> 6LR 6LR ---DAO(ROVR)---> 6LBR =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl1gUjIACgkQlUzhVv38 QpB84Qf+NHxuwPxhpTT6yWfyCpo8EZJIjvzPkzcvcD41rck0G7ef3AB+guTDblfI i5eBN+ftXpfRNLsVeUCztsSu+1Gy6e2eCs4QjRmCu0usYjaWfXOOo6U7EW78wDDt ogJZGjodjzg3lKTVG2wo+rnyhhAQWx/zcdQopUfGNZ+fgdHT67TA3zkUfe+5EzEf djU47P7onIVMoJhSUUttTEkSjBtXBNNliQmYUFI6tSKuCuHCieVcSue5tUEfVn4k 9b8m5w7vUH/kZlaMaEywZ/+y0ZKStKIXYrswxBOXRbHo6ApE9AXchPPVlog3KN4v jsvbG3Dnd22/5x01nRot/xUqB3d5Qw== =52Vf -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 23 17:40:25 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91771200B8 for ; Fri, 23 Aug 2019 17:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U9o6_Hc_24l for ; Fri, 23 Aug 2019 17:40:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB9A120077 for ; Fri, 23 Aug 2019 17:40:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E379B3818F for ; Fri, 23 Aug 2019 20:39:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E77DDC07 for ; Fri, 23 Aug 2019 20:40:18 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB6CBE@BLREML503-MBX.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DFB6CBE@BLREML503-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Add ROVR in DAO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 00:40:24 -0000 --=-=-= Content-Type: text/plain Rahul Arvind Jadhav wrote: > 1. Remove the ROVR generation on the 6LBR on behalf of the 6LN. > 2. Use the ROVR from NS(EARO) directly in the DAO. > 3. This would eliminate Keep-Alive EDAR/EDAC during initial/first registration. > 4. This would eliminate the need for root node to set all ones in > the ROVR field of keep-alive EDAR. > This seems optimal. > But there is one downside if the DAO is used for such purpose; Adding a > 64-bit ROVR field in DAO would mean that in storing MOP all the parents > maintain the ROVR field in their routing table. This is an immense > overhead, since it impacts the routing entry size even if the RPL > network needs to support just a single RUL. So, ideally, the RUL or 6LR would send some keepalives with the ROVR directly to the 6LBR even in storing mode. Maybe not in DAOs. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1gh3IACgkQgItw+93Q 3WW9CggAqlcB09AcRZ26EUCDntIPtxsNJ+fY1XGMfPGwXGCXVesbPXMjdOucqKXm hqGzk0o7+8o+AER5C9JaeRcghz5nRG9WWIG0MNY56c+ZOI9tMqSiCyaqszDHwSgb TTEajWYY78aPjvcCtBYfN6kxpDO0vvDSvt1xjW9nR3K5ZfS/s0C7F1YI27dGezEf I9SY5/tNVftfBbmOFSbZPfnmLjIEt0REFpS3MmNhHvFlvMF4MQCen5TSG1zvQqT0 qimR+q/QdWt3V+VpzqUEIRNCLn0sfZAcTAGy6S4cw3o+2sdAo/dRq7JDbYdeWqY9 md+JEUn/2kwBN9lrChSc2vkMosTrdQ== =zj9X -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 25 04:07:55 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D277D120074 for ; Sun, 25 Aug 2019 04:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6gfu2QtUcEx for ; Sun, 25 Aug 2019 04:07:53 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F12E12004E for ; Sun, 25 Aug 2019 04:07:53 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C4B59549DE6C58DD324C for ; Sun, 25 Aug 2019 12:07:49 +0100 (IST) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 25 Aug 2019 12:07:48 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.145]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0439.000; Sun, 25 Aug 2019 16:37:39 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] comments on mopex-cap-00 Thread-Index: AQHVWfPtD4pbDo6IVE6ViD6SM7yZ8qcLq8dA Date: Sun, 25 Aug 2019 11:07:38 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> References: <14914.1566593238@dooku.sandelman.ca> In-Reply-To: <14914.1566593238@dooku.sandelman.ca> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] comments on mopex-cap-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 11:07:55 -0000 Thanks Michael for the review and feedback. Please find my comments inline. 1) If Capabilities and MOD-Extension are mutually independent, why is it in= one document? [RJ] I raised the possibility of keeping it in separate document in IETF 10= 4. But no one voiced any specific reason to separate it out. Even though se= mantically the Capabilities and MOP-Extns are mutually independent, some of= the scenarios discussions might require to discuss them together. Do you b= elieve we should separate it out and if there is any advantage doing so? 2) MOP clearly applies to the entire DODAG. I don't know if Capabilities do from the description: REQ3: Optional capabilities handshake. Capabilities are features, possibly optional, which could be handshaked between the nodes and the root within an RPL Instance. Are they things that the root tells nodes, or things that the node tells the root? =20 [RJ]: MOP is indicated by the root and the whole network has to follow it. = The capabilities on the other hand are node specific. For e.g., the end nod= e can indicate that it supports a primitive via cap flag and this info coul= d be used by the root and vice-versa. The answer to your questions above is, "Both". Are they individualized, or does every node in the LLN have to support a capability before it can be used? [RJ]: Nice point. I haven't thought about this in detail. In non-storing MO= P, it may not be required that all the nodes support capabilities but in st= oring MOP, every 6LR needs to add the cap (if present) of the downstream ch= ild, thus requiring every node to support it. This definitely needs handlin= g in the draft. [Ref: https://github.com/roll-wg/MOPex-capabilities/issues/1] 3) I argued before against the Extended-MOP-value being added to the Base MOP. I prefer that the value 7 means *replace* the MOP with the MOPex. Yes, that results in two ways to encode MOP=3D"3", but I think that it leads to far less confusing code. [RJ]: I am ok with this approach. Will update the document. [Ref: https://github.com/roll-wg/MOPex-capabilities/issues/2] 4) 3.2, if the MOP is not 7, and the MOPex is present, what does this mean? (Nothing, I think it should be ignored) Would we really ever assign a new the value 7? [RJ] With point 3 accepted, this point is not relevant anymore. (?) 5) section 4.0: > Note that capabilities and MOPex are mutually exclusive and it is > possible for an implementation to support either or both of the > options. I think that you mean, not mutually exclusive? [RJ] I meant that caps and MOPex do not depend on each other and are mutual= ly independent. May be I should :s/exclusive/independent/=20 4.1: >There are no capability flags defined by this document. that makes it really hard to know how they work :-) [RJ] Yeah, should have added an example. Will be done in the next update. [Ref: https://github.com/roll-wg/MOPex-capabilities/issues/3] 4.2: use of "could" is very non-normative. > Capabilities > advertised by non-root nodes are strictly a subset of the > capabilities advertised by the root. This should be in REQ3. [RJ] Actually I am not sure that this will be true going forward. Why can't= a intermediate 6LR add its own capability in DIO (without depending on roo= t) for its downstream childs? If this is the case then the draft's above st= atement is not true. I am glad you pointed this out and wish to discuss mor= e on this. 7.1/7.3. If you take my advance about not adding, but replacing, then this = document would Update the Mode of Operation registry, and we would not need= a new registry. =3D=3D=3D=3D having done all of this. How will DAO-projection signal itself? It seems like a capability to me. I haven't read that document in a few months. If it uses capability, then = this document that creates capabilities SHOULD probably allocate a bit in i= t's initial table. [RJ] I am considering this for the example use-case of caps=20 From nobody Mon Aug 26 01:55:42 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AB3120048 for ; Mon, 26 Aug 2019 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Ywcu8Pf7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GWlwbf3p Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5PUv2rr4Vta for ; Mon, 26 Aug 2019 01:55:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5812C120025 for ; Mon, 26 Aug 2019 01:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1088; q=dns/txt; s=iport; t=1566809738; x=1568019338; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vTauzhloPoHURURuBmEK7h+uJS0kibhMt3kCJoDdI2Y=; b=Ywcu8Pf79fIF+Hp8MutHCXko1tekdQr9BmmjBaS1lEMWGIVkyRFXn2dX Jdl8ydJciCBj6zzVv6QeF7rn4xkI43TaXkohLC8Pft/VURJrgD7BCIFeB J4s9Ywp05V0H4RhW6sSZcQt//5lBhtS8fIAXYZzdkPmD7hJuQPcZVZE5v g=; IronPort-PHdr: =?us-ascii?q?9a23=3At7YjihGsyEbO268lmKmP5p1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAQDsnWNd/4kNJK1kHQEBBQEHBQG?= =?us-ascii?q?BVQYBCwGBRFADgUMgBAsqhCGDRwOKbE2CD5dogS6BJANUCQEBAQwBAS0CAQG?= =?us-ascii?q?EPwIXglAjNgcOAgoBAQQBAQECAQYEbYUtDIVKAQEBAwESEQQNDAEBOA8CAQg?= =?us-ascii?q?aAiYCAgIwFRABAQQbGoRrAw4PAQKcLgKBOIhhc38zgnsBAQWEfhiCFgmBDCg?= =?us-ascii?q?BhHyGdRiBQD+BEUaCTD6ERoMJMoImjCBTgiqOG442CQKCHpRemE+mDgIEAgQ?= =?us-ascii?q?FAg4BAQWBVwQtgVhwFYMngkKDcopTcoEpjXkBAQ?= X-IronPort-AV: E=Sophos;i="5.64,431,1559520000"; d="scan'208";a="319095188" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 08:55:37 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x7Q8tbTs024573 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 26 Aug 2019 08:55:37 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 03:55:37 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 03:55:35 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 04:55:35 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l8GWxMwqXAdax4ky9Jv9hWea99I2/fqs1/6h0SQw9CxMFyF6N+qnW9PMcgPZlT62BQJeW6tTjSCHZIARF9DIGQ1plEs6Fqxe9q5LL4ro2wnje3dsyWu8PPdpAfrjnp7mTMnQ9Qc63stdCjD/rqHHueqHPAzzItY4GPd2Npxhc7Deuvz372PPE8psQ7KpyYfl4pRlZQBuqspXI+RDHHtPHc661edSw9ThBLJ8UZ7Mqz5dn2HPU8bdJEZNEStDYi+kMDGQXJRhs7xQ9ff+uNDs3FSEIs23ZIcqXPaSEQYOahXhkh/W8s1enDQ+jwbpcFqOPpCJOpeHbhoMbTJpWogtGw== 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=vTauzhloPoHURURuBmEK7h+uJS0kibhMt3kCJoDdI2Y=; b=Afy51SaRrdRzWkfGsT5v0rbfpAV8sMuUY12+sEKSSZ7yvD6IZd+vIuvh/HUozXzjxwAZhQ5I8sWJIq38WZ1610WVmiADJGPCSy3bKf3poynQGERXkRaaBQ7/CpcWe6q/Jk0X9z4c/Mo6xbhL4msyL5j44T/KuK7m1yRPJPVVVA7hBIIztzs1DWob3i0f5w2i5lMi/Ofo090EM35Iy/ZXB72/d8SfMQ4nSIWzEWR+R9nX3WFRpvZm254IT6RC3lPygvUeDPnaF420b3Ap+Z59YPGCPb6FVUUTU3c+Z+WsT+nbNqz81lQ8IPQrFnYLp6hGqhJWy858sS28Rj6AW+RSag== 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=vTauzhloPoHURURuBmEK7h+uJS0kibhMt3kCJoDdI2Y=; b=GWlwbf3pzRnkWX7ahwtFhZ9KiVKfD1mll429ZG/B9u+jtJJ59Y64A3GcC40msqlrJmYVAvNe8S+DSPaH5cVHXFg9hOmVtabezfgBEPAiGhgDBjRbGk/ZHvXzkou6FduDPnjKSRm4y0TwAr8BRhvu8ZSL3T+jb4yzyLuMrkmPf3Y= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3773.namprd11.prod.outlook.com (20.178.253.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Mon, 26 Aug 2019 08:55:34 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 08:55:34 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Add ROVR in DAO? Thread-Index: AdVCahRZPRQ6beNIQb+VlVo9l/YWKAXLCFRQABejjIAAfUidoA== Date: Mon, 26 Aug 2019 08:55:22 +0000 Deferred-Delivery: Mon, 26 Aug 2019 08:55:17 +0000 Message-ID: References: <15452.1566593587@dooku.sandelman.ca> In-Reply-To: <15452.1566593587@dooku.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1003::f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7439204b-71f4-4b4d-f650-08d72a03287c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3773; x-ms-traffictypediagnostic: MN2PR11MB3773: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01415BB535 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(39860400002)(346002)(396003)(199004)(189003)(6506007)(71190400001)(186003)(6436002)(71200400001)(55016002)(86362001)(81156014)(81166006)(9686003)(8676002)(5660300002)(66446008)(76116006)(8936002)(6666004)(33656002)(66556008)(64756008)(66946007)(6116002)(7696005)(4744005)(2906002)(76176011)(66476007)(486006)(6246003)(25786009)(476003)(46003)(446003)(102836004)(229853002)(99286004)(11346002)(74316002)(6916009)(52536014)(305945005)(14454004)(256004)(316002)(53936002)(478600001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3773; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SaSpQxa9JHE5r/0MpCZA28HmXt9QBzDRco+JTIQgGYstXKSJxynVePKVcJZPAClXmNIcocXL2E5F1QE5Jvl5yUuZIudWW4B0EftDUlk4uBCUBZs1fLDrx/vUEOoLqf9fB86S1M6Qx5pfz8Jhme3TbdXWFnxarnBrWXKoAaMvTNJPAoh12TMbiKEnE/30mxx1YMhtotWQMWv+ClLK2hkOnJi4yG0NA7015CpNRzcrWX8aOeRO9sS+R8Sv1hOxgDJ0cpJ2W/3VTKFA0j0Yb5hWiojXIAEY2TnszVsQoOWe4BiM0VLQHpsgn6FlBltYuQdE1QlZ3FHtqSWaK7ygoJOGFsFO8PagRUw+tsAoMldpJlJoOr0IuhpsLwth+fWMeMJ4z3WZrCdr75BWURx4W+sJ2cbrNnUBEf0owA8UpfdVeLo= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7439204b-71f4-4b4d-f650-08d72a03287c X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 08:55:34.7391 (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: r5l+tb6KgWzvZGhcu2XemtRaqNEJrVScV70iiWeHcl/uYw/vCMg+dM8sCuA2x9bUIsR9pnbtinnmHCEL3EwgVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3773 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Roll] Add ROVR in DAO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 08:55:41 -0000 SGVsbG8gTWljaGFlbA0KDQo+IA0KPiBTbywgdGhpcyB3aWxsIGJlIHVzZWQgYnkgdW53YXJlLWxl YXZlcz8NCj4gICAgIEVBUk8oUk9WUikgLT4gNkxSDQo+ICAgICAgICAgICAgICAgICAgIDZMUiAt LS1EQU8oUk9WUiktLS0+IDZMQlINCg0KDQpZZXMsIG1vcmUgbGlrZSB0aGlzDQogNkxOIC0+IEVB Uk8oUk9WUikgLT4gNkwNCiAgICAgICAgICAgICAgICAgICA2TFIgLS0tREFPKFJPVlIpLS0tPiBS b290IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9vdCAtLS1EQVIoUk9W UiktLS0+IDZMQlINCg0KTm90ZSB0aGF0IEkgZG8gbm90IGtub3cgaG93IHRvIGF2b2lkIGtlZXBp bmcgd2hhdCB3ZSBoYXZlIGluIHVuYXdhcmUgbGVhdmVzIHRvZGF5LCB0aGF0IGlzIHRoZSBmbG93 IGZyb20gdGhlIDZMUiB3aXRob3V0IGEgUk9WUiwgYW5kIHRoZSBwcm9ibGVtIGlzIGFzIHVzdWFs IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuDQpXZSBoYXZlIHRvIGNob3NlIGJldHdlZW4geWV0IGFu b3RoZXIgZmxhZyBkYXkgLyBjb25maWd1cmF0aW9uIGJpdCBhcHByb2FjaCBvciB0byBsaXZlIHdp dGggdGhlIGtlZXAgYWxpdmUgYXMgYWxyZWFkeSBkZXNjcmliZWQgd2l0aCBubyBST1ZSIGFzIGFu IG9wdGlvbi4NClRoZXJlJ3MgYWxzbyB0aGUgcHJvYmxlbSBvZiBrbm93aW5nIHdoZXRoZXIgdGhl IDZMQlIgc3VwcG9ydHMgdGhlIGtlZXAgYWxpdmUgd2l0aCBubyBST1ZSLiBUaGF0IHdpbGwgbmVl ZCB0byBiZSBzaWduYWxlZC4NCg0KU3VnZ2VzdGlvbnMgd2VsY29tZSENCg0KUGFzY2FsDQo= From nobody Mon Aug 26 02:25:13 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED232120121 for ; Mon, 26 Aug 2019 02:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UIrkWVyi; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BzcBaGkF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm2wf2_ViyW3 for ; Mon, 26 Aug 2019 02:25:09 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A41120119 for ; Mon, 26 Aug 2019 02:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1470; q=dns/txt; s=iport; t=1566811509; x=1568021109; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7fbcyCd45m1mCj4fAjqty3JPq/VAeqj6CNli7f/i/vM=; b=UIrkWVyiI9R+wryc8tJnhSEkPFPedXwUlc2ndt5CqHK4SnKOnihKYxlU K0OVBnhUVwUsuUYXP1HBLQxLGMqpBcsT8F3jdHyTxr5iPLlxnzlgQgSQV 4gg87TctcP30ZldJP/YodQSqdAc1wb99NFM6KGP1x1NLz0O6NmTz7zwf+ U=; IronPort-PHdr: =?us-ascii?q?9a23=3AmfHYGxGeRxkCS/IGUUjRzJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAQAzpWNd/4oNJK1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBVgQBAQsBgURQA4FDIAQLKodoA4ptTYIPl2iCUgNUCQEBAQwBAS0CAQG?= =?us-ascii?q?EPwKCZyM3Bg4CCgEBBAEBAQIBBgRthS0MhUoBAQEEEi4BATgLBAIBCBEEAQE?= =?us-ascii?q?BLjIdCAEBBBMIGoRrAx0BApwqAoE4iGGCJYJ7AQEFhH4YghYJgTQBi3EYgUA?= =?us-ascii?q?/gRFGUYF7PoQoHoM7giaMIIkQlj4JAoIelF6YT6YOAgQCBAUCDgEBBYFmIoF?= =?us-ascii?q?YcBWDJ4JCg3KKU3KBKY4GAQE?= X-IronPort-AV: E=Sophos;i="5.64,431,1559520000"; d="scan'208";a="313770132" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 09:25:07 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x7Q9P7fx031374 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 26 Aug 2019 09:25:07 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 04:25:07 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 05:25:06 -0400 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 05:25:06 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gnCITyaV+jewlkTFSHKvecCXIWaLou6WBTbLmtE5OYPJV0y35yjJV6i3yzQ3/5RUWL9qPxcXAooplZoUX7t2XohK+L2uZIK+4kwztgJnIzRAykd9RivpssZCnL9uof6m8G3XUfnNOtTpid3L2iwIiy66+RYYKgTzXDdCQLWvqfL0kI/ZnvOdpXVT5IlDkWDs8fzy6r/1/HtKxmFLQF3TDeaWnJE7t87n3NdRGQPlLxDNoVH3nuCLMGB2OedB1D2pcgJgT/QY28xhewDEKV3aEdpGxs0oPq8RFDo1x9fN0CdmYR13spOOedLSIa9+W0HXpFZSsa4ZbC9kCyNk6ym24Q== 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=szdWzT2VMVgP51KRiboeOctZaio2LscJmAGmFecFleQ=; b=HaozA543+3YIIc0HiqYXVymU6qQtjI1ielpUiGkgNgOOT8YPwoJrXegT0rAwjdU9If9byuG/cSjCjmZYeV4cqAdWL/6jfCGLAjfmmkTcqcdGPrEJLMXAevs5rTEsOWh8WHEYhFUQMTJJ62HsPc8zBakMm6jqXOyVQLVkMjZUZbh3tY2Bw/Mr4dSOAps4DgepOsQEGHzGW/yA7XIm0bpTQGaHNrivPtrNvH6W4ZiAuRVp6anjR9lB22Dda2KmMga2Zzj0PRK3FkAyQn+6seCl/AwQAIo1Yh4ENewKYrJ48OCDKG+qX3tdhNMwUCC5eh2yZIS9/gvWoJ96HWTOe2rkZw== 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=szdWzT2VMVgP51KRiboeOctZaio2LscJmAGmFecFleQ=; b=BzcBaGkFYfIaEC9fNEhDp/6be9MrtFp7gq21+P6v5ceZ8leFLu6rXrkDSi1Z2XqOEn+xnvTCqAfgKoqOyT8a1wK7a+uJVi8oI8PBcafdXK2BwoI83r7qpNA9PZsYr/j6AUuyPb+M7/JBlpM7IMoErPACpwPfUvthwwvyRc65Qxw= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3567.namprd11.prod.outlook.com (20.178.251.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Mon, 26 Aug 2019 09:25:04 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 09:25:04 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Add ROVR in DAO? Thread-Index: AdVCahRZPRQ6beNIQb+VlVo9l/YWKAXLCFRQAB+Y+O4AddG70A== Date: Mon, 26 Aug 2019 09:24:49 +0000 Deferred-Delivery: Mon, 26 Aug 2019 08:56:52 +0000 Message-ID: References: <982B626E107E334DBE601D979F31785C5DFB6CBE@BLREML503-MBX.china.huawei.com> <24307.1566607218@localhost> In-Reply-To: <24307.1566607218@localhost> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1003::f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa3d9ced-8536-40f3-2a6c-08d72a074782 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3567; x-ms-traffictypediagnostic: MN2PR11MB3567: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01415BB535 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(396003)(39860400002)(376002)(366004)(199004)(189003)(13464003)(2906002)(478600001)(14454004)(11346002)(446003)(7736002)(86362001)(476003)(486006)(99286004)(76176011)(7696005)(74316002)(6116002)(33656002)(305945005)(186003)(46003)(102836004)(316002)(229853002)(6506007)(53546011)(6916009)(25786009)(71190400001)(71200400001)(256004)(66446008)(81156014)(66946007)(6246003)(76116006)(66556008)(66476007)(64756008)(81166006)(8676002)(55016002)(5660300002)(9686003)(53936002)(52536014)(6666004)(8936002)(6436002)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3567; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uJF1vvlrrApyHvM98kpekIU26AKwtThM/6/I5/UMCBPROicRzF2dR4NJo22H2weWvBl5APqzPM9wgClisSbdgM61n+OO77zFgs9ZhilC+QH3+dUBl0wz8rn3/j3bSTm+jiIw7ToKMXi0zlYv/VmJcm0XLn0SvzkMfNawLjzG55FqtxAu+hGkhdSZ0YG30HBnmGnV2XBUzEL2KC2LOaxXfKybu2TYx3GuHKgqCQE/WU+226W//GxwGZtqjhc9PsTrSSk6IJMqZ0UmiTQ4rrvZ0daVmLCiVUqw1LlWajv4r1WdGvhaTht+uAVASY1D0D55OLaWDdF5lzW+61CSdYRfaUO8iHVdGBGczuh0h7kLYiGTIEKldtbQz7ew208ai8ll0p4aHFuZxgN4I1ej587IH6Omg1wLGkIN8Kqoo6/EH0I= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa3d9ced-8536-40f3-2a6c-08d72a074782 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 09:25:04.7495 (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: 7GsCCuyH6c7Vcvy7FhppJnf0UZ70sWiZyII3DGirjJ4NCiNgqmfRfg4BlEETeo3Wv6oAhKUckx6GpUbKPVqX+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3567 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Roll] Add ROVR in DAO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 09:25:11 -0000 > -----Original Message----- > From: Roll On Behalf Of Michael Richardson > Sent: samedi 24 ao=FBt 2019 02:40 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Add ROVR in DAO? >=20 >=20 > Rahul Arvind Jadhav wrote: > > 1. Remove the ROVR generation on the 6LBR on behalf of the 6L= N. > > 2. Use the ROVR from NS(EARO) directly in the DAO. > > 3. This would eliminate Keep-Alive EDAR/EDAC during initial/f= irst > registration. > > 4. This would eliminate the need for root node to set all one= s in > > the ROVR field of keep-alive EDAR. > > This seems optimal. >=20 > > But there is one downside if the DAO is used for such purpose; Addi= ng a > > 64-bit ROVR field in DAO would mean that in storing MOP all the par= ents > > maintain the ROVR field in their routing table. This is an immense > > overhead, since it impacts the routing entry size even if the RPL > > network needs to support just a single RUL. >=20 > So, ideally, the RUL or 6LR would send some keepalives with the ROVR dire= ctly > to the 6LBR even in storing mode. Maybe not in DAOs. Well, that's what we want to avoid, 2 keep alive messages all the way acros= s the LLN when one could suffice. In that case I'd rather live with a DAR with no ROVR the duplication of eff= orts. All the best, Pascal From nobody Mon Aug 26 02:32:13 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80651120125 for ; Mon, 26 Aug 2019 02:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=be9Lri9y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sSl6J7LS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAOB9FYOtvMQ for ; Mon, 26 Aug 2019 02:32:09 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE92120826 for ; Mon, 26 Aug 2019 02:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5283; q=dns/txt; s=iport; t=1566811928; x=1568021528; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qgVCmCmyc+L65srdS/hA0d0e+XyBON0EC/m5/P3+RNU=; b=be9Lri9y9SbFPROxXGU9mVz8t1432MjEFGVe4ZRtN4kwI43GmEUohPi1 Bc4hRSELE55kMxtsrK5yYYOatCz7IjclXI94AunDYxHs5mY0e/3SI4zh7 j183plc69ED9GEKGvVFa36ncEq4NvhGtU/BBwBxp9GkB2rBBVGp0UFpha o=; IronPort-PHdr: =?us-ascii?q?9a23=3Ac8p7ih0+gekPIfiEsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALCgDJpWNd/5tdJa1kHQEBBQEHBQG?= =?us-ascii?q?BZ4FFUANtViAECyqHaAOKbE2CD5doglIDVAkBAQEMAQEYCwoCAQGEPwKCZyM?= =?us-ascii?q?4EwIKAQEEAQEBAgEGBG2FLQyFSgEBAQQBARAuAQEsDAsEAgEIEQQBAS8nCx0?= =?us-ascii?q?IAgQTCBqDAYFqAx0BAgycIQKBOIhhgiWCewEBBYR+GIIWAwaBNIR9hnUYgUA?= =?us-ascii?q?/gRFGgkw+gmEBAYFFHoM7giaVMJY+CQKCHoZqjXSCMocwhBuKUo8ehjWQOwI?= =?us-ascii?q?EAgQFAg4BAQWBZyGBWHAVO4JsgkKDcoUUhT9ygSmOBgEB?= X-IronPort-AV: E=Sophos;i="5.64,431,1559520000"; d="scan'208";a="314485588" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 09:32:08 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x7Q9W7I2010578 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 26 Aug 2019 09:32:08 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 04:32:07 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 05:32:06 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 05:32:05 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EBrcARWuM35eXW5VYeBaKyJBa9qsU1SsNGXSKoCirCw2yxpABMOBxX/1NWNaUCaMhdTyuQysdpVhJ+ShXr64S8em+qIBQY4VXkziEUqo7fXtqZ8TjexoIfIWvn64N/ezHxNEZAlttluT0rbzE5EREw8CWA8EoAFxoSKZosk4lrknIyX7m949LaTPPcmH8YUNe9JPbv7J5B0nRnBsE07CbXG0SRGHpm/r8BLDne9IWBtNdrTwQAerPvrgGGA+yVXaAstK1diJUWG0nMGQ2nU2dbqaE/8BUoU/XnULHeCEZVoVJbM4BMZxpgqNkw7XKZj03v+S7HJkOsWsWQXKRHvMjQ== 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=g/LaBXtkDoN7c1xV4i9O7N68wpyd7KNwHBkTNxXrRYQ=; b=WKRyrOlZQwHGB/UPjpF+P3bDGkrCr7F/LBKrGavOi02twfKAW3Hj5wkqcmWPuwwiGE1JWBbQLwKLERN5GcN0+cC5rcPBn5zDrwrWYcKtBIs1VtICsNYqbx3od0Dq6b7Ivme5SvUbBYGInpiGvytqbILYWQLxSGWGcl1squOeRZupL8nxQKBXe75EspSSy1n4yBvgx7uW7HMTDvV0hWWalIp9hyLWMZBHBEeFx3FTDdTsSKGVZ/BAp15Ymp0TYFXEiNuzpzEHI04s9vvo6xlu3W3el8VfT0ri8VV3ntebkpVALCjI6jyZj4l9OnCqgPquy9g/BlpkShJky/RzflzP4A== 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=g/LaBXtkDoN7c1xV4i9O7N68wpyd7KNwHBkTNxXrRYQ=; b=sSl6J7LS65xKuTGD0lXx5B5CUq7yR+n4y1khrwa8J17JYV67ZEAUti9PWPmAP5am4bgLxk3r9LmIsUBXzlDC1U8VuRU9VrHTkkXGpMT8gStoAACQX8BmIztaOKRoJKqfPrR/2FnOAo+AIZJuXgitepiHfVeJs6/BnlYhB5RwgbE= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3759.namprd11.prod.outlook.com (20.178.252.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Mon, 26 Aug 2019 09:32:04 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 09:32:04 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] comments on mopex-cap-00 Thread-Index: AQHVWfP0dJKtxPToUUalM4PDxdaoiKcLtrQAgAF1wcA= Date: Mon, 26 Aug 2019 09:31:45 +0000 Deferred-Delivery: Mon, 26 Aug 2019 09:31:24 +0000 Message-ID: References: <14914.1566593238@dooku.sandelman.ca> <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1003::f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 379ce1c6-024a-4cd8-4210-08d72a0841d9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3759; x-ms-traffictypediagnostic: MN2PR11MB3759: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01415BB535 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(136003)(396003)(366004)(13464003)(51444003)(199004)(189003)(6116002)(966005)(6436002)(6306002)(55016002)(53936002)(9686003)(25786009)(33656002)(86362001)(6246003)(5660300002)(66946007)(71190400001)(71200400001)(102836004)(99286004)(76176011)(7736002)(53546011)(6506007)(305945005)(74316002)(229853002)(486006)(11346002)(476003)(446003)(2906002)(316002)(52536014)(8676002)(6666004)(186003)(14454004)(66446008)(64756008)(66556008)(66476007)(256004)(478600001)(14444005)(6916009)(46003)(81166006)(8936002)(81156014)(76116006)(7696005)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3759; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lVsA3PUXbHxD4Z4aJVQKxNMMALXq9+v0Ozdg0pEZQME+kXMKNIw6a66e7PlYWDQpIS96hhUZx1S/wAUo61TyIdJwB6anMLCLGj+nScLgWAAEyfR0rbotzKok3dlZdVGeBoR6lquDTcuh8JcKSsG9ydiTALmrtntzJJltJwPpMGZEm3uV+RQhZ/3dH2Hc99wc3wPQYPLAVJ9o44TkPTHvbdCrH+OsdMeqSDCntvVKUEIPYsbEmJRxSYEeGStaFCtuvE1hVv3EwyC41rDyR9G6VYlzYXjDmWQl8iHC6rly5kmEF+X2myU+dN0a1oum2/2Jk1QPmw32oa9iJkhU2fwH/KO0wAVhe5zudKlU8V6sz7fFnF8BebRqIw2oTtIkS78vDD6D7jI8KS5fzD2IMujDL76U/QOtVn3iV0PqUjxh010= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 379ce1c6-024a-4cd8-4210-08d72a0841d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 09:32:04.7527 (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: gqUPgUkwcv3nVAxQ6+NsDbNSWG5DtiRb8bjQQPLaywndmY4wHLWsa2dXXD06GdM99rly7O7jQoc5eK7ilTm+5g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3759 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Roll] comments on mopex-cap-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 09:32:12 -0000 Hello Michael There were headwinds against flooding the IESG with too many small document= s. Now, we ma be wrong in this case and I'm perfectly OK to split if the AD= s recommend to do so. In this case, we have 2 functions which, though logically separate, are bot= h needed infrastructure. This gives us an infrastructure uplift spec and a = single reference for all the work that will build on it.=20 As Rahul says some new components will need a bit of both at the same time.= So keeping together is defensible. All the best, Pascal > -----Original Message----- > From: Roll On Behalf Of Rahul Arvind Jadhav > Sent: dimanche 25 ao=FBt 2019 13:08 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] comments on mopex-cap-00 >=20 > Thanks Michael for the review and feedback. >=20 > Please find my comments inline. >=20 >=20 > 1) If Capabilities and MOD-Extension are mutually independent, why is it = in > one document? > [RJ] I raised the possibility of keeping it in separate document in IETF = 104. But > no one voiced any specific reason to separate it out. Even though semanti= cally > the Capabilities and MOP-Extns are mutually independent, some of the > scenarios discussions might require to discuss them together. Do you beli= eve > we should separate it out and if there is any advantage doing so? >=20 > 2) MOP clearly applies to the entire DODAG. > I don't know if Capabilities do from the description: >=20 > REQ3: Optional capabilities handshake. Capabilities are features, > possibly optional, which could be handshaked between the nodes > and the root within an RPL Instance. >=20 > Are they things that the root tells nodes, or things that the node > tells the root? >=20 > [RJ]: MOP is indicated by the root and the whole network has to follow it= . The > capabilities on the other hand are node specific. For e.g., the end node = can > indicate that it supports a primitive via cap flag and this info could be= used by > the root and vice-versa. > The answer to your questions above is, "Both". >=20 > Are they individualized, or does every node in the > LLN have to support a capability before it can be used? > [RJ]: Nice point. I haven't thought about this in detail. In non-storing = MOP, it > may not be required that all the nodes support capabilities but in storin= g > MOP, every 6LR needs to add the cap (if present) of the downstream child, > thus requiring every node to support it. This definitely needs handling i= n the > draft. > [Ref: https://github.com/roll-wg/MOPex-capabilities/issues/1] >=20 > 3) I argued before against the Extended-MOP-value being added to the Base > MOP. I prefer that the value 7 means *replace* the MOP with the MOPex. > Yes, that results in two ways to encode MOP=3D"3", but I think that it > leads to far less confusing code. > [RJ]: I am ok with this approach. Will update the document. > [Ref: https://github.com/roll-wg/MOPex-capabilities/issues/2] >=20 > 4) 3.2, if the MOP is not 7, and the MOPex is present, what does this mea= n? > (Nothing, I think it should be ignored) > Would we really ever assign a new the value 7? > [RJ] With point 3 accepted, this point is not relevant anymore. (?) >=20 > 5) section 4.0: >=20 > > Note that capabilities and MOPex are mutually exclusive and it is > > possible for an implementation to support either or both of the > > options. >=20 > I think that you mean, not mutually exclusive? > [RJ] I meant that caps and MOPex do not depend on each other and are > mutually independent. May be I should :s/exclusive/independent/ >=20 > 4.1: >There are no capability flags defined by this document. >=20 > that makes it really hard to know how they work :-) [RJ] Yeah, should hav= e > added an example. Will be done in the next update. > [Ref: https://github.com/roll-wg/MOPex-capabilities/issues/3] >=20 > 4.2: use of "could" is very non-normative. >=20 > > Capabilities > > advertised by non-root nodes are strictly a subset of the > > capabilities advertised by the root. >=20 > This should be in REQ3. > [RJ] Actually I am not sure that this will be true going forward. Why can= 't a > intermediate 6LR add its own capability in DIO (without depending on root= ) > for its downstream childs? If this is the case then the draft's above sta= tement > is not true. I am glad you pointed this out and wish to discuss more on t= his. >=20 > 7.1/7.3. If you take my advance about not adding, but replacing, then thi= s > document would Update the Mode of Operation registry, and we would not > need a new registry. >=20 > =3D=3D=3D=3D having done all of this. >=20 > How will DAO-projection signal itself? It seems like a capability to me. > I haven't read that document in a few months. If it uses capability, the= n this > document that creates capabilities SHOULD probably allocate a bit in it's= initial > table. > [RJ] I am considering this for the example use-case of caps >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Aug 26 07:58:21 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB0C120867 for ; Mon, 26 Aug 2019 07:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=L4Q4rZK8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CZK45LWo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhxYwjfRe2dG for ; Mon, 26 Aug 2019 07:58:09 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F77A12084F for ; Mon, 26 Aug 2019 07:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8086; q=dns/txt; s=iport; t=1566831489; x=1568041089; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=FGbrKJJYk6yAtctCI8zPr8/3LQda8rnCjHUyxOEBHlg=; b=L4Q4rZK862KmZ6czxKYad0GAfS9Kjr0IP3ZZuZ1Gksqyq65RN5bshD1n KCnV5KAHavSfVblFtOM0JK7XnInoeORO/WJ2OMEz2Tbp3tbpkYLFdFKtk R8rb6MdiHfXCasu82GkXAEgRw+trG8DlNbxR646Nm0Ph55IHsQ49CkXAZ I=; IronPort-PHdr: =?us-ascii?q?9a23=3AiNqqthTGZMoE7Lf/IyO0Gst11Npsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOCAAs8mNd/5RdJa1kHQEBBQEHBQG?= =?us-ascii?q?BZ4FFJCwDgUMgBAsqh2gDim5Ngg+XaIJSA1QJAQEBDAEBLQIBAYQ/AoJnIzg?= =?us-ascii?q?TAgoBAQQBAQECAQYEbYUtDIVKAQECAgESKAYBATgEDQEINkImAQQbGoRrAw4?= =?us-ascii?q?PAQKdKwKBOIhhgiWCewEBBYR/GIIWCYE0hH2GdRiBQD+BEUaCTD6ERoM7gia?= =?us-ascii?q?UVJcaCQKCHpRegjKWHY8elnACBAIEBQIOAQEFgWchgVhwFYMngkIMF4NPilN?= =?us-ascii?q?ygSmOJwEB?= X-IronPort-AV: E=Sophos;i="5.64,433,1559520000"; d="scan'208";a="319402047" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 14:58:08 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x7QEw8Sb007236 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 26 Aug 2019 14:58:08 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 09:58:07 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 10:58:06 -0400 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 09:58:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I4Xcuwsfp9ICjjTfQeq3wOej1UoOKhKQCAY7Lbmor5TzT441fSTMk71g2n6PB6A4cg2usB/brgpQzWmtqEs1WXT5XiT1RYmmv9XWRR1JR8hL8Geq5BmdJSdjEZ3w8Kyla9cnu4fVyP9zT7ovEofWDrHtCgtk0Mn7y5QWc5GkOxxkZjV+0CQEFZMTcvZ0d+p5fdNb97dUXXhqcxS2cQDFUeyqUu5cVBjypbJxfy64yA/4NOtzHO2XnnwvEl9uGYASDu47rBBuYGvoD2pS0OS/bWC1D88/fT+BGdE8JW+DU7fz0blNFV9WH6urrTgzkIj2wwE8lFVBg7itPHXrbizi0g== 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=mJ1iciJm/YLwumXx4ht3NNrtxaPUIwpl2/4D8tZbtuY=; b=Vc2UrUAwf8n0kvPEwNqD9oYEhhG16n8PEhFt5zpHm0ZS79ZjsUTVc2W+Yzo0CLqBBdYgd3ocCJt3R0jMNSgmB7ee9o6rSVIoa4kU8o9PUyYeue/PChlalqe0a3H7iqwdB0SgG4S1iPMcMvGFL8RGtqGbNNMs+YBcoeOWls4XfaGwI4LFpP8rEyWWcNV/r+PmSwyHkfaAWkYOst34V+sUgHH5DCIQ0KzwUYndN1l2Bn9acwdEsbji2Obscplo5HrzYfQxJ6MWGmVr/e+opa0kaWe0XcCrPG0TeJcAbYy9PQ090VClD5Xe2V6lWYWKN1aMgtjQoPJlxua9jCPRxgLssQ== 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=mJ1iciJm/YLwumXx4ht3NNrtxaPUIwpl2/4D8tZbtuY=; b=CZK45LWoCdRJh+B8Ceen5LPSX1YqJBUidUwHarl3XDkRPVn9I7iME3H95d7G3+5D4Q07lgfRWI/T8WQ9zFnqVEN4tm1ZQbqOuMIBZTPlWb02VXy5oaC1AdumXU/34LRoQnvUDO1RW3HrltxtOXDuIeAGmaXpzLUMUsMRqP6gvM4= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3758.namprd11.prod.outlook.com (20.178.253.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Mon, 26 Aug 2019 14:58:04 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 14:58:04 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] UNaware leaves: separating EDAR proxy from 'R"' flag processing Thread-Index: AdVcHnfKNmcwp4yRQFixHoiRz0Xm0w== Date: Mon, 26 Aug 2019 14:58:00 +0000 Deferred-Delivery: Mon, 26 Aug 2019 14:57:41 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1003::f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 739514ae-35f2-4d86-0cc4-08d72a35cc6d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3758; x-ms-traffictypediagnostic: MN2PR11MB3758: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01415BB535 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(376002)(366004)(346002)(199004)(189003)(51444003)(186003)(486006)(476003)(46003)(14454004)(99286004)(86362001)(7696005)(14444005)(256004)(66574012)(25786009)(6116002)(6916009)(229853002)(33656002)(8936002)(6246003)(66476007)(76116006)(66946007)(66556008)(66446008)(64756008)(6666004)(8676002)(52536014)(74316002)(6506007)(478600001)(71190400001)(71200400001)(6436002)(102836004)(81156014)(2906002)(53936002)(5660300002)(9686003)(316002)(55016002)(305945005)(7736002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3758; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: a1btNBt2vXELScOLYFK4ery72aKpKY3+NLQAlNTQ9LHvtPM/UNgMkDVvqfNSlC/4ELIhlg0SlJ3HJuQea4VfOik4Gp/mBcPApB4ieEdYfOckcz5AsBE7EUuEEqXt3SqNosU/YOuj/m7w2EO26Cihhyig2KeOT2sA1rAP8XVfg1GAjhJstMMaNech8hXl7F6vYWsK8o4F5bGSr4vfnK8n16FeqKdOiCvM4VQqltjGdr8mWQiQlS3vftwJUh2Qh/tfIYcEHnBuW/1ObWCn2iuZS6xloeqtx+KAHGD5km/AlVvlr/1cQ7maSrAkiopQ38LfL98HBwddtxvAqPKJELqj5xQFRoqU+1ZhwMN5qcqZQSaoSaJlfE23bELWbTPGDrqIg7EhGz3qD62fqm/uHDRV27fjPKO/J14QzkzsgNmSkIg= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 739514ae-35f2-4d86-0cc4-08d72a35cc6d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 14:58:04.7056 (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: DjWFREHVY+Gsi4uyPW0Yij13g4i4MO/hKAvtCGQMgZP9fj5B9pP8fOXQN6By3CljdFgzJcbdlPzIi6H5FRui7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3758 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Roll] UNaware leaves: separating EDAR proxy from 'R"' flag processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 14:58:19 -0000 Hello Michael: =20 > OLD: > In RPL terms, a plain host that does not > participate to the routing protocol is called a Leaf. It must be > noted that a 6LN could participate to RPL and inject DAO routes to > self, but refrain from advertising DIO and get children. In that > case, the 6LN is still a host but not a Leaf. >=20 > NEW: > In RPL terms, a plain host that does not contribute forwarding service= s > to the routing protocol is called a Leaf. > Such a 6LN would still contribute DAO routes to itself, but would refr= ain > from advertising DIOs, and will not have any children. >=20 > But, I'm rather unclear about this next part: > In that case, the 6LN is still a host but not a Leaf. >=20 > I think that it should say: > In the case where the 6LN does not contribute DAOs to inject routes > to itself, then the 6LN is a host but not a Leaf. >=20 That text was obsolete. At the time of the writing a RUL was not a leaf but= now we changed that, didn't we? I mean, useofrplinfo uses RAL and RUL. I think we agreed that anything connected to RPL but not routing is a leaf= , so no we have RAL and RUL. Such a 6LN would still contribute DAO routes to itself, but would refrain from advertising DIOs, and will not have any children. "When to use RFC 6553, 6554 and IPv6-in-IPv6" [I-D.ietf-roll-useofrplinfo] introduces the term RPL-Aware-Leaf (RAL) for that type of 6LN. In contrast, a RPL-Unaware Leaf (RUL) designates a leaf does not contribute to RPL but is reachable over a RPL network. In that case, the 6LN is a plain host that needs an interface to the RPL router to obtain routing services over the LLN. Note that this document introduces RAN that is either a RPL router or a RAL= . > Would be good to have a reference for the "kinetically powered light swit= ch." > I have asked some people for one, because we always talk about them in th= e > abstract. >=20 > I think that section 3 should be clearer about whether the "R" bit alread= y > exists or not. (It is part of 8505). I suggest: >=20 > > - The 'R' flag that is set if the Registering > - Node expects that the 6LR ensures reachability for the Registered Add= ress, > - e.g., by means of routing or proxying ND. > - > + This document specifies the use of the existing 'R' flag. It is to = be set > + if the Registering Node expects that the 6LR is to ensures reachabi= lity > + for the Registered Address, e.g., by means of routing or proxying N= D. > + > + Actually the use by the host is defined in RFC 8505. This specification def= ines the reaction of the router to the R flag setting.=20 What about [RFC8505] specifies the use of the 'R' flag by the Registering Node. The Registering Node sets the 'R' flag to indicate that the 6LR should ensure reachability for the Registered Address, e.g., by means of routing or proxying ND. This document specifies the behavior of the RPL router depending on the setting of the 'R' flag. >=20 > section 5: >=20 > The behavior defined in this specification [[whereby the 6LR that > processes the registration advertises the Registered Address in DAO > messages and bypasses the DAR/DAC process for the renewal of a > registration]], is only triggered by an NS(EARO) that has the 'R' flag > set. If the 'R' flag is not set, then the Registering Node is > expected to be a RAN router that handles the reachability of the > Registered Address by itself. >=20 > Can we just omit the [[]] part? It's really a mouthful. > Or give the behaviour a name/section number. > Maybe that means a section 3.1? >=20 Well it is a bit more complicated.=20 Seems to me that the suppression of DAR / DAC at the 6LR to be recreated by= the root should be done regardless of the 'R' flag. Any node will send a periodic NS (EARO) to its parent / router whether it i= s a RUL or a RAN of any sort . We want to have the root generate the keep a= live EDAR/EDAC to the 6LBR upon a DAO as opposed to the 6LR, to save a trav= ersal of the network.=20 One problem is for the 6LR to know if the root and the 6LBR have an agreeme= nt to do the keep-alive based on DAO. This needs to be signaled by the root= , we probably need a flag in the 6CO. Another is that the keep-alive DAO from the root is lacking the ROVR unless= we add an option in RPL to carry it. > Also I want to be clear that the "This document" in section 5 refer to un= ware- > leaves, and not RFC8505. >=20 4. Updating RFC 6550 This document specifies a new behavior whereby a 6LR injects DAO messages for unicast addresses registered through the updated 6LoWPAN ND [RFC8505] on behalf of leaves that are not RPL-aware. [RFC8505] specifies the use of the 'R' flag in the EARO by the Registering Node. With that specification, the Registering Node sets the 'R' flag to indicate whether the 6LR should ensure reachability for the Registered Address, e.g., by means of routing or proxying ND. Conversely, this document specifies the behavior of the RPL router depending on the setting of the 'R' flag. The 6LR advertises the Registered Address in DAO messages, if and only if it is triggered by an NS(EARO) that has the 'R' flag set, indicating that the 6LN is a RUL. If the 'R' flag is not set, then the Registering Node is expected to be a RAN that handles the reachability of the Registered Address by itself. As prescribed by [RFC8505], a RPL router SHOULD NOT set the 'R' flag, unless it relies on the 6LR to generate the DAO messages on its behalf. 5. Updating RFC 8505 [RFC8505] specifies a periodic Extended DAR/DAR exchange that takes place between the 6LR and the 6LBR. It is triggered by a NS(EARO) message and is intended to create and then refresh the corresponding state in the 6LBR for a lifetime that is indicated by the 6LN. Conversely, RPL [RFC6550] specifies a periodic DAO that maintains the routing state in the RPL network for a lifetime that is indicated by the source of the DAO. This means that there are two periodic messages that traverse the whole network to indicate that an address is still reachable, one to the root and one to the 6LBR. This specification enables to synchronize the liveness monitoring at the root and the 6LBR, which may or may not be the same node. A same value of lifetime is used for both, and a single keep alive message, the RPL DAO, traverse the RPL network. Upon the renewal of a 6LoWPAN ND registration, this specification changes the behavior of a RPL router acting as 6LR for the registration as follows: If the root indicates the capability to proxy the keep-alive EDAR/EDAC exchange, then the 6LR refrains from sending an EDAR message. If the root is separated from the 6LBR, it regenerates a keep-alive message to the 6LBR upon a DAO message. In that flow, the RPL Root acts as a proxy on behalf of the 6LR to refresh the state in the 6LBR, which saves the traversal of the network by a second keep-alive message. This document also specifies a keep-alive EDAR message that the RPL Root may use to maintain an existing state in the 6LBR upon receiving DAO messages. The keep-alive EDAR message may only act as a refresher and can only update the Lifetime and the TID of the state in the 6LBR. This document similarly specifies a keep-alive NS(EARO) message that the RPL Root may use to maintain an existing state in a 6BBR upon receiving DAO messages when the root is located on a same link as the 6LBR. The keep-alive NS(EARO) message may only act as a refresher and can only update the Lifetime and the TID of the state in the 6BBR. I'll continue with you review in another thread, this is already a lot! Many thanks Michael Pascal From nobody Mon Aug 26 09:31:42 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990AE120992 for ; Mon, 26 Aug 2019 09:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqF1f2YiHlUR for ; Mon, 26 Aug 2019 09:31:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1CB1200DF for ; Mon, 26 Aug 2019 09:31:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 548BE3818C for ; Mon, 26 Aug 2019 12:30:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6743289 for ; Mon, 26 Aug 2019 12:31:36 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <15452.1566593587@dooku.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Add ROVR in DAO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 16:31:41 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > Note that I do not know how to avoid keeping what we have in unaware > leaves today, that is the flow from the 6LR without a ROVR, and the > problem is as usual backward compatibility. I'll need to spend some time with some flows in front of me to understand the conflict. unaware leaves is not done, and not deployed, so can we just change it now then? It's a bit of a mirky swirl of time sequence diagrams for me right now. > We have to chose between yet another flag day / configuration bit > approach or to live with the keep alive as already described with no > ROVR as an option. > There's also the problem of knowing whether the 6LBR supports the keep > alive with no ROVR. That will need to be signaled. I feel there is a combinatorics of options here, and not a lot of ability to communicate them to RULs. Let's get the end point well described, and figure out if there are in fact way points in the middle which are worth while describing? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1kCWgACgkQgItw+93Q 3WUdCAf+NCWqxveWhSz1AmNvllO6nR9Ka3rZIgZcvFA5LiRnGlKOq4XiNu4o7tEf rGui3m0qDFxbbKyOyQZcd7nlBkGjPr9ehVXv19ob45SG+/GXV5x0e8Fh6dExHRVY XxFmiEVfLZjvLvmnrDI0ma14FOtFUGgj1cwN8rYGnq+IsBum6YbzlFWYIutYfqSA IVSY9gK4mXfJcHMhoz3LP1L0lMnxjeKUHJBMYnY5lAtF3UfIVSOWo3tXrrrUUrg4 wdnFj1EaSPWcnLwSipLyvBfYHJfw9fOu0S+pu774ixLm/JQgPfKhbIaX0bxLi3VH D4c/nz7JYArMble5Lr/DVX66FO89Tg== =zv4I -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 26 10:34:13 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244CD120AE2 for ; Mon, 26 Aug 2019 10:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=i4GcKgr1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MyOurcMa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqoDGh0eZK1S for ; Mon, 26 Aug 2019 10:34:08 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0759120AA2 for ; Mon, 26 Aug 2019 10:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9268; q=dns/txt; s=iport; t=1566840848; x=1568050448; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UYpiJIfhmLuNQXMAK5kfslgBNY5XbcdCadfG/X6Mnus=; b=i4GcKgr1I9+41sZv/ebJVKDSSN13fW2mhlFCnYPnvyIdTjuFawdL0xeE S2BeNvHXaIr26FjJPd/OPG+QEiC4xwB405GODpVv4Y7frvv0gAshU2CTG mvTHiQhzJSQLBxVVWc222zd7sfrnahjid/6krA68EmXzJMkcB6PHJXwdG Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AWQKlmRZZ3mDAefN6gjTdsjf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTCABfF2Rd/4MNJK1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBZ4FFJCwDgUMgBAsqh2gDim1Ngg+QCIdggUKBEANUCQEBAQwBAS0CAQG?= =?us-ascii?q?EPwKCZyM4EwIKAQEEAQEBAgEGBG2FLQyFSgEBAQEDEi4BATgLBAIBCBEEAQE?= =?us-ascii?q?vMh0IAQEEEwgahGsDHQECni0CgTiIYYIlgnsBAQWFARiCFgmBNIR9hnUYgUA?= =?us-ascii?q?/gRFGgkw+hAw6gzuCJpRUXJY+CQKCHo19hmGCMpYdjx6WcAIEAgQFAg4BAQW?= =?us-ascii?q?BZyGBWHAVgyeCQgwXg0+KU3KBKY4nAQE?= X-IronPort-AV: E=Sophos;i="5.64,433,1559520000"; d="scan'208";a="314828825" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2019 17:34:07 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x7QHY7LP027630 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 26 Aug 2019 17:34:07 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 12:34:06 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Aug 2019 13:34:05 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 26 Aug 2019 12:34:05 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LkUHifF217RUyp59JP9X2OcCLJp835UWH4uxyDIB7ehRo4c8/8uvV05526siGnhV7ZyiW4T2gFLqrq48Vk6zBHaRZFENYc08KJBIV9/ompqEr7sxn8C45UZZ9elsXAcm06b8iimDWyOpdt31OmBEsLJT+llY2atVfQgtYfY+nOmYJYuMlPcOML3vpwuBvnDSnNZmlnp9cIkSWvD4r/bbZYLTogHSm8JE2xcdO5+IuaK2LfVhIGi+OLzGZJg1Nd13rP15nd1ccnbA8BArBMRijN2CS5PZYGQRMZQo6SgMn4Av8gMLBjhLPS1lXFkXFVPNeyx110cz/65LzSilrnNSEA== 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=IG+UtDxV4c1PSKWQB2FfEKXbmzzk+N7ch2aanjiGhhk=; b=forWvY2TCYyCsXYYuH/1QtC+Shl0hgCtuhkrJk0ehpxhm7c7vmeN+juDB1SjN3iw8131Gl/OdIGECR/SyWQkT+CR+Y9BK/hVLH6DCBI2r5j98OTzpz7yqCsjgSQ+cfZyEX0eEM/8Cmuqzkwjh5oigeFqRmihecNVeYgl8enSbDLtVbV29IPJxmomjqethzAJvfYZhTGix8aG0Ax+NU7r5TRWqb8pgnFPD2bnHlrmLo2bcYPgu8xx8mpYPp/2qDsPCzCofRIWmH4w3XhE7zqFUBs+pQ8ZGKqCB8GCdGYijot9DjMASm6UKma+nnN+lhI17pr4LdthlSufS0658qH3Ew== 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=IG+UtDxV4c1PSKWQB2FfEKXbmzzk+N7ch2aanjiGhhk=; b=MyOurcMaILuxSwexqPzhmqk/tRnp/CO0MkAnnUGFw/r8L1hXTeDZcplo6mfmC3YgLTk4BBamtQMatmKPvXpdHFKM+3ETut0qFEVp2CLV42a3IWwiagp1tZ+BORcpXt4iBkXZRAbwylvB0R6dYnviq1Ip1Y1Ddt6GdqwWIj5YKhQ= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3616.namprd11.prod.outlook.com (20.178.251.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.19; Mon, 26 Aug 2019 17:34:04 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 17:34:04 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] UNaware leaves: separating EDAR proxy from 'R"' flag processing Thread-Index: AdVcHnfKNmcwp4yRQFixHoiRz0Xm0wAB5voA Date: Mon, 26 Aug 2019 17:33:37 +0000 Deferred-Delivery: Mon, 26 Aug 2019 17:32:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1006::74] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf286521-91cc-4d6b-341c-08d72a4b977d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3616; x-ms-traffictypediagnostic: MN2PR11MB3616: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01415BB535 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(376002)(346002)(396003)(13464003)(199004)(189003)(51444003)(229853002)(66946007)(86362001)(316002)(76116006)(256004)(478600001)(33656002)(2940100002)(66446008)(46003)(66476007)(14444005)(66556008)(64756008)(186003)(102836004)(305945005)(8936002)(8676002)(7736002)(6666004)(71190400001)(71200400001)(53546011)(74316002)(66574012)(6506007)(81166006)(81156014)(5660300002)(6436002)(25786009)(6116002)(6246003)(2906002)(53936002)(99286004)(9686003)(7696005)(14454004)(476003)(6916009)(55016002)(52536014)(486006)(76176011)(11346002)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3616; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: XHmuCncJ2NCuR/R81iz4slfumwZWgdSvvTFj+nfDDHpL4LJesg+fjt4PYo08uC1WzwE5aq4J4BV0+wNP+yGyR6SWly7jwwe6zT0ttG3+/EBJM9XAsBoG5Fgsd/TbcZzeFHFmtK3SYGMqLxuWKr8HbhD0jFdhUQ1awBxl6JsblQ0EYxvh9eJLb6xitkVUld9K2bYhizt4mpjbTPKTTTLgJAzPKCjdjgrwOfO9qi2ije3Pj3J9wyYcuCkST/2WH1R46wzqIiEA2B6Fo8LWrMfx0b/IHWHdJ8t20HHl1F4PFhyQLQM+2Ryd50jKlz82m8ZgGtnIeNGN34ZPPSBpeX3sleatT3zZdCpNDZWFz4sv27Na02WWRWfON29EzWfcOYmtAIGRbbdOrrSg+pNtIDeSQ8C5gWxnDASfxpUliypqX70= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cf286521-91cc-4d6b-341c-08d72a4b977d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 17:34:04.7344 (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: 7s/D2vGFjNiV0oT7aE/9AeYw+yDeBqaOie1KNsOZJdN3xo16VDoUa/ihyW8n5qxTDW2fOd/UchgFCrB4opB/Og== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3616 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Roll] UNaware leaves: separating EDAR proxy from 'R"' flag processing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 17:34:11 -0000 Dear all It would be neat to suppress the keep alive DAR across the network for all = 6LNs from the 6LN to the 6LBR.=20 The problem is that the 6LR needs to make sure that there is a DAO to trigg= er a proxy DAR from the root to the 6LBR to replace it. For a RUL the 6LR knows because it generates it. For a RPL aware node that = does its own DAOs, the 6LR may not see them (e.g., in non-storing mode). So suppressing the keep alive DAR would be on the faith that the 6LN does t= he right thing and injects a or whatever else will trigger a DAR to the 6LB= R. All the best, Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: lundi 26 ao=FBt 2019 16:57 > To: roll@ietf.org > Subject: RE: [Roll] UNaware leaves: separating EDAR proxy from 'R"' flag > processing >=20 > Hello Michael: >=20 > > OLD: > > In RPL terms, a plain host that does not > > participate to the routing protocol is called a Leaf. It must be > > noted that a 6LN could participate to RPL and inject DAO routes to > > self, but refrain from advertising DIO and get children. In that > > case, the 6LN is still a host but not a Leaf. > > > > NEW: > > In RPL terms, a plain host that does not contribute forwarding servi= ces > > to the routing protocol is called a Leaf. > > Such a 6LN would still contribute DAO routes to itself, but would re= frain > > from advertising DIOs, and will not have any children. > > > > But, I'm rather unclear about this next part: > > In that case, the 6LN is still a host but not a Leaf. > > > > I think that it should say: > > In the case where the 6LN does not contribute DAOs to inject routes > > to itself, then the 6LN is a host but not a Leaf. > > > That text was obsolete. At the time of the writing a RUL was not a leaf b= ut > now we changed that, didn't we? > I mean, useofrplinfo uses RAL and RUL. > I think we agreed that anything connected to RPL but not routing is a le= af, so > no we have RAL and RUL. >=20 > Such a 6LN would still contribute DAO routes to itself, but would > refrain from advertising DIOs, and will not have any children. "When > to use RFC 6553, 6554 and IPv6-in-IPv6" [I-D.ietf-roll-useofrplinfo] > introduces the term RPL-Aware-Leaf (RAL) for that type of 6LN. In > contrast, a RPL-Unaware Leaf (RUL) designates a leaf does not > contribute to RPL but is reachable over a RPL network. In that case, > the 6LN is a plain host that needs an interface to the RPL router to > obtain routing services over the LLN. >=20 > Note that this document introduces RAN that is either a RPL router or a R= AL. >=20 >=20 > > Would be good to have a reference for the "kinetically powered light > switch." > > I have asked some people for one, because we always talk about them in > > the abstract. > > > > I think that section 3 should be clearer about whether the "R" bit > > already exists or not. (It is part of 8505). I suggest: > > > > > > - The 'R' flag that is set if the Registering > > - Node expects that the 6LR ensures reachability for the Registered > Address, > > - e.g., by means of routing or proxying ND. > > - > > + This document specifies the use of the existing 'R' flag. It is t= o be set > > + if the Registering Node expects that the 6LR is to ensures reacha= bility > > + for the Registered Address, e.g., by means of routing or proxying= ND. > > + > > + >=20 > Actually the use by the host is defined in RFC 8505. This specification d= efines > the reaction of the router to the R flag setting. > What about >=20 > [RFC8505] specifies the use of the 'R' flag by the Registering Node. > The Registering Node sets the 'R' flag to indicate that the 6LR > should ensure reachability for the Registered Address, e.g., by > means of routing or proxying ND. This document specifies the > behavior of the RPL router depending on the setting of the 'R' flag. >=20 >=20 > > > > section 5: > > > > The behavior defined in this specification [[whereby the 6LR that > > processes the registration advertises the Registered Address in DAO > > messages and bypasses the DAR/DAC process for the renewal of a > > registration]], is only triggered by an NS(EARO) that has the 'R' fl= ag > > set. If the 'R' flag is not set, then the Registering Node is > > expected to be a RAN router that handles the reachability of the > > Registered Address by itself. > > >=20 >=20 >=20 > > Can we just omit the [[]] part? It's really a mouthful. > > Or give the behaviour a name/section number. > > Maybe that means a section 3.1? > > >=20 > Well it is a bit more complicated. >=20 > Seems to me that the suppression of DAR / DAC at the 6LR to be recreated = by > the root should be done regardless of the 'R' flag. > Any node will send a periodic NS (EARO) to its parent / router whether it= is a > RUL or a RAN of any sort . We want to have the root generate the keep ali= ve > EDAR/EDAC to the 6LBR upon a DAO as opposed to the 6LR, to save a travers= al > of the network. > One problem is for the 6LR to know if the root and the 6LBR have an > agreement to do the keep-alive based on DAO. This needs to be signaled by > the root, we probably need a flag in the 6CO. > Another is that the keep-alive DAO from the root is lacking the ROVR unle= ss > we add an option in RPL to carry it. >=20 >=20 > > Also I want to be clear that the "This document" in section 5 refer to > > unware- leaves, and not RFC8505. > > >=20 > 4. Updating RFC 6550 >=20 > This document specifies a new behavior whereby a 6LR injects DAO > messages for unicast addresses registered through the updated 6LoWPAN > ND [RFC8505] on behalf of leaves that are not RPL-aware. >=20 > [RFC8505] specifies the use of the 'R' flag in the EARO by the > Registering Node. With that specification, the Registering Node sets > the 'R' flag to indicate whether the 6LR should ensure reachability > for the Registered Address, e.g., by means of routing or proxying ND. >=20 > Conversely, this document specifies the behavior of the RPL router > depending on the setting of the 'R' flag. The 6LR advertises the > Registered Address in DAO messages, if and only if it is triggered by > an NS(EARO) that has the 'R' flag set, indicating that the 6LN is a > RUL. If the 'R' flag is not set, then the Registering Node is > expected to be a RAN that handles the reachability of the Registered > Address by itself. >=20 > As prescribed by [RFC8505], a RPL router SHOULD NOT set the 'R' flag, > unless it relies on the 6LR to generate the DAO messages on its > behalf. >=20 > 5. Updating RFC 8505 >=20 > [RFC8505] specifies a periodic Extended DAR/DAR exchange that takes > place between the 6LR and the 6LBR. It is triggered by a NS(EARO) > message and is intended to create and then refresh the corresponding > state in the 6LBR for a lifetime that is indicated by the 6LN. > Conversely, RPL [RFC6550] specifies a periodic DAO that maintains the > routing state in the RPL network for a lifetime that is indicated by > the source of the DAO. This means that there are two periodic > messages that traverse the whole network to indicate that an address > is still reachable, one to the root and one to the 6LBR. This > specification enables to synchronize the liveness monitoring at the > root and the 6LBR, which may or may not be the same node. A same > value of lifetime is used for both, and a single keep alive message, > the RPL DAO, traverse the RPL network. >=20 > Upon the renewal of a 6LoWPAN ND registration, this specification > changes the behavior of a RPL router acting as 6LR for the > registration as follows: If the root indicates the capability to > proxy the keep-alive EDAR/EDAC exchange, then the 6LR refrains from > sending an EDAR message. If the root is separated from the 6LBR, it > regenerates a keep-alive message to the 6LBR upon a DAO message. In > that flow, the RPL Root acts as a proxy on behalf of the 6LR to > refresh the state in the 6LBR, which saves the traversal of the > network by a second keep-alive message. >=20 > This document also specifies a keep-alive EDAR message that the RPL > Root may use to maintain an existing state in the 6LBR upon receiving > DAO messages. The keep-alive EDAR message may only act as a > refresher and can only update the Lifetime and the TID of the state > in the 6LBR. >=20 > This document similarly specifies a keep-alive NS(EARO) message that > the RPL Root may use to maintain an existing state in a 6BBR upon > receiving DAO messages when the root is located on a same link as the > 6LBR. The keep-alive NS(EARO) message may only act as a refresher > and can only update the Lifetime and the TID of the state in the > 6BBR. >=20 >=20 > I'll continue with you review in another thread, this is already a lot! >=20 > Many thanks Michael >=20 > Pascal From nobody Mon Aug 26 16:57:33 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C83120811 for ; Mon, 26 Aug 2019 16:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YViO_Qia11Nj for ; Mon, 26 Aug 2019 16:57:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB1012080F for ; Mon, 26 Aug 2019 16:57:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 15DE13818E for ; Mon, 26 Aug 2019 19:56:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9EF9A89 for ; Mon, 26 Aug 2019 19:57:27 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> References: <14914.1566593238@dooku.sandelman.ca> <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] comments on mopex-cap-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 23:57:32 -0000 --=-=-= Content-Type: text/plain Rahul Arvind Jadhav wrote: RJ> I raised the possibility of keeping it in separate document in IETF RJ> 104. But no one voiced any specific reason to separate it out. Even RJ> though semantically the Capabilities and MOP-Extns are mutually RJ> independent, some of the scenarios discussions might require to RJ> discuss them together. Do you believe we should separate it out and RJ> if there is any advantage doing so? I think that it will be easier for reviewers if the two parts are clearly separated. On the other hand, both parts deal with how to do extensions to the RPL control plane, and there is a non-trivial fixed cost to processing an RFC. mcr> 2) MOP clearly applies to the entire DODAG. I don't know if mcr> Capabilities do from the description: doc> REQ3: Optional capabilities handshake. Capabilities are features, doc> possibly optional, which could be handshaked between the nodes and the doc> root within an RPL Instance. mcr> Are they things that the root tells nodes, or things that the node mcr> tells the root? RJ> MOP is indicated by the root and the whole network has to follow RJ> it. The capabilities on the other hand are node specific. For e.g., RJ> the end node can indicate that it supports a primitive via cap flag RJ> and this info could be used by the root and vice-versa. The answer RJ> to your questions above is, "Both". okay, so probably need to have two requirements, and we need to clearly delineate the two behaviours. mcr> Are they individualized, or does every node in the LLN have to support mcr> a capability before it can be used? rj> Nice point. I haven't thought about this in detail. In non-storing rj> MOP, it may not be required that all the nodes support capabilities rj> but in storing MOP, every 6LR needs to add the cap (if present) of rj> the downstream child, thus requiring every node to support it. This rj> definitely needs handling in the draft. [Ref: rj> https://github.com/roll-wg/MOPex-capabilities/issues/1] I'll start a new thread. > 5) section 4.0: doc> Note that capabilities and MOPex are mutually exclusive and it is doc> possible for an implementation to support either or both of the doc> options. mcr> I think that you mean, not mutually exclusive? rj> I meant that caps and MOPex do not depend on each other and are rj> mutually independent. May be I should :s/exclusive/independent/ yes. mcr> How will DAO-projection signal itself? It seems like a capability to mcr> me. I haven't read that document in a few months. If it uses mcr> capability, then this document that creates capabilities SHOULD mcr> probably allocate a bit in it's initial table. RJ> I am considering this for the example use-case of caps If DAO-projection references this document, then they will likely become a set when published, and we coud probably get them reviewed together. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1kcecACgkQgItw+93Q 3WWW6wf/WcuJPoELbtirdJrUZlLEOQfpPEyYYqfwaT7WbyZTNlgqfDQfIZpg4fPq QP6nj/FW9CsRPg0IEzhzrzjjTQ2VfK1UkH9G0xwL5sHNN/mdynazMPsA/FaIPTA8 /7vZxhqLxlmrrxkFUXZngeAehq63BaemSEXVy2Td751Ygf6s2znAb9y+fL9fyEa0 p0QieKQV0rBsLuD5X6OAA+3DqcuX2+AtelVQecHwa9RimNlnFRRUFaJSoSGdrUWf vOqvsp/cUGvwIXyh1OrodBhuJ0ySM8AkqZynoxVzmGAGuMjtoJVkKQyMQwTCJwTU Y9lPzZbSWTpF1w4whnH6mHHt0puhyw== =8SS4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 26 17:46:50 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FA1120818 for ; Mon, 26 Aug 2019 17:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMoJryIWXOCo for ; Mon, 26 Aug 2019 17:46:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879A8120817 for ; Mon, 26 Aug 2019 17:46:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C2A0B380BE for ; Mon, 26 Aug 2019 20:45:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 63259AD4 for ; Mon, 26 Aug 2019 20:46:45 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> References: <14914.1566593238@dooku.sandelman.ca> <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Roll] do capabilities need to understood, can they be added? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 00:46:50 -0000 --=-=-= Content-Type: text/plain I asked: mcr> Are they individualized, or does every node in the LLN have to support mcr> a capability before it can be used? Rahul Arvind Jadhav wrote: rj> Nice point. I haven't thought about this in detail. In non-storing rj> MOP, it may not be required that all the nodes support capabilities rj> but in storing MOP, every 6LR needs to add the cap (if present) of rj> the downstream child, thus requiring every node to support it. This rj> definitely needs handling in the draft. [Ref: rj> https://github.com/roll-wg/MOPex-capabilities/issues/1 I see: 1) the root announces a capability. 6LRs that understand it may use the new capability unilaterally if they understand it, and see a need for it. Nodes that do not understand the new capability are not affected. This could be a control plane thing, or a data plane thing. 2) the root announces support for capability that it wishes to enable, in order for it be used, every node must support it. If every DAO from every node supports the capability, then the root announces that it is turned on. This in effect is a two-pass system, requiring either two capability bits. It might be that it is better to encode these two bits are three values (plus 00-not supported). 3) any 6LR may announce a capability to it's children that it received from it's parent, if it understands that capability. If it does not, then it MUST clear the capability. This can be a unilateral capability (like 1), or one that has to be confirmed (like 2). So this is really 3A and 3B. 4) any 6LR may announce a capability to it's children, even if it did not receive it from a parent. The capability is not to be repeated by the children (regardless of whether they understand it), unless they also wish to enable it. I therefore see several issues to resolve. For capabilities that a node understands, it can know which type of capability it is. For a capability that is unknown, if the behaviour is other than "set to zero", then we need to tell the node what kind of capability it is, and how it is encoded. Counting above, I see (1)-available, (2)-query, (2)-enable, (3)-available, (3)-query, (3)-enable, (4)-available. Conveniently, 7 things, plus all zeros. We could encode capabilities in three bits, so the behaviour would be part of the encoded. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1kfXUACgkQgItw+93Q 3WVUeAf/Wforkj435e/7YRny+op1sqyC5rmOJCi3KRQ/Ne2XOOkfTIccvxwUp0Nd f39Q0Pg8cSskSwUlNqQpcKw5W9HNKpJuE0oaqZSdX0140MA6WTAhlzA5rB1KTrHD 7N4SepGfYYjvoWqS8YT5WlvY5DfxxfA91Guo7mcYQFjzOkQ8Y4q2B4g23lJWcADb q74WWcyjF/RfoLi3U4+VxuK9HWS5FqJkRmSky8rAJKil7y3qcE/WtuqSsA2ngz+o aZU3ew+y0KjPsUb2ukczjBYnmzjjCCNhuMUjuFyY0tgsH6Wv7BnJVTla0KNBWhNw d5Z+mLj5dfuts87d+bLpYrh7uNcGeA== =N5QV -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 27 00:37:23 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0AC120018 for ; Tue, 27 Aug 2019 00:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fk9PpZOcYhI for ; Tue, 27 Aug 2019 00:37:20 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 E502F12004A for ; Tue, 27 Aug 2019 00:37:19 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id j4so35722040iog.11 for ; Tue, 27 Aug 2019 00:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iaSZhCDmvNNYEkr0xLH2RJQC94yjcu9dyVClAqJvm4U=; b=qBleyBY55tK7vQlGQQr6MWq90tYfNEpBTVchAjH+WrwC6ZhBxyq/vzM5MGG1fwILFB N2OfBEQ2B7z4cw9qSQSi+FDrNISyKq9mqJsXaqx2/nvqo+eOepf7cvG8b0tkbr1JGPFs H33egzbJpLzqsjpjDjyp6a3jxBPq+hPtQhcw5UbgVV5i8LgQOpdyMIXRV/Qwq0YnZCIJ uQ6hRUPZsd3iOylry7XA/zlr3P7wU4mIzEnDGlGG2IFGjy7MtcME5UlfaPUBy74xAp98 gF4W0233aDPkHC+9CmFkHPeIErknIOr6gKJW4sVkHpNnIK0rYCr3vUUN5EDgufu0D2yU FioQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iaSZhCDmvNNYEkr0xLH2RJQC94yjcu9dyVClAqJvm4U=; b=U6Di7wab/sWKSKC/X7r1Mp8y0TPDaxN0V/Rhdr2QY9TfjuumSZUJPnVauBTNbD0KP7 wuonfWWSznNZG33imcIOELuh3brq0MSSPyfB5p/a+jUV9S67n5OP/NN+6QiBDx+agC/v +jpyFHcIam50CnELcer2IYX5KfsyLFyhulOAOFZNnJTflMUd+lzy5aDOhC76SYrlmfmp uJWqGoBvH7Hw1EA7vkcwfnkqhJ4CMWB1FVTYCuMkPILj3crhEXRWRcqZ0TqGpD1Vlf+S zPY2pMWc335gQmnz83wpQWkWqoSnCWvIjutrk3VHaWIpACAXDXFOwp3JXoXabgZCVznu AWKA== X-Gm-Message-State: APjAAAXnSyRu1EYY2NSc865wsd0yy1Jk8I47NqsjDM3y34BqEybqzzsz BSNB6GxBL8g87jl93v4W84KSkK4SUggUHLSDDrVGAA== X-Google-Smtp-Source: APXvYqx28adGS8QBlIOm3nv67PvJx/o3/AuSTygdAyyY5N/W/cDSCTJLXqafi/fmifPk8P85iHFos98p3JwN2hn/2T8= X-Received: by 2002:a6b:8d90:: with SMTP id p138mr16712031iod.282.1566891438676; Tue, 27 Aug 2019 00:37:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Tue, 27 Aug 2019 10:37:07 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="0000000000009aa7a205911457fd" Archived-At: Subject: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 - Extended X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 07:37:22 -0000 --0000000000009aa7a205911457fd Content-Type: text/plain; charset="UTF-8" Dear all, We extend this WG adoption call until 10 September. It would be nice to have your opinion on this. Thank you very much in advance, Ines and Peter. On Thu, Aug 8, 2019 at 4:19 PM Ines Robles wrote: > Dear all, > > This is a call for WG adoption of the > draft draft-richardson-6tisch-roll-enrollment-priority-02. > > The call starts today 08-08-2019 until 08-22-2019. > > Please let us know your opinion on this. > > Thank you in advance, > > Ines and Peter. > --0000000000009aa7a205911457fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

We exten= d this WG adoption call until 10 September.=C2=A0

= It would be nice to have your opinion on this.

Tha= nk you very much in advance,

Ines and Peter.
=

= On Thu, Aug 8, 2019 at 4:19 PM Ines Robles <mariainesrobles@googlemail.com> wrote:
Dear = all,

This is a call for WG adoption of the draft=C2=A0dr= aft-richardson-6tisch-roll-enrollment-priority-02.

The call starts today 08-08-2019 until 08-22-2019.

Please let us know your opinion on this.

Thank y= ou in advance,

Ines and Peter.
--0000000000009aa7a205911457fd-- From nobody Tue Aug 27 06:18:38 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8A120073 for ; Tue, 27 Aug 2019 06:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaczmE21hM4R for ; Tue, 27 Aug 2019 06:18:34 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D27612003F for ; Tue, 27 Aug 2019 06:18:34 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4016478BFF88F061482F for ; Tue, 27 Aug 2019 14:18:32 +0100 (IST) Received: from lhreml720-chm.china.huawei.com (10.201.108.71) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 27 Aug 2019 14:18:31 +0100 Received: from lhreml720-chm.china.huawei.com (10.201.108.71) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 27 Aug 2019 14:18:31 +0100 Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 27 Aug 2019 14:18:31 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.145]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Tue, 27 Aug 2019 18:48:23 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] do capabilities need to understood, can they be added? Thread-Index: AQHVXHD2ayN5rouNOkKTBdc8Jbrn/qcO3hNw Date: Tue, 27 Aug 2019 13:18:23 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DFB9417@BLREML503-MBX.china.huawei.com> References: <14914.1566593238@dooku.sandelman.ca> <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> <22118.1566866805@localhost> In-Reply-To: <22118.1566866805@localhost> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] do capabilities need to understood, can they be added? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 13:18:37 -0000 mcr> Are they individualized, or does every node in the LLN have to sup= port mcr> a capability before it can be used? Rahul Arvind Jadhav wrote: rj> Nice point. I haven't thought about this in detail. In non-storing rj> MOP, it may not be required that all the nodes support capabilities rj> but in storing MOP, every 6LR needs to add the cap (if present) of rj> the downstream child, thus requiring every node to support it. This rj> definitely needs handling in the draft. [Ref: rj> https://github.com/roll-wg/MOPex-capabilities/issues/1 I see: 1) the root announces a capability. 6LRs that understand it may use the new capability unilaterally if they understand it, and see a need for it= . Nodes that do not understand the new capability are not affected. This could be a control plane thing, or a data plane thing. [RJ] The problem may be in the other direction, .. In storing MOP, how=20 should a 6LR which does not understand capability treat a DAO containing=20 capability? Also how should a 6LR treat an unknown option in general?=20 6550 mentions how to treat unknown RPL code but there is no handling=20 for unknown option in DIO/DAO. Is there? I searched and could not find. Most of the existing implementations just ignore what they don't=20 understand. 2) the root announces support for capability that it wishes to enable, in order for it be used, every node must support it. If every DAO from every node supports the capability, then the root announces that it is turned on. This in effect is a two-pass system, requiring either two capability bits. It might be that it is better to encode these two bits are three values (plus 00-not supported). [RJ] Another scenario could be that Root announces support for an=20 optional capability. The 6LN just needs to know whether it could=20 make use of this capability of the root to do something. It may not=20 need to reply back to the root saying I see it and I support it. Also should we be using two capability bits or we could use the info=20 on whether the bit is set in DIO/DAO to infer the direction. 3) any 6LR may announce a capability to it's children that it received from it's parent, if it understands that capability. If it does not, then it MUST clear the capability. This can be a unilateral capability (like 1), or one that has to be confirmed (like 2). So this is really 3A and 3B. [RJ] I get 3A .. but do we really need 3B. I mean if the node also needs=20 to indicate that it also supports the same capability to the root then it=20 can set the same bit in the DAO and send it back ... Thus working in=20 both directions. It may not be required that capabilities be handshaked=20 in both directions mandatorily. For e.g., root may indicate the capability= =20 that it has access to 6BBR and that unaware leaves could register=20 through 6LRs. Thus 6LRs could proxy the NS (EARO) and other relevant=20 messages. In this case, is it needed that 6LR reply back to the root=20 saying it supports unaware leaves? There might be another example which requires 6LRs/6LNs to indicate in the reply that it supports the feature asked by root using the same=20 cap bit in DAO. The DIO/DAO decides the direction but the bit can be=20 the same. 4) any 6LR may announce a capability to it's children, even if it did not receive it from a parent. The capability is not to be repeated by the children (regardless of whether they understand it), unless they als= o wish to enable it. [RJ] agree I therefore see several issues to resolve. For capabilities that a node understands, it can know which type of capabil= ity it is. For a capability that is unknown, if the behaviour is other tha= n "set to zero", then we need to tell the node what kind of capability it i= s, and how it is encoded. Counting above, I see (1)-available, (2)-query, (2)-enable, (3)-available, = (3)-query, (3)-enable, (4)-available. Conveniently, 7 things, plus all zer= os. We could encode capabilities in three bits, so the behaviour would be = part of the encoded. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Tue Aug 27 09:59:55 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C0A120875 for ; Tue, 27 Aug 2019 09:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fJ/2Vhoz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YndYCdqC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0uS_xEYKl8K for ; Tue, 27 Aug 2019 09:59:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA41F12084C for ; Tue, 27 Aug 2019 09:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3694; q=dns/txt; s=iport; t=1566925178; x=1568134778; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0C3Wd4/fuj0w7dCbN9FP/aZKmwMsnmNU3naoI9XJtU8=; b=fJ/2VhozSVPk09Zhn0K5vogPbMS3eVw89vkFOJhJbTSIPsxkFP3ypdJw nqbPzQovIoK3Eg9+NyeJLLQI8mT6BzYZG07JpYYBFdrjtj+2zIturK9Zf pBTYaq9N4plXO2HahUpD/JOUnVLPurVXJnICuEiHoy9ZTD8arxb4x6/6O 0=; IronPort-PHdr: =?us-ascii?q?9a23=3ASRdK3B1ZMlV3t6aPsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHCQD6YGVd/49dJa1lHQEBBQEHBQG?= =?us-ascii?q?BZ4FFUANtViAECyqHaAOKc02CD5dpgUKBEANUCQEBAQwBASMKAgEBhD8CgkY?= =?us-ascii?q?jOBMCCgEBBAEBAQIBBgRthS4MhUoBAQEDARIoBgEBOAQLAgEINhAyJQIEGxq?= =?us-ascii?q?DAYFqAw4PAQIMoBcCgTiIYYIlgnsBAQWFBRiCFgMGgTSLdRiBQD+BEUaCTD6?= =?us-ascii?q?CYQKBSRqDO4ImjDOfQAkCgh6Gao15gjKHMIpUhCCVWZA8AgQCBAUCDgEBBYF?= =?us-ascii?q?nIYFYcBWDJ4JCDBeDT4pTcoEpjh4BAQ?= X-IronPort-AV: E=Sophos;i="5.64,438,1559520000"; d="scan'208";a="620833037" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2019 16:59:37 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x7RGxbfS030369 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Aug 2019 16:59:37 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 27 Aug 2019 11:59:37 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 27 Aug 2019 11:59:36 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 27 Aug 2019 12:59:36 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HjrRxZ7I+Rq7ioLtaA6NoZ9F/0xwVdRWTikawP8ZvE1z4e3ryhL58iqIUJl85lwGKGkr1QtL2oUokCIu2ZSZXtg68PGTSbKZygB1DzYphh62S2EXA3TBoRAsprrWEANkd9mc8zao/aiwyJZeg1Pk4sF6FVIFTaQkOyd4N+PCLPFSD9OCmnmLrOWNwySDOQ8PwHeKIHklzQ0Ip0jNxe+MR7fpGwbDq2+rFungJk3jeyt2jgyRqxS4XLrz6+X4Sem7JoL+9bOSg4q2ntLs2uGictk2F+G1IYLxWRf5xNouHDFvx0KVrYGFjAO7U6kVwo2BKVy9+cV/4a1pqwYauWQ+sQ== 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=JUefuIsbW/0x1JHI13O9wOuu7CY+HWgv87dy70xSCtE=; b=A+dHmrKJURKq6ED9RKKzuKilfwW2EjkWI6MmVAnaxuzXDNmuutZtIMFn9g52qUNdgyHmAgyP0+niXcOXHjfCMjhnsMboRzJfofzITvu080/GJlnYl8b89waZbjSjU/w3ijtdjHbi4FVvL3b2GtxDIQnwdLQRMIVKGjfow6rgukJ8JlM4rEIuts0rDxJxHSI+/8ed1bdKjQfnxrQNjdrqxW2JjdLZ4U2bML/QF87Chtuj1vksSV1ee+Rw4F8OxmHfo5Newef8CHMJGA4l3N9jfqH08+1cv0a/Sul12yatfM8l4eMm7d/g4YAkJOokgv8p5DjoRU0StsZXUU9NJcvxsg== 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=JUefuIsbW/0x1JHI13O9wOuu7CY+HWgv87dy70xSCtE=; b=YndYCdqChNmqhPwZqbVBj8tZOEyuHAUNIOdf7v4nviDpc6ybVz0zeywrM3pl4CwLcFEwTYIlpmKDWgDX7jri8PSEvGIQm1sGyU7sNIJW4Efs3XJDIa15Htsy96TYAux10yS1xOzyDLSgIy/UZMBsPFRuUhHghCuzt+Mt2Gy86zM= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3551.namprd11.prod.outlook.com (20.178.250.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Tue, 27 Aug 2019 16:59:34 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2199.021; Tue, 27 Aug 2019 16:59:34 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] UNaware leaves Thread-Index: AQHVWfFjezBBAmRk80qIlWys7+Zg/qcO7pFA Date: Tue, 27 Aug 2019 16:59:07 +0000 Deferred-Delivery: Tue, 27 Aug 2019 16:59:01 +0000 Message-ID: References: <14058.1566592130@dooku.sandelman.ca> In-Reply-To: <14058.1566592130@dooku.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:8170:98a7:7988:d19d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 961c52b2-4b7b-426b-1542-08d72b0ff018 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3551; x-ms-traffictypediagnostic: MN2PR11MB3551: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0142F22657 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(376002)(346002)(396003)(43544003)(199004)(189003)(51444003)(25786009)(102836004)(966005)(46003)(2906002)(486006)(6246003)(66476007)(6916009)(76176011)(476003)(478600001)(316002)(256004)(7736002)(446003)(52536014)(99286004)(229853002)(14454004)(11346002)(305945005)(74316002)(186003)(66446008)(66556008)(6116002)(66946007)(6506007)(55016002)(71200400001)(53936002)(71190400001)(8676002)(5660300002)(81166006)(81156014)(86362001)(9686003)(7696005)(6666004)(76116006)(8936002)(33656002)(6436002)(64756008)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3551; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AA/inPPpqX2/nVf5tFEooWfB9a06rE7tO4qsjryjlAE6BrigSjBG0ZZf87vX28jvOlTLKwgJIAJEQW2wqPX03j8ahmr/Fr2rTaQz+qVTWT15yfpczzKk5HtnIbcsQMq4tXMltLVYy+gaCjQQkRE7ZOkJTHAEINvOX+uP4pXg6Y0/X3pZ4/35x13cHvbegX3myapn0Z6V2QxPADjqBFdphV7oW+aV2dBXQIiuPScvVLfctfkCVoXDwM3A6iAEVJBDTlTlz9yZSAEDGdhkgtgbBNjRuu+PVUL6WQBPErJLfXZ7VC1gj+2eDXg7vvqeDclFrZ4OAJxQ3xzrIE8mDhcOjzh290nZldMHXtXRhy48RP/yYMU+nmhFSbDAal8+QAD0kVrLnFqe3sRhX+jdxLOgU70Eudq31xlG4Zf5tsIG6uk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 961c52b2-4b7b-426b-1542-08d72b0ff018 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2019 16:59:34.8338 (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: KI+64LB1vgb/eYma4SuPWMe4B70cFJB6227lT+YypMSY42zr711VsDjHFiMkeRsI3zg9EUxdv8+dFQNaeGe1DA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3551 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Roll] UNaware leaves X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 16:59:53 -0000 Continuing ... All: Considering the efforts Michael placed in that review I invited him to= coauthor. We now use github to collaborate and the WIP is in https://github.com/roll-= wg/roll-unaware-leaves/=20 Michael: Please see below > section 6 is rather all over the place. > I'd like subsection points, because we are going to need to refer to the = sections, I can propose this: 6. 6LN Requirements to be a RPL-Unware Leaf . . . . . . . . . . 9 6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 9 6.2. IPv6 Host Support of RPL Artifacts . . . . . . . . . . . 9 6.2.1. Support of the HbH Header . . . . . . . . . . . . . . 9 6.2.2. Support of the Routing Header . . . . . . . . . . . . 10 6.2.3. Support of IPv6 Encapsulation . . . . . . . . . . . . 10 > and there will be 6man interaction? > Could the whole section be named, "6LN Requirements to be a Unware Leaf". > Can we get a 6man reviewer for this sooner? >=20 Renamed.=20 Note that the dependencies on IPv6 do not change IPv6, just requires an IPv= 6-compliant support by the host. Not sure we need 6MAN help for that. > > or not. The flows below are RPL Non-Storing Mode examples. In > > Storing Mode, the DAO ACK may not be present, and the DAO messages > > cascade from child to parent all the way to the DODAG Root. >=20 > Actually, isn't the K-flag behaviour this still an open issue in the WG? > Or did we resolve this somewhere? Last I recall it was in Rahul's big do= cument, > not in something we had adopted. There was never really an issue. There is a trick in one open source implem= entation (Kontiki) for an end-to-end ack that was useful for their use case= . But that is non-standard. The RUL draft reminds the normal expectation of RPL, that is a hop by hop a= ck. As I said on the mike at an early WG meeting, if the parent acks it tak= es responsibility to progress the DAO. If later the parent fails to progress the DAO, it should stop being a paren= t and poison to the child can use some other path to progress the DAO towa= rds the root.=20 Once the DAO reaches the root, the address becomes reachable. >=20 > I think that 7.1, if it is general flow, shouldn't try to do storing and = non-storing > mode. Either have two sections, or omit the differences in the general f= low, and > deal with the details in subsequent sections. >=20 I made a step, to be improved, by adding the storing mode flow > I think that maybe the general flow should omit the backbone registration= . > Explain it all without a backbone, and then do it again with backbone. >=20 Removed the BBR for now > > This specification does not alter the operation of a 6LoWPAN ND- > > compliant 6LN, which is expected to operate as follows: >=20 > really... I thought that we were making it able to deal with RPL artifact= s, as > specified in section 6!!! Which is as should already be. That's not even 6LoWPAN ND, that's IPv6 if y= ou look at it. > What is the specific signal that the 6LR can use to know that the host is= an RAN > rather than a RUL? Yes we have text, maybe even repeated with terminology; e.g.,=20 " The 6LR advertises the Registered Address in DAO messages, if and only if it is triggered by an NS(EARO) that has the 'R' flag set, indicating that the 6LN is a RUL. If the 'R' flag is not set, then the Registering Node is expected to be a RAN that handles the reachability of the Registered Address by itself. " More tomorrow. I committed what I had up to here in github. Take care, Pascal From nobody Tue Aug 27 10:49:21 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D291212012E for ; Tue, 27 Aug 2019 10:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIZepTDOouPq for ; Tue, 27 Aug 2019 10:49:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E141200C7 for ; Tue, 27 Aug 2019 10:49:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 48E263818F for ; Tue, 27 Aug 2019 13:48:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 019B689 for ; Tue, 27 Aug 2019 13:49:15 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB9417@BLREML503-MBX.china.huawei.com> References: <14914.1566593238@dooku.sandelman.ca> <982B626E107E334DBE601D979F31785C5DFB7878@BLREML503-MBX.china.huawei.com> <22118.1566866805@localhost> <982B626E107E334DBE601D979F31785C5DFB9417@BLREML503-MBX.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] do capabilities need to understood, can they be added? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 17:49:19 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Rahul Arvind Jadhav wrote: mcr> Are they individualized, or does every node in the LLN have to mcr> support a capability before it can be used? > Rahul Arvind Jadhav wrote: rj> Nice point. I haven't thought about this in detail. In non-storing rj> MOP, it may not be required that all the nodes support capabilities rj> but in storing MOP, every 6LR needs to add the cap (if present) of rj> the downstream child, thus requiring every node to support it. This rj> definitely needs handling in the draft. [Ref: rj> https://github.com/roll-wg/MOPex-capabilities/issues/1 > I see: > 1) the root announces a capability. 6LRs that understand it may use > the new capability unilaterally if they understand it, and see a need > for it. Nodes that do not understand the new capability are not > affected. This could be a control plane thing, or a data plane thing. RJ> The problem may be in the other direction, .. In storing MOP, how RJ> should a 6LR which does not understand capability treat a DAO RJ> containing capability? Also how should a 6LR treat an unknown option RJ> in general? 6550 mentions how to treat unknown RPL code but there RJ> is no handling for unknown option in DIO/DAO. Is there? I searched RJ> and could not find. Most of the existing implementations just igno= re RJ> what they don't understand. There is the case where an implementation does not understand the capability extension, in which case, it likely does not copy it down, and no node below that node can use that capability, even if would be safe. The children cou= ld hear other DIOs via other paths, so all is not lost. I'm trying to address the case where the capability extension is passed on, but the node may not know the specific capablity that was listed. > 2) the root announces support for capability that it wishes to enable, > in order for it be used, every node must support it. If every DAO fr= om > every node supports the capability, then the root announces that it is > turned on. This in effect is a two-pass system, requiring either two > capability bits. It might be that it is better to encode these two > bits are three values (plus 00-not supported). RJ> Another scenario could be that Root announces support for an option= al RJ> capability. The 6LN just needs to know whether it could make use of RJ> this capability of the root to do something. It may not need to rep= ly RJ> back to the root saying I see it and I support it. Also should we = be RJ> using two capability bits or we could use the info on whether the b= it RJ> is set in DIO/DAO to infer the direction. That's case (1). Case (2) is where the root wants to enable use of some capability, but to do so, it needs to know if all nodes support it. This where we need a discover operation followed by an enable operation.=20=20 > 3) any 6LR may announce a capability to it's children that it received > from it's parent, if it understands that capability. If it does not, > then it MUST clear the capability. > This can be a unilateral capability (like 1), or one that has to be > confirmed (like 2). So this is really 3A and 3B. RJ> I get 3A .. but do we really need 3B. I mean if the node also needs RJ> to indicate that it also supports the same capability to the root RJ> then it can set the same bit in the DAO and send it back ... Thus RJ> working in both directions. It may not be required that capabilities RJ> be handshaked in both directions mandatorily. For e.g., root may RJ> indicate the capability that it has access to 6BBR and that unaware RJ> leaves could register through 6LRs. Thus 6LRs could proxy the NS RJ> (EARO) and other relevant messages. In this case, is it needed that RJ> 6LR reply back to the root saying it supports unaware leaves? There RJ> might be another example which requires 6LRs/6LNs to indicate in the RJ> reply that it supports the feature asked by root using the same cap RJ> bit in DAO. The DIO/DAO decides the direction but the bit can be the RJ> same. But, (3) is about an intermediate node announcing it can do something for i= ts children (and grandchildren).=20=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1lbRoACgkQgItw+93Q 3WUD7QgAie0qd+dSGtSlToqj71fRAPOlyX57HuIvqPEYOA/o2Jlb2UTrB//WVMux wOUCt/2dnJJkY3WdDquOaresqYOD92vFlyskuFsPkQx1eGtYqRGVK5n7aac2TafX V7zPM69fDWTnIyACvAjytKgmj9+0TkF7LziAydmhMXsRpr9VqJFy0yfLeqnQVm53 6IR4YJcfZ69bkQ4d+5bM2DJb5zJNo3zyTCyYi6tPJxAjyaY9CSt9Kxd0bdsgmaaZ B9ogxS1Db0fQdMaJmF8mC1bZ1GrlWN1tsBCk7ZoeEIYoO4O4hlXDaAzORoUn5q6b pMKAu7cQc9EPou9tIGyTheyqjYQTEA== =5Irf -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 27 17:00:50 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A1012080A for ; Tue, 27 Aug 2019 17:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PYitqmD3LPI for ; Tue, 27 Aug 2019 17:00:46 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10ABC120806 for ; Tue, 27 Aug 2019 17:00:46 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9117B6BF124C650A87D5 for ; Wed, 28 Aug 2019 01:00:43 +0100 (IST) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 28 Aug 2019 01:00:43 +0100 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 28 Aug 2019 01:00:43 +0100 Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 28 Aug 2019 01:00:42 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.145]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0439.000; Wed, 28 Aug 2019 05:30:34 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 - Extended Thread-Index: AQHVXKpM0xHBnIZ3IEOtTklGWQavG6cPp81g Date: Wed, 28 Aug 2019 00:00:33 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DFB977A@BLREML503-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DFB977ABLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 - Extended X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 00:00:48 -0000 --_000_982B626E107E334DBE601D979F31785C5DFB977ABLREML503MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEuDQoNCk1pbi1wcmlvcml0eSBpcyBhIHNjYWxhciB2YWx1ZSBmb3IgNkxScy9wcm94eSB0byBp bmRpY2F0ZSBpdHMga2Vlbm5lc3MgdG8gYWNjZXB0IG90aGVyIG5vZGVzIHRvIGpvaW4gdGhlIG5l dHdvcmsgdmlhIGl0LiBUaGVyZSBtaWdodCBiZSB1c2UtY2FzZXMgYmV5b25kIGpvaW4tcHJveHkg Zm9yIHVzaW5nIG1pbi1wcmlvcml0eS4NCg0KUmVnYXJkcywNClJhaHVsDQoNCkZyb206IFJvbGwg W21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJbmVzIFJvYmxlcw0K U2VudDogMjcgQXVndXN0IDIwMTkgMTU6MzcNClRvOiByb2xsIDxyb2xsQGlldGYub3JnPg0KU3Vi amVjdDogW1JvbGxdIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXJpY2hhcmRzb24tNnRpc2No LXJvbGwtZW5yb2xsbWVudC1wcmlvcml0eS0wMiAtIEV4dGVuZGVkDQoNCkRlYXIgYWxsLA0KDQpX ZSBleHRlbmQgdGhpcyBXRyBhZG9wdGlvbiBjYWxsIHVudGlsIDEwIFNlcHRlbWJlci4NCg0KSXQg d291bGQgYmUgbmljZSB0byBoYXZlIHlvdXIgb3BpbmlvbiBvbiB0aGlzLg0KDQpUaGFuayB5b3Ug dmVyeSBtdWNoIGluIGFkdmFuY2UsDQoNCkluZXMgYW5kIFBldGVyLg0KDQpPbiBUaHUsIEF1ZyA4 LCAyMDE5IGF0IDQ6MTkgUE0gSW5lcyBSb2JsZXMgPG1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWls LmNvbTxtYWlsdG86bWFyaWFpbmVzcm9ibGVzQGdvb2dsZW1haWwuY29tPj4gd3JvdGU6DQpEZWFy IGFsbCwNCg0KVGhpcyBpcyBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIHRoZSBkcmFmdCBkcmFm dC1yaWNoYXJkc29uLTZ0aXNjaC1yb2xsLWVucm9sbG1lbnQtcHJpb3JpdHktMDIuDQoNClRoZSBj YWxsIHN0YXJ0cyB0b2RheSAwOC0wOC0yMDE5IHVudGlsIDA4LTIyLTIwMTkuDQoNClBsZWFzZSBs ZXQgdXMga25vdyB5b3VyIG9waW5pb24gb24gdGhpcy4NCg0KVGhhbmsgeW91IGluIGFkdmFuY2Us DQoNCkluZXMgYW5kIFBldGVyLg0K --_000_982B626E107E334DBE601D979F31785C5DFB977ABLREML503MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+JiM0MzsxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+TWluLXByaW9yaXR5IGlzIGEgc2NhbGFyIHZhbHVlIGZvciA2 TFJzL3Byb3h5IHRvIGluZGljYXRlIGl0cyBrZWVubmVzcyB0byBhY2NlcHQgb3RoZXIgbm9kZXMg dG8gam9pbiB0aGUgbmV0d29yayB2aWEgaXQuIFRoZXJlIG1pZ2h0IGJlIHVzZS1jYXNlcyBiZXlv bmQgam9pbi1wcm94eQ0KIGZvciB1c2luZyBtaW4tcHJpb3JpdHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SYWh1 bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5JbmVzIFJvYmxlczxicj4NCjxiPlNlbnQ6PC9iPiAyNyBBdWd1c3QgMjAxOSAx NTozNzxicj4NCjxiPlRvOjwvYj4gcm9sbCAmbHQ7cm9sbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW1JvbGxdIFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXJpY2hhcmRzb24t NnRpc2NoLXJvbGwtZW5yb2xsbWVudC1wcmlvcml0eS0wMiAtIEV4dGVuZGVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgZXh0ZW5kIHRoaXMgV0cgYWRvcHRp b24gY2FsbCB1bnRpbCAxMCBTZXB0ZW1iZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSB5 b3VyIG9waW5pb24gb24gdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IHZlcnkgbXVjaCBpbiBhZHZhbmNlLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmVzIGFuZCBQ ZXRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVGh1LCBBdWcgOCwgMjAxOSBhdCA0OjE5IFBNIEluZXMgUm9ibGVzICZsdDs8YSBocmVm PSJtYWlsdG86bWFyaWFpbmVzcm9ibGVzQGdvb2dsZW1haWwuY29tIj5tYXJpYWluZXNyb2JsZXNA Z29vZ2xlbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgdGhlIGRy YWZ0Jm5ic3A7ZHJhZnQtcmljaGFyZHNvbi02dGlzY2gtcm9sbC1lbnJvbGxtZW50LXByaW9yaXR5 LTAyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgY2FsbCBzdGFydHMgdG9kYXkgMDgtMDgtMjAxOSB1bnRpbCAwOC0yMi0yMDE5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ug bGV0IHVzIGtub3cgeW91ciBvcGluaW9uIG9uIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBpbiBhZHZhbmNlLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmVzIGFu ZCBQZXRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_982B626E107E334DBE601D979F31785C5DFB977ABLREML503MBXchi_-- From nobody Wed Aug 28 00:10:11 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6641200C4 for ; Wed, 28 Aug 2019 00:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=j9Gt3LYU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=K+xCE9YM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7nUduWY5c2o for ; Wed, 28 Aug 2019 00:10:06 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7207C120145 for ; Wed, 28 Aug 2019 00:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13093; q=dns/txt; s=iport; t=1566976206; x=1568185806; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=oWwQslXn00F5pVQxFot37CaKMRiNN/HYidUjckCm9Ic=; b=j9Gt3LYU+wQDZR/fkM0bqa3s/1xW67+f5ZbFH2VyQ/J8xffOYia0GqFX hmz6y8//pe8YvHbSfm614ClP6ENAF9qpSYujI6kc9owFiXoqryRFxmRqr LlYw8jSs53htcf7WTku3lkA5PCV0FQYcKRVD787+kl69B/klb02hPq3Wf E=; IronPort-PHdr: =?us-ascii?q?9a23=3AtNYcERXmiAeh9wDuq5QyAfuI7xjV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANiJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dEwd4TgxRmBceEDUPhK/u/ay0oR+xJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2BQAtKGZd/5hdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBZ4EWLyknA21WIAQLKoQhg0cDinJNgg+TDYRcgUKBEANUCQEBAQwBAS0?= =?us-ascii?q?CAQGEPwIXgjIjOBMCCgEBBAEBAQIBBgRthS4MhUoBAQEEEgsGHQEBOA8CAQg?= =?us-ascii?q?RAwEBASgDAgICMBQJCAIEEyKDAAGBHU0DHQECn3wCgTiIYXOBMoJ7AQEFhRE?= =?us-ascii?q?NC4IWCYE0i3eCF4E4H4JMPoIagXIcPBaCVTKCJoEyAYtCgiyFE4kKjjkGAwK?= =?us-ascii?q?CHo4DhkkbgjKHMI51gzluoXECBAIEBQIOAQEFgWchgVhwegFzgU6CQjhvAQc?= =?us-ascii?q?IB4I0ilNygSmOBQEB?= X-IronPort-AV: E=Sophos;i="5.64,440,1559520000"; d="scan'208,217";a="320391142" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Aug 2019 07:10:05 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x7S7A2GK020571 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Aug 2019 07:10:04 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 02:10:02 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 03:10:01 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 28 Aug 2019 02:10:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QY1jzHzjOxTtBVPgFtb4IV5YweIq9N6eVJqUXYzCI7qhtIFdOUtrHbA5c2UloRoH2MGl9OZa+QEpsDVjq8PE49jRmtfBvmiE3P+gWZPUYp2PROi7XA6Q32hnTE3GEQiecb90Dh/YVm2az3sMin2wAbcG0fNQsuHLYaFkyrKTe+60o2HDR/u/b13w/5KfSppSdmFL1BKNKQz/sl/UZoZ4wZ+4TMh20f1LK79qVyhZuMBR/hl/gY5MAKAQAjRozSv5DZlpKDkMT3GND77P/uj5MZ0uoFbP1R2O6YgdCJ8XNfluYhTrBy2ym62jR67ANxCdALMUwFv5K41iR3QbqAIYgw== 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=oWwQslXn00F5pVQxFot37CaKMRiNN/HYidUjckCm9Ic=; b=hD5FwyR4q5GVgdY0rrPuuFcDFgY1oVzeM5s+QN/ffafEVCWbmBtcnES8HsAqG8qRwvDDnCVRocuy3TYZg1YiYUjUKL3zOa7CU9XNXTR9OWIHLNsjnc1POz7T7Vjq9fujBUIbvY/LUcF+MEqJyI/Sxt4F4nMS1q3Q7glmDuNeo1yuMuMbPmmhOeueLK7JwZ9VFdbnMZhde8rW/8uJDci9n9FrQ44Xt+6BdSVXkJksHMPTBfDk8j47yvopt1s3fNFWvoDxdb1767PyznacS/w9/k6a1jFo1E+ShLq/7aczHPWfcGcrWJGeG9ZPBA2vpCzz9iSuhW4TLLkT/qzldeGoBw== 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=oWwQslXn00F5pVQxFot37CaKMRiNN/HYidUjckCm9Ic=; b=K+xCE9YMzA2H4thGocPKP1GXtF+S2/HXnxoHnRlzL0LpEs8NLfxvnt+wUZfojQxKCHt53pTT73Zwgg9cIVwiR/KMGcAjrJs2M1dKnYGoX1VV1Tw5Y5DwbTeigv6gYGvPGOw3fgZp2uswLYWQpPvsEhxXplZvdMQPAk/lcn8d30c= Received: from MN2PR11MB3680.namprd11.prod.outlook.com (20.178.252.96) by MN2PR11MB3648.namprd11.prod.outlook.com (20.178.252.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Wed, 28 Aug 2019 07:10:00 +0000 Received: from MN2PR11MB3680.namprd11.prod.outlook.com ([fe80::d0cd:e041:d935:3ebd]) by MN2PR11MB3680.namprd11.prod.outlook.com ([fe80::d0cd:e041:d935:3ebd%7]) with mapi id 15.20.2199.021; Wed, 28 Aug 2019 07:10:00 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 - Extended Thread-Index: AQHVXKpRniGKBEW3iUWTaQBaKVY1SKcPreSAgAD+GIA= Date: Wed, 28 Aug 2019 07:09:59 +0000 Message-ID: References: <982B626E107E334DBE601D979F31785C5DFB977A@BLREML503-MBX.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DFB977A@BLREML503-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=liz3@cisco.com; x-originating-ip: [2001:420:588c:1252:8d62:883a:6e49:7b29] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d1ce9464-5b8d-4104-8a1a-08d72b86bd89 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3648; x-ms-traffictypediagnostic: MN2PR11MB3648: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 014304E855 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(396003)(346002)(39860400002)(136003)(504964003)(189003)(199004)(486006)(2616005)(476003)(229853002)(53546011)(446003)(6916009)(11346002)(6506007)(46003)(76176011)(99286004)(316002)(36756003)(8676002)(25786009)(236005)(6512007)(53936002)(6306002)(54896002)(81156014)(102836004)(8936002)(14454004)(81166006)(6486002)(6436002)(33656002)(6116002)(6246003)(86362001)(186003)(2906002)(7736002)(478600001)(256004)(76116006)(71200400001)(91956017)(66446008)(64756008)(5660300002)(71190400001)(66476007)(66946007)(66556008)(24704002)(88722002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3648; H:MN2PR11MB3680.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /nbjo02Q6BHKgWtB3jUe6xYaCBtiEtqX92BBIiFk91fCnCw16SF5l2uoHJ/0KSKb6BQEfNbvwREPB0OE45zoPMo8nsSm48F5EifKyUMn9/iLEiMdRKxOe/lYTzSNMQ0fHA6H1Jvf7BsO4wHVx4QHLSOjx5RdISHsJLbreTdKsED125abrjwVpBeBeG2cpfaMmaFyLdIJoPz4DNQFiXM/hrOmjkpBxxyHH1AYksiabzE6pIVZt1GOB2AfabjCoIlKugHiCrMcnQxGB4CZeOPfzgttpUdFB9kyFpnumxE7Kji35TlZw4wUIJeaU00T4rlqcYZxD3VbaoVs7RgqFLXTADLXOlZXLHdmqDnJfQe9ovJrlhuKAO4g2aAwRs/LYnVuEEhsaweZ08ZPUuzNtyTtNbEABpTypxthHrD2vGJXAr4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_A9C1BF88DA224CE59F137E5FA659ADCEciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d1ce9464-5b8d-4104-8a1a-08d72b86bd89 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2019 07:09:59.9965 (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: YJu7EhoevMuAyyFTTKuvgCFRmgc95Y19zSMkPX8g3w8BJR0kasb5I2kxzYvUBXhZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3648 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 - Extended X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 07:10:09 -0000 --_000_A9C1BF88DA224CE59F137E5FA659ADCEciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KSXTigJlzIHZlcnkgdXNlZnVsIGVzcGVjaWFsbHkgaW4gbGFyZ2Ugc2NhbGUgY2FzZS4g V2hlbiBmb3JtaW5nIGxhcmdlIHNjYWxlIG5ldHdvcmssIGRldmljZXMgYWx3YXlzIGpvaW4gdGhl IG5vZGUgd2l0aCBiZXN0IE9GLCBpdCBjYXVzZXMgdHJhZmZpYyBjb25nZXN0aW9uIGFuZCB0aGUg bmV0d29yayB0b3BvbG9neSBjaGFuZ2UgYWxsIHRoZSB0aW1lLg0KVGhlIGVucm9sbG1lbnQgcHJp b3JpdHkgY2FuIG1ha2UgdGhlIG5ldHdvcmsgcm9idXN0IGFuZCBzcGVlZCB1cCB0aGUgbmV0d29y ayBmb3JtaW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQpMaQ0KDQoNCkZyb206IFJvbGwgPHJvbGwtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJhaHVsIEFydmluZCBKYWRoYXYgPHJhaHVsLmph ZGhhdkBodWF3ZWkuY29tPg0KUmVwbHktVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExv c3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPg0KRGF0ZTogV2VkbmVzZGF5LCBBdWd1c3QgMjgs IDIwMTkgYXQgODowMSBBTQ0KVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5l dHdvcmtzIDxyb2xsQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtSb2xsXSBXRyBhZG9wdGlvbiBj YWxsIGZvciBkcmFmdC1yaWNoYXJkc29uLTZ0aXNjaC1yb2xsLWVucm9sbG1lbnQtcHJpb3JpdHkt MDIgLSBFeHRlbmRlZA0KDQorMS4NCg0KTWluLXByaW9yaXR5IGlzIGEgc2NhbGFyIHZhbHVlIGZv ciA2TFJzL3Byb3h5IHRvIGluZGljYXRlIGl0cyBrZWVubmVzcyB0byBhY2NlcHQgb3RoZXIgbm9k ZXMgdG8gam9pbiB0aGUgbmV0d29yayB2aWEgaXQuIFRoZXJlIG1pZ2h0IGJlIHVzZS1jYXNlcyBi ZXlvbmQgam9pbi1wcm94eSBmb3IgdXNpbmcgbWluLXByaW9yaXR5Lg0KDQpSZWdhcmRzLA0KUmFo dWwNCg0KRnJvbTogUm9sbCBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEluZXMgUm9ibGVzDQpTZW50OiAyNyBBdWd1c3QgMjAxOSAxNTozNw0KVG86IHJvbGwgPHJv bGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbUm9sbF0gV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQt cmljaGFyZHNvbi02dGlzY2gtcm9sbC1lbnJvbGxtZW50LXByaW9yaXR5LTAyIC0gRXh0ZW5kZWQN Cg0KRGVhciBhbGwsDQoNCldlIGV4dGVuZCB0aGlzIFdHIGFkb3B0aW9uIGNhbGwgdW50aWwgMTAg U2VwdGVtYmVyLg0KDQpJdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgeW91ciBvcGluaW9uIG9uIHRo aXMuDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggaW4gYWR2YW5jZSwNCg0KSW5lcyBhbmQgUGV0ZXIu DQoNCk9uIFRodSwgQXVnIDgsIDIwMTkgYXQgNDoxOSBQTSBJbmVzIFJvYmxlcyA8bWFyaWFpbmVz cm9ibGVzQGdvb2dsZW1haWwuY29tPG1haWx0bzptYXJpYWluZXNyb2JsZXNAZ29vZ2xlbWFpbC5j b20+PiB3cm90ZToNCkRlYXIgYWxsLA0KDQpUaGlzIGlzIGEgY2FsbCBmb3IgV0cgYWRvcHRpb24g b2YgdGhlIGRyYWZ0IGRyYWZ0LXJpY2hhcmRzb24tNnRpc2NoLXJvbGwtZW5yb2xsbWVudC1wcmlv cml0eS0wMi4NCg0KVGhlIGNhbGwgc3RhcnRzIHRvZGF5IDA4LTA4LTIwMTkgdW50aWwgMDgtMjIt MjAxOS4NCg0KUGxlYXNlIGxldCB1cyBrbm93IHlvdXIgb3BpbmlvbiBvbiB0aGlzLg0KDQpUaGFu ayB5b3UgaW4gYWR2YW5jZSwNCg0KSW5lcyBhbmQgUGV0ZXIuDQo= --_000_A9C1BF88DA224CE59F137E5FA659ADCEciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4F468856B4615F4FBE1F6D23695CF462@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+JiM0 MzsxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkl04oCZcyB2ZXJ5IHVzZWZ1bCBlc3BlY2lhbGx5IGluIGxhcmdl IHNjYWxlIGNhc2UuIFdoZW4gZm9ybWluZyBsYXJnZSBzY2FsZSBuZXR3b3JrLCBkZXZpY2VzIGFs d2F5cyBqb2luIHRoZSBub2RlIHdpdGggYmVzdCBPRiwgaXQgY2F1c2VzIHRyYWZmaWMgY29uZ2Vz dGlvbiBhbmQgdGhlIG5ldHdvcmsgdG9wb2xvZ3kNCiBjaGFuZ2UgYWxsIHRoZSB0aW1lLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ VGhlIGVucm9sbG1lbnQgcHJpb3JpdHkgY2FuIG1ha2UgdGhlIG5ldHdvcmsgcm9idXN0IGFuZCBz cGVlZCB1cCB0aGUgbmV0d29yayBmb3JtaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5MaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5Sb2xsICZsdDtyb2xsLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBSYWh1bCBB cnZpbmQgSmFkaGF2ICZsdDtyYWh1bC5qYWRoYXZAaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5SZXBs eS1UbzogPC9iPlJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzICZsdDty b2xsQGlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEF1Z3VzdCAyOCwg MjAxOSBhdCA4OjAxIEFNPGJyPg0KPGI+VG86IDwvYj5Sb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFu ZCBMb3NzeSBuZXR3b3JrcyAmbHQ7cm9sbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UmU6IFtSb2xsXSBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1yaWNoYXJkc29uLTZ0aXNj aC1yb2xsLWVucm9sbG1lbnQtcHJpb3JpdHktMDIgLSBFeHRlbmRlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mIzQzOzEu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NaW4tcHJpb3JpdHkg aXMgYSBzY2FsYXIgdmFsdWUgZm9yIDZMUnMvcHJveHkgdG8gaW5kaWNhdGUgaXRzIGtlZW5uZXNz IHRvIGFjY2VwdCBvdGhlciBub2RlcyB0byBqb2luIHRoZSBuZXR3b3JrIHZpYSBpdC4gVGhlcmUg bWlnaHQgYmUgdXNlLWNhc2VzIGJleW9uZCBqb2luLXByb3h5DQogZm9yIHVzaW5nIG1pbi1wcmlv cml0eS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlJhaHVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvbGwgW21haWx0bzpyb2xsLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkluZXMgUm9ibGVzPGJyPg0KPGI+U2Vu dDo8L2I+IDI3IEF1Z3VzdCAyMDE5IDE1OjM3PGJyPg0KPGI+VG86PC9iPiByb2xsICZsdDtyb2xs QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbUm9sbF0gV0cgYWRvcHRpb24gY2Fs bCBmb3IgZHJhZnQtcmljaGFyZHNvbi02dGlzY2gtcm9sbC1lbnJvbGxtZW50LXByaW9yaXR5LTAy IC0gRXh0ZW5kZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RGVhciBhbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZSBleHRlbmQgdGhpcyBXRyBhZG9wdGlvbiBjYWxsIHVudGlsIDEwIFNlcHRlbWJlci4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQg d291bGQgYmUgbmljZSB0byBoYXZlIHlvdXIgb3BpbmlvbiBvbiB0aGlzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgdmVyeSBt dWNoIGluIGFkdmFuY2UsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkluZXMgYW5kIFBldGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyA4LCAyMDE5IGF0IDQ6MTkgUE0g SW5lcyBSb2JsZXMgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJpYWluZXNyb2JsZXNAZ29vZ2xlbWFp bC5jb20iPm1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYSBjYWxsIGZv ciBXRyBhZG9wdGlvbiBvZiB0aGUgZHJhZnQmbmJzcDtkcmFmdC1yaWNoYXJkc29uLTZ0aXNjaC1y b2xsLWVucm9sbG1lbnQtcHJpb3JpdHktMDIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjYWxsIHN0YXJ0cyB0b2RheSAwOC0wOC0yMDE5 IHVudGlsIDA4LTIyLTIwMTkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBsZXQgdXMga25vdyB5b3VyIG9waW5pb24gb24gdGhpcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh bmsgeW91IGluIGFkdmFuY2UsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkluZXMgYW5kIFBldGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_A9C1BF88DA224CE59F137E5FA659ADCEciscocom_-- From nobody Wed Aug 28 08:23:43 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F35120059 for ; Wed, 28 Aug 2019 08:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=LLI0qcnX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vqhP6pAB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T17-qirAaYOS for ; Wed, 28 Aug 2019 08:23:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6207B12000F for ; Wed, 28 Aug 2019 08:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3429; q=dns/txt; s=iport; t=1567005819; x=1568215419; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9CiaWLrj21ghxmv5L6CrjmB5GlZELqn70r0ZSGyiLZY=; b=LLI0qcnXSy+TjttGqP2CVF5SK9QWfuoQFRGYPefRmiNJ0R/onenPIQCg gN7P5Qeoy2NkcDJZHNnwDiGaq9qwaMvTB27oo4wqFab0IR1YtiH/DQglq 3EyzTwbuaC11qhtmOcbnIiapsBymy+ASwLjcFv0wt7SahVJWJZ3I8KrT0 0=; IronPort-PHdr: =?us-ascii?q?9a23=3ANhuiiRRhOVvijdWA95SluqETLdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTCQAenGZd/5BdJa1lHQEBBQEHBQG?= =?us-ascii?q?BZ4FFUAOBQyAECyqHaAOKbk2CD5dqglIDVAkBAQEMAQEtAgEBgUuCdAKCUCM?= =?us-ascii?q?4EwIDCAEBBAEBAQIBBgRthS4MhUoBAQQBEigGAQE4BA0BCDZCJgEEEwgahGs?= =?us-ascii?q?DDg8BAqEkAoE4iGGCJYJ8AQEFhQ4YghYJgTSEf4Z4GIFAP4ERRoJMPoQeKIM?= =?us-ascii?q?7giasAQkCgh6Ua4Iyi02KWqYdAgQCBAUCDgEBBYFnIYFYcBU7gmyCQgwXg0+?= =?us-ascii?q?KU3KBKYs6glEBAQ?= X-IronPort-AV: E=Sophos;i="5.64,441,1559520000"; d="scan'208";a="622221735" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Aug 2019 15:23:38 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x7SFNcog015897 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Aug 2019 15:23:38 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 10:23:37 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 28 Aug 2019 10:23:36 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 28 Aug 2019 10:23:36 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZhKIsX77urA/S9flH8PGZOd9i4Vga8GVX5nM30TGTjartf1aLq29YtuT0aUkEJYbyMNnyO+y2s04Td8CezPpGizBE8M4YB8s0RsbkuO1wbprRYLqo/Eyb/NNEwKKvF39tf1J9almpUGWm7zQdL8oI/D3nDsVzMmEzIMV8qwXFCu4eZnC5P5RmOB7o6X3onV5GI63n3cPb7oETgNfxtABJYTLsY2mqX5in+fZxRjCRReiEgR4u5t664Fpsj1zOWOGznxzTXQ3fYjN6G/gkovNVIKbiFJZ7eHlhhbsu/SxGUdiBiU0XIINe9pW8e0EFbJzBc1bfDofiYvkpJ8qRFIyNw== 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=XGaJn+8S7f1iOgt4vW3WmIoP0j4Y/Zoghmv6DrJrmKo=; b=juGGdcAVuwILI8v3PzWQ0qUQBC5lIZNJK18UeEap1AfnKCkXnyVs3ZoY7A3cxuE1tQUdy68oG0FsNcDjl3xk71RcrqK4ljZOwYVvVtMcefF4Gtc1VGKOP/SjjnrLdXIjYjvpcdVuJzvdxEYEKs/TcbFGLBQR+vWBHJ6aQJ6mUSpZ1eeEakOudXxR2Lx4wOQs0K3NKqxo42JWw15SdUkaf9yDz/2riqlN5PDHft3MHAqjvaH1x1Tg9SYfP0Lg2lJXhCWa+eRgKXk4s/TDU2apRc41CfqkqXjsa9Cl2IXAnRsxIklKhh45PRuKahoAvTSkTWvlDm5OlFbDnQvKK41LzQ== 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=XGaJn+8S7f1iOgt4vW3WmIoP0j4Y/Zoghmv6DrJrmKo=; b=vqhP6pABUS8xtmQvt5ge03zN+O1/T3e9dToTQV4GqAyhY8v5WhBABWtiLz22OrF9bWgViT4F+mb7BVe7kZNqJlGf9R6RguEasM0TjreKzA/Niw1WUewM2N4+iqdc46WPkVynULxzaJdKpOqUw4B12R9+4uAMn8xn5wTUxl47f7g= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4000.namprd11.prod.outlook.com (10.255.181.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Wed, 28 Aug 2019 15:23:35 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2199.021; Wed, 28 Aug 2019 15:23:35 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] UNaware leaves (3) Thread-Index: AdVdrJQ325t5EgpaR3OV/cTL4cmzdA== Date: Wed, 28 Aug 2019 15:23:28 +0000 Deferred-Delivery: Wed, 28 Aug 2019 14:27:30 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1003::10c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c1bb46b-4d95-4195-2ad1-08d72bcbb175 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4000; x-ms-traffictypediagnostic: MN2PR11MB4000: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 014304E855 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(136003)(346002)(396003)(52314003)(43544003)(199004)(51444003)(189003)(66574012)(25786009)(102836004)(46003)(6246003)(2906002)(66476007)(486006)(316002)(256004)(53936002)(74316002)(476003)(14454004)(229853002)(99286004)(305945005)(14444005)(6916009)(52536014)(186003)(66556008)(478600001)(71200400001)(55016002)(5660300002)(9686003)(6436002)(81166006)(81156014)(86362001)(8676002)(7736002)(71190400001)(7696005)(6666004)(66946007)(76116006)(6116002)(66446008)(64756008)(6506007)(33656002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4000; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: K32RL/LXbk5lMqwFSarXfBZEnvjuN/NUGrjefJ+ZqpQrM8G24H5urxQfed+KCHsLYYhsVk6KSosP28NJO+sBlMbzrwRGIM9Tg30AX7t3gp5bh+0Fc2mE8vadpIEM3QPcimRyBDgQz7FH10mWOAwRaXTqvfD+H/xC/LnEubs42+WsuXLDP5A2Rz6b5g3BVBcXhA4DfCiC7x3xcoqXyT+/i/ghUrrWPox3WNmNZV+Rv6F6UrIB/XGz8wiEtDgnXvjPt/3kha0I769yg6/WHjAQlMdJXi1Kxe+jSqrYyW+2Pdb0LzakLWZjCyyPeJcoJh9zfAoyvU2Jkh7idJS/nS3ax3ZCfz0ZDDmZHWlM0btlKs+7Y5JRjDv+wI3jsKiUrQ4vdUG8qgWxTwdyTUavCoTXFK2U+L4MmmjS7rccAXkvaRw= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8c1bb46b-4d95-4195-2ad1-08d72bcbb175 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2019 15:23:34.9727 (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: hbKZ5pnIT7tJZYTLTTOs7ZFiiEXlpDLEjMEt0xAf/dyuV1Q6Fo9Mc7pS7l7OQlMrnvzAbuAOrDsCdkZKc+6XgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4000 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Roll] UNaware leaves (3) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 15:23:42 -0000 Hello Michael: Continuing on your very helpful comments: >=20 > I suggest that all text like: > o Upon each consecutive registration, the 6LN MUST increase the TID > field. >=20 > read like: > o As described in RFCXXXX section FOOBAR, upon each consecutive > registration, the 6LN MUST increase the TID field. >=20 > because I think that the point is that there are no changes, right? > Except for the InstanceID. >=20 Done > Should this specification extend 6tisch-minimal (CoJP) to include a way t= o set > the InstanceID? Possible, you're welcome to propose text and chat with Minimal co authors o= n the 6TiSCH ML : ). Pls keep in mind that over a same L2 network a node may participate to more= than one instance, so a list would be needed. Also that minimal provisions= L2 and now it would be provisioning L3. There's a limit to what we want to provision with AAA vs. management. The c= ool thing with management is that it is common to several security mechanis= ms.=20 >=20 > o A 6LN acting as a RUL MUST set the 'R' flag in the EARO whereas a > 6LN acting as a RAN SHOULD NOT set the 'R' flag. >=20 > wouldn't a 6LN acting as a RAN be a 6LR Leaf, and therefore not a 6LN? > Maybe we need another term here. Anything connected to a 6LoWPAN network is a 6LN. A 6LN is a Node, that is = a host or a router. A 6LR is a 6LN with additional capabilities. We do not= have a term for a 6LoWPAN plain host (like a 6LH) but as far as RPL is con= cerned a RUL is good enough. >=20 > o the 6LN is not expected to be aware of RPL so it is not expected > to produce RPL artifacts in the data packets. >=20 > certainly, it shouldn't do IPIP or RH3. > It would be damn useful if it would put the RPI in. MMod/Added text " Even without support for RPL, a RUL may be aware of opaque values to be provided to the routing protocol. If the RUL has a knowledge of the RPL Instance the packet should be injected into, then it SHOULD set the Opaque field in the EARO to the RPLInstanceID, else it MUST leave the Opaque field to zero. In any fashion the 6LN MUST set the "I" field to zero to indicate that topological information to be passed to a routing process as specified in [RFC8505] section 5.1. A RUL is not expected to produce RPL artifacts in the data packets, but it MAY do so. for instance, if the RUL has a minimal awareness of the RPL Instance and can build an RPI. A RUL that places an RPI in a data packet MUST indicate the RPLInstanceID that corresponds to the RPL Instance the packet should be injected into. All the flags and the Rank field are set to zero as specified by section 11.2 of [RFC6550]. " >=20 > Not putting it in means the adjacent 6LR has to IPIP it, address it to th= e RPL > Root. > If we put it in, then in the storing case, no further IPIP is needed!! >=20 Agreed. But that means a change in the RUL s. RFC 8505. That's a MAY at bes= t. > In non-storing the root still has to add the RH3, if it's going back down= . > If it's window smash alarm, it is probably going to leave the LLN anyway,= so > no big deal. Agreed >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 More later : ) Committed so far in github. Take care; Pascal From nobody Thu Aug 29 06:24:31 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A684012007C for ; Thu, 29 Aug 2019 06:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJhIanDIdR3B for ; Thu, 29 Aug 2019 06:24:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FE2120071 for ; Thu, 29 Aug 2019 06:24:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6DC983808A for ; Thu, 29 Aug 2019 09:23:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EDD2AC52 for ; Thu, 29 Aug 2019 09:24:25 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <14058.1566592130@dooku.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] UNaware leaves X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 13:24:30 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: >> > This specification does not alter the operation of a 6LoWPAN ND- >> > compliant 6LN, which is expected to operate as follows: >> >> really... I thought that we were making it able to deal with RPL artifacts, as >> specified in section 6!!! > Which is as should already be. That's not even 6LoWPAN ND, that's IPv6 if you look at it. Well, I tried to push for 6man's host requirements bis (RFC8504) to include processing of IP(dst=me)IP(dst=me) to be included, but it was a hard push, and I didn't have the energy. So, we are making requirements which go beyond 8504. >> What is the specific signal that the 6LR can use to know that the host is an RAN >> rather than a RUL? > Yes we have text, maybe even repeated with terminology; e.g., > " > The 6LR advertises the > Registered Address in DAO messages, if and only if it is triggered by > an NS(EARO) that has the 'R' flag set, indicating that the 6LN is a > RUL. If the 'R' flag is not set, then the Registering Node is > expected to be a RAN that handles the reachability of the Registered > Address by itself. > " got it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1n0gkACgkQgItw+93Q 3WVjmwf/bj0JzmbumcV7TrGtgLRAZYzF4h4iQhn3D1VIk7YS8N4qgPd/UUTls6hV pNP1U1xKmDoPh/qdIL6CjeZdYOmlBCeMTzR14OQT0cYVEWJmxoNuzZJC0M1Konpk v0qqHfrWYuwJTv0rZvAF5q9nzy9Zo2xlPYoUcXcKw0bhfQgCIUmANCF1BcvTjANl lpvSRo13tTCd/m4syr389E0fDtlNQhjV1m88bhRw0kK/YAKtZ24/83ZkI5e3t3hY aLSrVXT0XVIpzq9+zXndvsylo46vC8+5GEQumt2GJm+4LIph12dHDI9fHuDB5Wv8 pRaC7kw2yMP9xpOtf6MyI9n7cicozQ== =QJJ0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 29 09:05:03 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBA1120941 for ; Thu, 29 Aug 2019 09:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=THQ3IQWA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0Kz6xNpA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inOMj1DXETSQ for ; Thu, 29 Aug 2019 09:04:59 -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 A8BDC12093E for ; Thu, 29 Aug 2019 09:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4351; q=dns/txt; s=iport; t=1567094699; x=1568304299; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=NEgqEKjOAVfRJy1epD6SgXFySS1hiAKlrdCJI5gj7uI=; b=THQ3IQWAuPlWz72Ny+LwFnq8CUOT12jhOGMA68zBU/ReCDhIO+oAHIA9 AoCT0QeJ7uZ+RmhIv5I1XHcWk04h42YSJlWlhzocAFp81Myj1/WP3cdRk XX1VOTzSlxpz0Hka+iZOp83c+F4E+xo4lHJbQ79VceiSTwnhJ+ejrq4qp k=; IronPort-PHdr: =?us-ascii?q?9a23=3AkgQtlxyly+nMYQvXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4BgAv92dd/4gNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBZ4FFUAOBQyAECyqHaAOKcU2CD36WbIJSA1QJAQEBDAEBLQIBAYQ/AoJ?= =?us-ascii?q?ZIzgTAgMIAQEEAQEBAgEGBG2FLgyFSgEBAgIBEigGAQE4BA0BCDZCJgEEGxq?= =?us-ascii?q?EawMODwECoCUCgTiIYYIlgnwBAQWFDBiCFgmBNIR/hngYgUA/gRABRoIXNT6?= =?us-ascii?q?ERoM7giaJE4M0n0UJAoIei3WEEIRpgjKHNI53jyWXAQIEAgQFAg4BAQWBZyG?= =?us-ascii?q?BWHAVgyeCQgwXg0+KU3KBKY5OAQE?= X-IronPort-AV: E=Sophos;i="5.64,443,1559520000"; d="scan'208";a="321101612" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 16:04:58 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x7TG4wUG015034 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 29 Aug 2019 16:04:58 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 11:04:58 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 11:04:57 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 29 Aug 2019 11:04:57 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G9NuPE1FRz8BpNr7NarsJCnaBL/TknSDT8MdiWVfnJgiJfjKXGr0DI8KkZqiCJpznEcGxpvSqtmFnbeQ2k0wzwzqkYXDQKpi47F5To02A7a+I8Oppt5J1eL3TfRQ29Wfz8jSwmYOSzZczeeAemwB/XgXgtZy11pZVdNd/Oyh01I6XWwbAg4BB3ZqRoO4xyi88WRjfjBl6723k1mtvkYaKCZFibvFW4LfjH5OabnDoUDsqSbRLOpUDN+EwpZYCSW2G6+OgggLhiHPdMJdHqEwEjlF04k36Mydt+UL8ImOiKtnwX7k0UcUBa7zCJcvMUonHOGYLuemDOg76DaBESdEKA== 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=RqWMrXGjoNg8MScWWdpjPRWyhRq1Bhl87L3d564UlE0=; b=APA/i96iA+2WpTO/54pzG60GI74QlUEuJGLDfybK19wrcjn/hCnOHycAMom+drt5G/ZDgODIwJTB3gJGGavF111ontBf9jvB4SSndeuWkwPPHLe0M3ORJtKXvj3amj2Bk3GAVTVEaqbFzEpAfmMp9Os3YYANvhMDtQg3UU0FnXAa2WM5YggzEpr+fDjekyC8TWNyr9P7UzKzdGaIG/gg2BLeHpdjAbGqX1QE6L2dmTslGNPaioWguQXUX9oTuXnJhWxlxpAMEY+pBKVoGZyzQH1NTeLF+6H41/+byk348I5P0acEAJo8GNyGCseUYduphu44qasi8YlHnDN2C0c7vg== 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=RqWMrXGjoNg8MScWWdpjPRWyhRq1Bhl87L3d564UlE0=; b=0Kz6xNpAh7pkLnsLFzdSGoti/XLz6bF/DnGot+PpnryOxAQNE0Y3IVqjAPgvGQWApwW9aC3x7IlLATxKHrFwFJkpYQ/BGYF6cZj9sb3g+ffJCV2qrHqprxQbGoqrK24Uy1qRF+B8gpH67JNrEAizGEhFvVT1yOBsr2xD1Qn8l5o= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3824.namprd11.prod.outlook.com (20.178.254.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.19; Thu, 29 Aug 2019 16:04:56 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 16:04:56 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] UNaware leaves (4) Thread-Index: AdVeg1GJv6rPM07XS06M3ZEA/Gpw3g== Date: Thu, 29 Aug 2019 16:04:51 +0000 Deferred-Delivery: Thu, 29 Aug 2019 16:04:39 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:8170:98a7:7988:d19d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3fbeabf9-d4e3-43f4-0bf3-08d72c9aa2ce x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3824; x-ms-traffictypediagnostic: MN2PR11MB3824: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(39860400002)(366004)(396003)(189003)(199004)(51444003)(46003)(6246003)(71200400001)(71190400001)(256004)(14444005)(9686003)(99286004)(25786009)(66574012)(102836004)(74316002)(305945005)(6116002)(6666004)(86362001)(66946007)(478600001)(53936002)(55016002)(6436002)(486006)(316002)(5660300002)(66446008)(8676002)(66476007)(7736002)(64756008)(76116006)(14454004)(476003)(81156014)(6506007)(6916009)(81166006)(7696005)(8936002)(186003)(2906002)(66556008)(52536014)(229853002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3824; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: S9kFFFPCJNrceYTAci+gkp5RZdpg+UlXY67uN2Tx7nj2kNhUBA8G7Du9N+9kMrFIjj3/PnHTkJvNWWHBcE8JPFmwrVxhMpxRrlNBCCGvqGMr0mpKhWlQdADwMSobrPOExSo5onhOOTUHKWgucOz40be0VV9n/xWb/N+Pn0yQwOSI/qf7trm9Z+Q04IFHuoTPQtS14Si11QOQul/Cqy6M63aPWkMtIlvCHkTRKQCu0Yv/yET/IlAV/uR7f9asX22R+7AgN/GW5HoB1b8ajB6trRZr1dD8+iOKgUI4ZT0mpB/hTcUD65I1xH+bSxKJR9XXq4e6c2e3aRB2s75X2g0F6IXFQ0HplFjaHJqvDcEo+x5I1tywkebBf04zY7IXiVET6LVmRAEi3VsodQniyTXWQRuyjFZtpKeNxELR4bjfnM4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3fbeabf9-d4e3-43f4-0bf3-08d72c9aa2ce X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 16:04:56.3313 (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: gbJkvEbSKTQhhEPnWvrgKFNPxolM5MWo5mG7wPXu02gtyXsYzRUvfoU8qX560YMriUKUBuAhjFUA1VMrbJGkKw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3824 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Roll] UNaware leaves (4) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:05:02 -0000 Hello Michael The rest below: >=20 > I want to get rid of the IPIP headers not because they take space, but be= cause > the represent code paths not frequently taken. In particular, the hop-by-= hop > IPIP header just pisses me off. Yes; By definition a RPL aware leaf applies useofrplinfo and a RUL does not know= RPL. We're on a fine line.=20 I've added text that I wish you e =20 > > From then on, the 6LN periodically sends a new NS(EARO) to refresh > > the NCE state before the lifetime indicated in the EARO expires, with > > TID that is incremented each time till it wraps in a lollipop > > fashion. As long as the 'R' flag is set and this router can still >=20 > lollipop fashion probably needs a reference. What does TID start with? > (what's the stick of the lollipop? I guess this is in 8505, but reviewer= s > probably won't know this unless we tell them) Added references to section 5.2.1 of RFC 8505. >=20 > I think that "is left to zero" is a bit awkward. > I think that "is zero" is better? > I think that the Opaque field isn't zero, but is empty? OK =20 > > o the External 'E' flag in the Transit Information Option (TIO) > > associated to the Target Option is set to indicate that the 6LR > > redistributes an external target into the RPL network. This is > > how the Root knows in Non-Storing Mode to use IP-in-IP and > > terminate the outters headers at the 6LR that generated the DAO. >=20 > There are a lot of other circumstances in which the root has to use an IP= IP. I > think that it would be better to say: >=20 > } o the External 'E' flag in the Transit Information Option (TIO) > } associated to the Target Option is set to indicate that the 6LR > } redistributes an external target into the RPL network. When > } the Root has to use an IP-in-IP [useofrplinfo], then this flag > } indicates the IP-in-IP should be addressed to this node. >=20 Picked.=20 *Important Note:* that for a basic RUL the tunnel must terminate at the pa= rent, which must be known to do the encaps. Only non storing signaling allo= ws that. S I propose that for external routes, we use non-storing signaling= even in a storing mode DODAG. Proposed text RPL data packets are often encapsulated using IP-in-IP and in Non-Storin= g Mode, packets going down will carry an SRH as well. RPL data packets also typi= cally carry a Hop-by-Hop Header to transport a RPL Packet Information (RPI) . These additional headers are called RPL arti= facts. When IP-in-IP is used and the outer headers terminate at a 6LR down the = path, then the 6LR decapsulates the IP-in-IP and the packet that is forwarded = to the external destination is free of RPL artifacts. IP-in-IP to the 6LR MUST be used if the final destination cannot handle = or ignore the RPL artifacts or the way they are compressed . An External route indicates by default a nod= e or a prefix that is not known to handle or ignore the RPL artifacts. The RECOMMENDED behaviour when using IP-in-IP to an External route is th= at the outter headers terminate at the 6LR that injected the External route= . Non-Storing Mode signaling MUST be used to inject External routes to the Root in order to advertise the 6LR that is associated to a RUL. > I think that traffic from the Root to the RAN will not need an IP-IP, > just the RH3/RPI, which the RAN will skip. Traffic from elsewhere > will have an IPIP in for that Root to add the RH3/RPI. But, since the RA= N will > skip IPIP, the Root could address traffic. >=20 > Are there projected DAO interactions where the Root arranges for traffic = to > go laterally across the DODAG that might need some consideration here? I do not see that, need more thoughts >=20 > ASIDE: should this document effectively Update UseofRPLINFO? Not sure, please reviews the new text above on using non storing signaling = etc.. > Security Considerations will probably need another page. Yes. Michael: the ball is yours now. Can you please proofread and if we agree I'= ll publish and raise attention on the changes we just discussed here. Many thanks=20 Pascal From nobody Thu Aug 29 09:10:33 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD9012097B for ; Thu, 29 Aug 2019 09:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=bTbtpYcx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OtYlRFwT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUFRjVk3JAOJ for ; Thu, 29 Aug 2019 09:10:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB73120979 for ; Thu, 29 Aug 2019 09:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4233; q=dns/txt; s=iport; t=1567095030; x=1568304630; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=eWDpKn+tYYh6oJqd3ieG2hZ27zmipOQbuhneVaHOT7Q=; b=bTbtpYcxjTcwYLpYbi0k0K64OtCeGfRwu2Ne9ZRd0tQLbLe3sEjMcvyN A2VYX5pP/Ihi/AuJEZ39k8Tt+XALvZlaKpNd0EslLV7ZMfJVY6lNWnV+x DsdJHChLufqzJHrMEC7UDdgDeUcW/aWWp50OP1M7QYigPqQcW3JyqIJdg c=; IronPort-PHdr: =?us-ascii?q?9a23=3A7Rh1fhD/W9nRuB1PKZ2ZUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRBwBk+Gdd/4MNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBZ4FFUAOBQyAECyqHaAOKcU2CD5dqglIDVAkBAQEMAQEtAgEBgUuBdAF?= =?us-ascii?q?/AoJZIzgTAgMIAQEEAQEBAgEGBG2FLgyFSgEBFy4BATgLBgEZBAEBAWAdCQE?= =?us-ascii?q?EEwgahGsDHQECoCcCgTiIYYIlgnwBAQWFDBiCFgmBNIt3GIFAP4ERRoIehRQ?= =?us-ascii?q?egzuCJoxHiHqWSwkCgh6LdYh5mF2mJgIEAgQFAg4BAQWBZyGBWHAVgyeCQoN?= =?us-ascii?q?yilNygSmOTgEB?= X-IronPort-AV: E=Sophos;i="5.64,444,1559520000"; d="scan'208";a="535611432" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 16:10:29 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x7TGATS0025831 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 29 Aug 2019 16:10:29 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 11:10:28 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 12:10:27 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 29 Aug 2019 11:10:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FKBmHzNJ2ti66+9DHYM75XvcaYuBbdQT5wGALp3WsQsrMfDuds5kGCzrus5PlF6mQFSL6yfGfXHr5iEqPU5di6NRB5bE5pxorSlAVqG+cfXs5syOrtNlDgca9AXNl2Y/yQ6TvkSdf07H7DSaDCJVPCcIZL9xWUAQIdD5wU2nD1A28PEqcUqxZReqEfzt03Ktvi81GYu7NhFQJ/01ry5+Jw5F54RrTaPnopngT391sl1E3CTo6gxdGGJabUX1kRXiZdZ2PnwPuMkZGp5K4uT1AygcUkOYINuEK5vKT3jLHBQzF1dS1srsbXA3e7Jt6t66TCRU+HScbTc0Q0EnRseoLg== 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=Vfl6rWPaXBnYySG87Yu4ogX+ltzqT9H1cSeKqf6oXoU=; b=AXDDw7uXLa3Pr2teIEb61MVP5TpHSng37kOK3dWB2RSGCgkvuE0Pd6zo1O6a0bk72CkvCA1fBaTxl9wYPul/TtQ/a/AQMR5i/LdLPa15R4hYwOkadK1gUhV7+SEWrjxRx58IcxhI29OxCxLxrl6U7lU4rbw1oUi1TIquTp/C4cP774uhYrAsBVCUL+7usoXXCsqEgSbQS0yZjpvfoRdBKymJj1M2gLny6xH3Qi0KPIRGxroXZu/ZRF9d64vprEL1tOBiO8m3OEhottPFgOtk6RaRAbZHmFyICpKmTrRERqPx5cpkF9ZL+zxTeCcIGulRuZWlMvbxvm0JFArHsQV/Cw== 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=Vfl6rWPaXBnYySG87Yu4ogX+ltzqT9H1cSeKqf6oXoU=; b=OtYlRFwTToalwiYmmseDmaru+qoPjgaQ1RzocvYL9xacmHjGTyD5SVyA21BO/iqKn+NVskknodin5Tz9GH7aJ6yW9XtPVhd5UswtryXKIPINY3oHYFN1jxvyxFGnLhXQLvUi4IboyEKt6Gkr69m2LpzvHw07ZG5Rzt1cXhi9Ktw= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3824.namprd11.prod.outlook.com (20.178.254.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.19; Thu, 29 Aug 2019 16:10:26 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 16:10:26 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Terminating IP in IP at the 6LR Thread-Index: AdVehAsg/WVZd5TGTJ+FXlMdHYDzxg== Date: Thu, 29 Aug 2019 16:10:00 +0000 Deferred-Delivery: Thu, 29 Aug 2019 16:09:52 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:8170:98a7:7988:d19d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1efc3927-7d1f-4cbf-a2e8-08d72c9b678b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3824; x-ms-traffictypediagnostic: MN2PR11MB3824: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(39860400002)(366004)(396003)(13464003)(189003)(199004)(46003)(71200400001)(71190400001)(256004)(14444005)(9686003)(99286004)(25786009)(66574012)(102836004)(74316002)(305945005)(6116002)(6666004)(86362001)(66946007)(478600001)(53936002)(55016002)(6436002)(486006)(316002)(5660300002)(66446008)(8676002)(66476007)(7736002)(64756008)(76116006)(14454004)(476003)(81156014)(6506007)(6916009)(81166006)(53546011)(7696005)(8936002)(186003)(2906002)(66556008)(52536014)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3824; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6TdNHQbKrBnzAgKh7rjzN2kdn61zTBgLplrzWtHhZoFl11m7mamYWTmTQfW1rqX80Zj3FqFcOEvF0zsyAEN9wzFsNOavvt/5oNWD84ehpBXf+rDG1eG1yI8D1rOr6QyQ8Mukv/Eyk6j5fpVrdtNEgEnn1Tiu+eG79XgKAYwz2tlCwkAvuSUvuRQ5/9LybB+LkD5dXa0XyrtQ7/bUeLxw/LW+hzdFe03Rxa0EtiIcbVWDfKitU2ZGd0tCDa+oJGtSTslA9KnvMJcw5cfLjfeISh/4XFjHVY3yOUW67Bso7ndUI0IinDSGITYnL0OFrqY2C1GKRT3/TXI6lWhnxbgL6E/lboiDQQVDNwOiExpJi96S6SQO5FDPCz0RY01Jkzof+LSlHsglKE/XQk62JZugx2bNdaz6W334PQy/mTHaT/Y= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1efc3927-7d1f-4cbf-a2e8-08d72c9b678b X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 16:10:26.3312 (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: hNp3ZUzPaT5ZLBD0FETVUltgSovtNme3mgnNUvITVYmhmItRWT+d/Mcs0n/0oHGI6hU9zCESWRf7Qk/gwrjz5w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3824 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: [Roll] Terminating IP in IP at the 6LR X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:10:32 -0000 Makes sense Michael: we cannot expect that by default the RUL is able to terminate IP in IP. So= unless configured otherwise we must terminate at the 6LR. Which is only kn= own in non storing. So we need non storing signaling for 'E' routes. OK... about updating usefrplinfo, unsure. If you think so you have the pen. I 'dd= like to publish this early next week if that's OK for you. I added text: " 6.2.3. Support of IPv6 Encapsulation A RUL may support IPv6-in-IPv6 decapsulation when it is the destination of the outer header but that is not assumed by [RFC8504]. If the 6LN is a RUL, it may be able to drop the inner packet if it is not the destination of the inner header. By default the IP-in-IP tunnel should terminate at the parent 6LR so supporting this capability in a RUL is secondary. " Which seeds in the new text below: " 6.2. External Routes and RPL Artifacts RPL data packets are often encapsulated using IP-in-IP and in Non- Storing Mode, packets going down will carry an SRH as well. RPL data packets also typically carry a Hop-by-Hop Header to transport a RPL Packet Information (RPI) [RFC6550]. These additional headers are called RPL artifacts. When IP-in-IP is used and the outer headers terminate at a 6LR down the path (see Figure 7 for the format in Storing Mode), then the 6LR decapsulates the IP-in-IP and the packet that is forwarded to the external destination is free of RPL artifacts. IP-in-IP to the 6LR MUST be used if the final destination cannot handle or ignore the RPL artifacts or the way they are compressed [RFC8138]. An External route indicates by default a node or a prefix that is not known to handle or ignore the RPL artifacts. The RECOMMENDED behaviour when using IP-in-IP to an External route is that the outer headers terminate at the 6LR that injected the External route. Non-Storing Mode signaling MUST be used to inject External routes to the Root in order to advertise the 6LR that is associated to a RUL. In order to save the IP-in-IP encapsulation and to support Storing Mode of operation, it is preferred that the 6LN can ignore an RPI and consume a routing header in both the native and [RFC8138]-compressed forms. In order to enable IP-in-IP to a 6LN in Non-Storing Mode, it is also of interest that the 6LN supports decapsulating IP-in-IP in both forms. " All the best, Pascal > -----Original Message----- > From: Roll On Behalf Of Michael Richardson > Sent: jeudi 29 ao=FBt 2019 15:24 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] UNaware leaves >=20 >=20 > Pascal Thubert (pthubert) wrote: > >> > This specification does not alter the operation of a 6LoWPAN N= D- > >> > compliant 6LN, which is expected to operate as follows: > >> > >> really... I thought that we were making it able to deal with RPL a= rtifacts, > as > >> specified in section 6!!! >=20 > > Which is as should already be. That's not even 6LoWPAN ND, that's I= Pv6 > if you look at it. >=20 > Well, I tried to push for 6man's host requirements bis (RFC8504) to inclu= de > processing of IP(dst=3Dme)IP(dst=3Dme) to be included, but it was a hard = push, > and I didn't have the energy. >=20 > So, we are making requirements which go beyond 8504. >=20 > >> What is the specific signal that the 6LR can use to know that the = host is > an RAN > >> rather than a RUL? >=20 > > Yes we have text, maybe even repeated with terminology; e.g., >=20 > > " > > The 6LR advertises the > > Registered Address in DAO messages, if and only if it is triggered = by > > an NS(EARO) that has the 'R' flag set, indicating that the 6LN is a > > RUL. If the 'R' flag is not set, then the Registering Node is > > expected to be a RAN that handles the reachability of the Registere= d > > Address by itself. > > " >=20 > got it. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- From nobody Thu Aug 29 16:57:17 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A827A1200D6 for ; Thu, 29 Aug 2019 16:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh2iVBBXDuve for ; Thu, 29 Aug 2019 16:57:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F34D120059 for ; Thu, 29 Aug 2019 16:57:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3EBE33808A for ; Thu, 29 Aug 2019 19:56:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 707EDD8C for ; Thu, 29 Aug 2019 19:57:11 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] UNaware leaves (3) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 23:57:16 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: >> Should this specification extend 6tisch-minimal (CoJP) to include a way to set >> the InstanceID? > Possible, you're welcome to propose text and chat with Minimal co > authors on the 6TiSCH ML : ). Actually, we created a "Constrained Join Protocol Parameters Registry" parameters. This document can allocate a value from it :-) > Pls keep in mind that over a same L2 network a node may participate to > more than one instance, so a list would be needed. Also that minimal > provisions L2 and now it would be provisioning L3. > There's a limit to what we want to provision with AAA > vs. management. The cool thing with management is that it is common to > several security mechanisms. I don't think we need a list on CoJP. A RAL that participated in multiple L2 networks would probably need to do multiple joins to get the network keys for each, and it would have to have enough RAM/Flash/etc. to keep track of the different keys, and also instanceID. >> o A 6LN acting as a RUL MUST set the 'R' flag in the EARO whereas a >> 6LN acting as a RAN SHOULD NOT set the 'R' flag. >> >> wouldn't a 6LN acting as a RAN be a 6LR Leaf, and therefore not a 6LN? >> Maybe we need another term here. > Anything connected to a 6LoWPAN network is a 6LN. A 6LN is a Node, that > is a host or a router. A 6LR is a 6LN with additional capabilities. We > do not have a term for a 6LoWPAN plain host (like a 6LH) but as far as > RPL is concerned a RUL is good enough. I think that a 6LoWPAN plain host (I like 6LH), is a RPL-unware-leaf (RUL) We have just created the RPL-Aware-Leaf (RAL), and we'd like it to become the status quo, right? Oh, I think I'm confused on terms. I'll have to come back and read it again. >> Not putting it in means the adjacent 6LR has to IPIP it, address it to the RPL >> Root. >> If we put it in, then in the storing case, no further IPIP is needed!! >> > Agreed. But that means a change in the RUL s. RFC 8505. That's a MAY at best. I think that it's the killer-app part of this work. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1oZlcACgkQgItw+93Q 3WVJVwf8CDZV22tTx5i4/DPml9qbZ4ogALKEvmbIugb3nGRkzLeERpZneDJFIoj8 2Zw23TT2CAj7fBLvkNt26qeZlLV/D/bjzjc8h6Le9EeEofzpUCZF74Vxf/unRCpS CrGuK52Xvb2TM6N7P754SlJ9ZLvuIOd7qGA154U/DXhzQzONZgDslfPCSsjCXxEw Ala3g6ygr/+hE7+O29W158aoWwpV1gfMce6MdyvlHqnR7AjvrW4HAEEYsUgpucrh K8Zf8XDLgWrcAif+jTYfRpXrdofjxfPVcC0uyYU3eave2uRBK8bHpAyD7mRQTtlH bhNy2od61OXTJXosvJU9cSCw28zqjg== =u3Fp -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 29 22:50:20 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C109412013B for ; Thu, 29 Aug 2019 22:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ElG9krEY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GPR06VRO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1ez3JZvZgbH for ; Thu, 29 Aug 2019 22:50:16 -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 895F212011F for ; Thu, 29 Aug 2019 22:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2949; q=dns/txt; s=iport; t=1567144216; x=1568353816; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DWeAFZOSrYlhoUrUZjA8bycRY4gX7UPhx28jnCxiNC4=; b=ElG9krEYadcdZhX7fnWPOaLFYJ9CALYxJ6q86fKQyr/d+c1zqRcmlsuE XucY6w5HcJBq2hCIBxnmus/P07HQ5Wx39dewCVqKQ+SIWFahxdpEI1kOq SnhvKltI73LdEUqZoEnz1tzZVpm6g62rFuY4dYZ1osI4qQlI+OFabTKPm A=; IronPort-PHdr: =?us-ascii?q?9a23=3AdntDbxEbxmsjomxHBFt39p1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAQDpuGhd/5xdJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVgQBAQsBgURQA4FDIAQLKodoA4pyTYIPl2uCUgNUCQEBAQwBAS0CAQG?= =?us-ascii?q?EPwKCWSM3Bg4CAwgBAQQBAQECAQYEbYUuDIVKAQEBAwESKAYBATgPAgEINhA?= =?us-ascii?q?yJQEBBBsahGsDDg8BAqE9AoE4iGGCJYJ8AQEFhRAYghYJgTQBhH6GeBiBQD+?= =?us-ascii?q?BEUaCTD6EHiiDO4ImrA0JAoIflHGCMoc0hByKXaYqAgQCBAUCDgEBBYFmIoF?= =?us-ascii?q?YcBU7gmyCQgwXg0+KU3KBKYs2glMBAQ?= X-IronPort-AV: E=Sophos;i="5.64,445,1559520000"; d="scan'208";a="321484618" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2019 05:49:58 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x7U5nwAY021364 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 30 Aug 2019 05:49:58 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 00:49:57 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 00:49:57 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 30 Aug 2019 01:49:57 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VoXzQkZkxmnepsGoRal97o8c/Q69Xict0BFmfatCyMKrdI5JOG/P0/H6rD1Xxs+3tV3vp4BYu5iTekWoTQ8+YOcydE8g4mIWgoXGjjV0J6tC6+jaAAujP+OuYdmjn14fsOcwnhuLj+qm6vyvpS6rfDgCT+5AAvZk6PInBeelc5dRIuwADRFTjvKxrmI+WOR2ODhgXAM0LTAw6Dy7bW24bUABGTkk/FgDr6t9yTSSe8Jne0DQQsIK69nuoCpnHSAlUpwBXELuEF1pT9UtOrMo77I77gjPEDaMcOo6bjLu2YTEMbxvfqPBzGmUhT6ALU5AiMOrJnW6alqYjNq7quhSow== 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=2Q5YAEC2tIeTFJf+Cj2KtoxiodJc7x0d/14GV9mxmYg=; b=T/6zugYkWzJR+kO8tJ4XNPkabEk7rPq/XOjDcuTtu4ByOFnwqzBcU9OiJZAL++Gc9CWgTDRORizyvS6h2fhIRhsGdTmLq2ZsCnXKr/1nPaepP9DoWmGm+w1TAPp4fEwg0rGEMbNpOwcDeqAU7hUVZpiEjHpC0XTUg3vlZnlG0Uf2GLVknXb/sUzOAfP6HMSQCq2LHo22GCdT5mWzS3+UeOSLhjzZCnOxWhuBBNATASPh70Rdl8HM4ckgFF6XxoLLYwXzRhTErQc0ipyJFv819DjNB7zd1O6dGW7OqOV0uFnTPbrLu+3+ZtDP+7Y/D8KLUSi0Fol0+U6ZqP/+8rldnA== 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=2Q5YAEC2tIeTFJf+Cj2KtoxiodJc7x0d/14GV9mxmYg=; b=GPR06VROf8PmxHvLN5F2yuyB4soMvOPfzDfplJ2tNANep/B9nPEg0imXlsOS58KXjPBErFilFEeGqXXlMDEIsEbIisT5VoKh1GsW7lY6AO0KAH4XruD9ZAwHff/gDyvvBcdS10doxY7Mju8Iiq5H2coViNIqzl6oPOrhot4zzBg= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4319.namprd11.prod.outlook.com (52.135.39.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Fri, 30 Aug 2019 05:49:56 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.013; Fri, 30 Aug 2019 05:49:56 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] UNaware leaves (3) Thread-Index: AdVdrJQ325t5EgpaR3OV/cTL4cmzdABGOTaAAAvdJSA= Date: Fri, 30 Aug 2019 05:49:28 +0000 Deferred-Delivery: Fri, 30 Aug 2019 05:48:30 +0000 Message-ID: References: <23546.1567123031@localhost> In-Reply-To: <23546.1567123031@localhost> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1003::52] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 09bb3801-4c69-49f4-17c2-08d72d0de31b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4319; x-ms-traffictypediagnostic: MN2PR11MB4319: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(396003)(346002)(366004)(189003)(199004)(51444003)(66446008)(66476007)(66556008)(64756008)(66946007)(71200400001)(7696005)(476003)(486006)(6436002)(71190400001)(76116006)(76176011)(14444005)(256004)(6666004)(74316002)(6916009)(99286004)(229853002)(2906002)(14454004)(6506007)(186003)(33656002)(52536014)(86362001)(6246003)(6116002)(25786009)(102836004)(305945005)(7736002)(5660300002)(316002)(478600001)(8676002)(81156014)(8936002)(81166006)(66574012)(46003)(9686003)(55016002)(11346002)(446003)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4319; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /ijLKsKhVvmJwNHycXY1okHAtiquwTbEuILvIq1zqdPNRxMotDhPC4dTCs+6Pq/cqoCgdSc3JjaRbAq8ckM7Jw1AH1tLK7zhh90S6bUB2xNIFyI5JDB1mkb1z9bA91JcarBs15zdRkDGOipduh9KSMTnqbpVUJGYUrCO+SR5ysr3rPRUYLeX7Akb0F2aYl/bgGhzLYMbe2CVYmyI7GcSX7xLFZpwm4TaIy5YjardQz9LeQ+6M9f3Tfxp1Xn92uWrpg4kA3pV/qSEff618CjZjNQEKP9NrIInHmhdrUANHMSxi9OK+Gg4W2yvEJZPa2I069RhRj8PRt8aoDH81CFmpa/XRmMmRt8LK5QTLa85tfY+c10t7znsUcxGdDzHje6FrJcbtveHD9e3jxPz5jkQwnYiuxnbL4l0AwMI+9XZ8eI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 09bb3801-4c69-49f4-17c2-08d72d0de31b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 05:49:56.3503 (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: DrsL89N5MGchZHSGXxWxV0BRegXk8MdFVH+XicHK0k/YI2B8oA5P9SDz44pvzj7Ouy8skAhYHYdiPo/Mprm5AA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4319 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Roll] UNaware leaves (3) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 05:50:19 -0000 Hello Michael > > Possible, you're welcome to propose text and chat with Minimal co > > authors on the 6TiSCH ML : ). >=20 > Actually, we created a "Constrained Join Protocol Parameters Registry" > parameters. This document can allocate a value from it :-) Works for me. So we imagine a RUL that does 6TiSCH minus RPL correct? Shoul= dn't that be a 6TiSCH-aware RUL draft? Like a RFC 8504 but for a 6TiSCH nod= e? >=20 > > Pls keep in mind that over a same L2 network a node may participate= to > > more than one instance, so a list would be needed. Also that minima= l > > provisions L2 and now it would be provisioning L3. >=20 > > There's a limit to what we want to provision with AAA > > vs. management. The cool thing with management is that it is common= to > > several security mechanisms. >=20 > I don't think we need a list on CoJP. > A RAL that participated in multiple L2 networks would probably need to do > multiple joins to get the network keys for each, and it would have to hav= e > enough RAM/Flash/etc. to keep track of the different keys, and also > instanceID. But we could have multiple instances in one network. Would you want to use = one key per instance? Maybe, yes. >=20 > >> o A 6LN acting as a RUL MUST set the 'R' flag in the EARO whereas= a > >> 6LN acting as a RAN SHOULD NOT set the 'R' flag. > >> > >> wouldn't a 6LN acting as a RAN be a 6LR Leaf, and therefore not a = 6LN? > >> Maybe we need another term here. >=20 > > Anything connected to a 6LoWPAN network is a 6LN. A 6LN is a Node, = that > > is a host or a router. A 6LR is a 6LN with additional capabilities= . We > > do not have a term for a 6LoWPAN plain host (like a 6LH) but as far= as > > RPL is concerned a RUL is good enough. >=20 > I think that a 6LoWPAN plain host (I like 6LH), is a RPL-unware-leaf (RUL= ) We > have just created the RPL-Aware-Leaf (RAL), and we'd like it to become th= e > status quo, right? >=20 > Oh, I think I'm confused on terms. I'll have to come back and read it ag= ain.>=20 The term 6LH was not defined, maybe that's sad. If it did it could mean for= some people RFC 6775.=20 A RUL MUST support RFC 8505 so we get the TID and the R flag. It also means= a certain setting of the I and opaque fields. So it is a subset of what "6= LH" would mean. > >> Not putting it in means the adjacent 6LR has to IPIP it, address i= t to the > RPL > >> Root. > >> If we put it in, then in the storing case, no further IPIP is need= ed!! > >> >=20 > > Agreed. But that means a change in the RUL s. RFC 8505. That's a MA= Y at > best. >=20 > I think that it's the killer-app part of this work. Yes I hope people who implement RULs support that. That's part of IPv6 supp= ort. Can you please review the way I worded it all? All the best; Pascal From nobody Thu Aug 29 23:43:03 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868B21202A0 for ; Thu, 29 Aug 2019 23:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=VJxH0Mja; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=s2NogUDq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE63JcgHkuOT for ; Thu, 29 Aug 2019 23:42:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB60120289 for ; Thu, 29 Aug 2019 23:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11206; q=dns/txt; s=iport; t=1567147379; x=1568356979; h=from:to:subject:date:message-id:mime-version; bh=Qwd51ZSjEnGRAHcs1siNdQ79dlKxrI9QGWMZSMgf5l4=; b=VJxH0Mjaapq6bsEOwnPLL2ySbLXiUt4mFhStyaGLC/f2sP2CMPKHh0gL JcVw+nxnLYJi4RUGP53oIMxWRXVjtCGXoSOXQcjksxQ3QAEmoUrhszxNH fk2pSIjyJtwN9+sED5HrcreR8N8ClV407vyaVK0S20EITWZf9FhwmdjxF E=; IronPort-PHdr: =?us-ascii?q?9a23=3A79iBbxxVbKagEvXXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOAADPxGhd/49dJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgRUvJCwDbVYgBAsqh2gDhFKGIE2SGYMCA4RcgS4UgRADVAk?= =?us-ascii?q?BAQEMAQEtAgEBhD8CglojNAkOAgMIAQEEAQEBAgEGBG2FLgyFYxsTAQE4EQG?= =?us-ascii?q?BACYBBBsagwGBHU0DHQECoTQCgTiIYYIlgnwBAQWFERiCFgmBNAGLdhiBQD+?= =?us-ascii?q?BEUaHFjqDO4ImlECXTQkCgh+OC4ZmgjKWLY8nlwMCBAIEBQIOAQEFgVA4gVh?= =?us-ascii?q?wFYMngkKDcopTcoEpjgkBAQ?= X-IronPort-AV: E=Sophos;i="5.64,446,1559520000"; d="scan'208,217";a="617753504" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2019 06:42:58 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x7U6gwfX015523 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 30 Aug 2019 06:42:58 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 01:42:57 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 01:42:57 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 30 Aug 2019 01:42:57 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AbuKxXHgoxHML1vFApR4fNDPFNChrGICswvFBL9o7RMWL6smHqaFOXuB7BKiKFzgUHro6/Mt5CwwHTb1u/m0VwiaMV+a0ZEtfTwwlRWRcJ18ro2lJ3IlNAwSKhRRrHqxtoho5PqxGANFLdaxKPB+Ke8CAkS1jeoJNUatP8cg4n3bWePfGA1pMerOQyLWkCYgeQNKW55KvMpp6ool3/mY2ToxgdRMllXdhBgazX+wnP9j/kDvw2FZdc1tFh4TF8VhW3PFs/2dN0UU2dyTyAwHUJ8ozJEVwm6djA8Cad39CqzvEGaqW6d/83Fw0tv/YzEnR6DqugWC2BrFAAwWIBkTvw== 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=CU6C+Z67bpGXLQurGtvd9P40ywF1eBCSn9TCElxWqvM=; b=HcCBEftDmE9PdszWFV1XQu4OLn38PD1vh+y4M4bZMGZdz3MrIufC0pdLhV4JdvTG88EVQ5hxYKuchv9JODyqPmIN97rW0O41tRMB+9B5xQoeXgdSTjdCk8rnCEp3ScM/fF8/NpkCLIGripR52OE9UE0q16bdao8v/V0u5IaOwWxu3Zs+we5pad+gPE6KNkRvYbn/MSsn7uBr8v7nmpU6iIvX5PRU3PO44Ej5kJsbaoGS3fpuwikPPwzPaS1HWCHJQm3ytR9N4DzOsGTqC5KxWUhmeU7B7WKmUKXseAMunopo1HAiWqgKXLMPyRQZNzzzz87JWkIkTfPxp8LH4Bk01A== 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=CU6C+Z67bpGXLQurGtvd9P40ywF1eBCSn9TCElxWqvM=; b=s2NogUDqPCM5kx/i41J8I9OYC2YQWEXXNAcRfTO7sjyX+GNfa/MS3fmhiSx/RD2XsUlbPP+4/Jehe3OArnoXkAECORmMsbHuIvHWfSWVNyqBei2TsZtSpB0VMW8RtL2Z1AA9TaJYac0CjRBVuo9VtIKxTzV5VXfd10BlcUpZS1c= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4352.namprd11.prod.outlook.com (52.135.38.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Fri, 30 Aug 2019 06:42:56 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.013; Fri, 30 Aug 2019 06:42:56 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: suggested addition to draft-ietf-roll-efficient-npdao Thread-Index: AdVe/YcA7dtmnImrSGKYwVT3ZLHQqA== Date: Fri, 30 Aug 2019 06:42:50 +0000 Deferred-Delivery: Fri, 30 Aug 2019 06:41:50 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1003::52] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a290574-b7bc-402d-f8c0-08d72d154a90 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4352; x-ms-traffictypediagnostic: MN2PR11MB4352: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(376002)(346002)(39860400002)(199004)(189003)(256004)(52536014)(14444005)(81166006)(81156014)(8676002)(486006)(476003)(66946007)(2906002)(74316002)(6116002)(53936002)(790700001)(7736002)(6666004)(64756008)(66556008)(66476007)(14454004)(66446008)(8936002)(76116006)(6916009)(5660300002)(316002)(71200400001)(33656002)(71190400001)(86362001)(478600001)(55016002)(54896002)(6306002)(9686003)(4744005)(46003)(6436002)(7696005)(186003)(102836004)(25786009)(99286004)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4352; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vl29ifShPxJRdWSJeIk/UBt5M5FY/sbwutohLIgMj1yyl7qloTaADCzMjlVZ56GscGRpvgtH5lqg3UhLNlJGIpG6pjcJ8zY/XJ5q2UPpyIiuwXQ6w1qKltppSXTxUo0aXdPrVqnR9WhrdFVewcvka3MZHMXDQqwPt/ZP1nnbUMlrpiv996wQCb1bbvrlaN6otdoPVOWZbEqVfcHhXQ1kgCkfAail9s0T30OcfqgdUwKgasknvwG7PpXjZBRvZEKCkabm8BnTEvTgniNZvCTzPoSqTyDR1clZE9tPPgVa/sV/KrOx10bRgcaMvZAMB3T/APi8t+MYWMiRRESwmZzdODVkDhuwGHxOiYhgsLo9xNrUP1V7jAc/pPR/5MWv41gxH7efV740hmRFVRknwXdIYBIB4o/HNRLY29F74UCHFv0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565C4909E1E1327A640D6BDD8BD0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3a290574-b7bc-402d-f8c0-08d72d154a90 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 06:42:56.3563 (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: jF2v/Fjt99W8ONKUBb0jhNM4sriLX0zu9l3BehFll0RiZVe+dc+/cX/nacyDxkDiXD90+H7iY2m2ARV4jTjlrw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4352 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 06:43:02 -0000 --_000_MN2PR11MB3565C4909E1E1327A640D6BDD8BD0MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all ; I know it's late but I'd suggest an addition to draft-ietf-roll-efficient-n= pdao. There's a reserved field in the DCO. My suggestion is to use it to transport RPL DAO-ACK status values as define= d in RFC 6550. This way we can signal the reason of the DCO to the node. This will become significant with the RPL-unaware leaves draft, so we can r= ebuild a NA(EARO) with a non-zero status based on a DCO. Else the RUL draft will have to update efficient NP DAO, which does not loo= k as good. Any objection to this? Pascal 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |K|D| Flags | Reserved | DCOSequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID(optional) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ --_000_MN2PR11MB3565C4909E1E1327A640D6BDD8BD0MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all ;<= /p>

 

I know it’s late but I’d suggest an addi= tion to draft-ietf-roll-efficient-npdao. There’s a reserved field in = the DCO.

My suggestion is to use it to transport RPL DAO-ACK = status values as defined in RFC 6550. This way we can signal the reason of = the DCO to the node.

This will become significant with the RPL-unaware le= aves draft, so we can rebuild a NA(EARO) with a non-zero status based on a = DCO.

 

Else the RUL draft will have to update efficient NP = DAO, which does not look as good.

 

Any objection to this?

 

Pascal

 

   0       &n= bsp;           1 &nb= sp;            =      2        &= nbsp;          3

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

     | RPLInstanceID |K|D|  = Flags   |   Reserv= ed    | DCOSequence   |

     +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

     |     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |

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

     |     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |

     +    &nbs= p;            &= nbsp;          DODAGID(optiona= l)            &= nbsp;     +

     |     &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;      |

     +    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        +

     |     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |

     +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

     |   Option(s)...

     +-+-+-+-+-= 3;-+-+-+

 

--_000_MN2PR11MB3565C4909E1E1327A640D6BDD8BD0MN2PR11MB3565namp_-- From nobody Fri Aug 30 00:04:11 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90095120170 for ; Fri, 30 Aug 2019 00:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzrF_ZcdzlgV for ; Fri, 30 Aug 2019 00:04:06 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B001120113 for ; Fri, 30 Aug 2019 00:04:06 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D2CECA55929A0B8C7B28 for ; Fri, 30 Aug 2019 08:04:03 +0100 (IST) Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 30 Aug 2019 08:04:03 +0100 Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 30 Aug 2019 08:04:03 +0100 Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 30 Aug 2019 08:04:03 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.145]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0439.000; Fri, 30 Aug 2019 12:33:55 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: suggested addition to draft-ietf-roll-efficient-npdao Thread-Index: AdVe/YcA7dtmnImrSGKYwVT3ZLHQqAAAaBpQ Date: Fri, 30 Aug 2019 07:03:54 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DFBB52ABLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 07:04:09 -0000 --_000_982B626E107E334DBE601D979F31785C5DFBB52ABLREML503MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The DCO could be initiated for regular route invalidation due to path chang= es or because of management decision. The status code can help understand t= he reason for initiating the DCO. I like the idea of this. However, I don't know, procedurally, what it means to changing the draft at= this stage. The changes to draft would include new IANA considerations for the status f= ield. From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthu= bert) Sent: 30 August 2019 14:43 To: Routing Over Low power and Lossy networks Subject: [Roll] suggested addition to draft-ietf-roll-efficient-npdao Dear all ; I know it's late but I'd suggest an addition to draft-ietf-roll-efficient-n= pdao. There's a reserved field in the DCO. My suggestion is to use it to transport RPL DAO-ACK status values as define= d in RFC 6550. This way we can signal the reason of the DCO to the node. This will become significant with the RPL-unaware leaves draft, so we can r= ebuild a NA(EARO) with a non-zero status based on a DCO. Else the RUL draft will have to update efficient NP DAO, which does not loo= k as good. Any objection to this? Pascal 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |K|D| Flags | Reserved | DCOSequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID(optional) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ --_000_982B626E107E334DBE601D979F31785C5DFBB52ABLREML503MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The DCO could be initi= ated for regular route invalidation due to path changes or because of manag= ement decision. The status code can help understand the reason for initiati= ng the DCO. I like the idea of this.

 

However, I don’t= know, procedurally, what it means to changing the draft at this stage.

 

The changes to draft w= ould include new IANA considerations for the status field.

 

From: Roll [mailto:roll-bounces@ietf.org] = On Behalf Of Pascal Thubert (pthubert)
Sent: 30 August 2019 14:43
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] suggested addition to draft-ietf-roll-efficient-npda= o

 

Dear all ;<= /p>

 

I know it’s late but I’d suggest an addi= tion to draft-ietf-roll-efficient-npdao. There’s a reserved field in = the DCO.

My suggestion is to use it to transport RPL DAO-ACK = status values as defined in RFC 6550. This way we can signal the reason of = the DCO to the node.

This will become significant with the RPL-unaware le= aves draft, so we can rebuild a NA(EARO) with a non-zero status based on a = DCO.

 

Else the RUL draft will have to update efficient NP = DAO, which does not look as good.

 

Any objection to this?

 

Pascal

 

   0       &n= bsp;           1 &nb= sp;            =      2        &= nbsp;          3

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

     | RPLInstanceID |K|D|  = Flags   |   Reserv= ed    | DCOSequence   |

     +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

     |     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |

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

     |     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |

     +    &nbs= p;            &= nbsp;          DODAGID(optiona= l)            &= nbsp;     +

     |     &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;      |

     +    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        +

     |     &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       |

     +-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+

     |   Option(s)...

     +-+-+-+-+-= 3;-+-+-+

 

--_000_982B626E107E334DBE601D979F31785C5DFBB52ABLREML503MBXchi_-- From nobody Fri Aug 30 00:29:55 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0312018B for ; Fri, 30 Aug 2019 00:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjjCZAoQ8CPl for ; Fri, 30 Aug 2019 00:29:50 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B9F120130 for ; Fri, 30 Aug 2019 00:29:49 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id BB78F180397DB; Fri, 30 Aug 2019 07:29:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=xwXI3vxqNISQS4z1QM O22sa/eMg86HR2NM0Z19qRXnY=; b=en504Fnw0ja+bkhvosQEcaUFTpEalQbHA4 DwkQGiS/USiqFwPd5L4nhdz8m/Rwb9zDE2qpUUhm7JtLySWY3RzQs7kq0LyCY6s0 EEqC0vXtUnMCt+EQAh+RXSe3qsqi9sCsL6kH1ZjHHpojfDAO8uZQefkYcVN/iAsc YTcn6o/H0= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:1:2:41:72:152:355:379:582:599:800:960:962:967:969:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1730:1776:1792:1801:2068:2069:2198:2199:2525:2526:2527:2528:2553:2559:2564:2682:2685:2692:2693:2859:2895:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3586:3622:3865:3866:3867:3868:3870:3871:3872:3873:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4052:4250:4321:4379:4605:4860:5007:6117:6119:6261:6657:6678:7576:7809:7875:7903:8583:8603:8957:9010:9025:9080:9121:9149:9177:9545:10004:10026:10848:10946:11232:11233:11658:11914:12043:12109:12114:12291:12379:12438:12683:12740:12895:13138:13139:13158:13228:13231:13439:13846:14095:14096:21060:21080:21433:21451:21627:21740:21772:21939:30012:30046:30054:30060:30070:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0. X-HE-Tag: farm20_1b69c33666d3b X-Filterd-Recvd-Size: 13922 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf18.hostedemail.com (Postfix) with ESMTPA; Fri, 30 Aug 2019 07:29:48 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_dc30a83a1e7bca1b8e27bdb967ecb3d7" Date: Fri, 30 Aug 2019 09:29:47 +0200 From: Peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com> Message-ID: <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [5.206.216.229] Archived-At: Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 07:29:53 -0000 --=_dc30a83a1e7bca1b8e27bdb967ecb3d7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Authors, It is a bit late to change the approved draft. It is in IANA editing; and you could write to IANA to apologize for a late addition and see how far they are in the process. BUT, worse, how much text is needed to explain this addition? Adding text to an approved document sounds like opening a can of worms to me. Peter Rahul Arvind Jadhav schreef op 2019-08-30 09:03: > The DCO could be initiated for regular route invalidation due to path changes or because of management decision. The status code can help understand the reason for initiating the DCO. I like the idea of this. > > However, I don't know, procedurally, what it means to changing the draft at this stage. > > The changes to draft would include new IANA considerations for the status field. > > FROM: Roll [mailto:roll-bounces@ietf.org] ON BEHALF OF Pascal Thubert (pthubert) > SENT: 30 August 2019 14:43 > TO: Routing Over Low power and Lossy networks > SUBJECT: [Roll] suggested addition to draft-ietf-roll-efficient-npdao > > Dear all ; > > I know it's late but I'd suggest an addition to draft-ietf-roll-efficient-npdao. There's a reserved field in the DCO. > > My suggestion is to use it to transport RPL DAO-ACK status values as defined in RFC 6550. This way we can signal the reason of the DCO to the node. > > This will become significant with the RPL-unaware leaves draft, so we can rebuild a NA(EARO) with a non-zero status based on a DCO. > > Else the RUL draft will have to update efficient NP DAO, which does not look as good. > > Any objection to this? > > Pascal > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RPLInstanceID |K|D| Flags | Reserved | DCOSequence | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + + > > | | > > + DODAGID(optional) + > > | | > > + + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Option(s)... > > +-+-+-+-+-+-+-+-+ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=_dc30a83a1e7bca1b8e27bdb967ecb3d7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Authors,

It is a bit late to change the approved draft.
= It is in IANA editing; and you could write to IANA to apologize for a late = addition and see how far they are in the process.
BUT, worse,  ho= w much text is needed to explain this addition?

Adding text to a= n approved document sounds like opening a can of worms to me.

Pe= ter

Rahul Arvind Jadhav schreef op 2019-08-30 09:03:

The DCO could be ini= tiated for regular route invalidation due to path changes or because of man= agement decision. The status code can help understand the reason for initia= ting the DCO. I like the idea of this.

&n= bsp;

However, I don&rsquo= ;t know, procedurally, what it means to changing the draft at this stage.

&n= bsp;

The changes to draft= would include new IANA considerations for the status field.

&n= bsp;

From: Roll [mailto:roll-bounces@iet= f.org] On Behalf Of Pascal Thubert (pthubert)
Sent: 30 August 2019 14:43
To: Routing Ov= er Low power and Lossy networks <roll@ietf.org>
Subject= : [Roll] suggested addition to draft-ietf-roll-efficient-npdao

 

Dear all ;

 

I know it’s late but I’d suggest an addi= tion to draft-ietf-roll-efficient-npdao. There’s a reserved field in = the DCO.

My suggestion is to use it to transport RPL DAO-ACK = status values as defined in RFC 6550. This way we can signal the reason of = the DCO to the node.

This will become significant with the RPL-unaware le= aves draft, so we can rebuild a NA(EARO) with a non-zero status based on a = DCO.

 

Else the RUL draft will have to update efficient NP = DAO, which does not look as good.

 

Any objection to this?

 

Pascal

 

   0        &n= bsp;          1  &nb= sp;            =     2         &= nbsp;         3

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+

     | RPLInstanceID |K|D|   Flags=    |&n= bsp;  Reserved    | DCOSequence   |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+

     |      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |

     +       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     +

     |      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |

     +      &n= bsp;            = ;         DODAGID(optional) &n= bsp;            = ;    +

     |      &n= bsp;            = ;            &n= bsp;            = ;             &= nbsp;     |

     +      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      +

     |      &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;      |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+

     |   Option(s)...

     +-+-+-+-+-+-+-+-+

 


= _______________________________________________
Roll mailing list
Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
--=_dc30a83a1e7bca1b8e27bdb967ecb3d7-- From nobody Fri Aug 30 00:56:25 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDD6120C55 for ; Fri, 30 Aug 2019 00:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXburmdyzxAJ for ; Fri, 30 Aug 2019 00:56:21 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 187B9120C2C for ; Fri, 30 Aug 2019 00:56:21 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id g207so2287134wmg.5 for ; Fri, 30 Aug 2019 00:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=z3g6Z3QW/ChFQfE5oFgH5api5GEkO1g7u6IhXFMiWX4=; b=cMdzhm4DCAxpD3BEY87AyNIsePJWwqDfui7k40I3yHM/KA1iokpn4UOLpIcLQ2Ga0K PsO+opVKEhjGYd/hFbaWAG71Mt9b6Lzvbi3MYuRMiJLQxQKm8Wo4P9vYqOD7uvnofk98 mf0mGO3/1w7vOOIs0egMNkyCuvcGWEOOzSOVj22R40MVD9BOTeqKoRPsMNSXC5VKZblz YjAtTjGPSDAwLvoyl0tJj9MHLzebZBunsFyoFzS0B4WqY8xJ/pLynuEgKkJr679NPHMv sY7iYIGGTj3joR8qmaFtA3mC/XkNsVcu/d/YRrxe4P2dqFtSwdVRkkGTQUHF2qmT+9+a D2oA== 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; bh=z3g6Z3QW/ChFQfE5oFgH5api5GEkO1g7u6IhXFMiWX4=; b=gq/KwA6V+OZLqCInh4FxiW7Gy9psXlegKmB6j/rKyJrU0hk90UxHzoRt5Q2N3HAc5s hDYLgUKyN5kJC+SzbuDjvEAOpCV3uVhyOAeNMQVO/xH9FmtkLjhBfxAPMAFJt4kZtR7F cf8Zn0ox8QdGNjCg117RMfZ6exOu7j3NRrTnRqYsSu0CmgBwAuT5MrcMRfy5ejtXXNho RObIJC+qgmLjYIYQG6LdHiU44I0OTxQ8UEmozid011X7E5lbltfOqIXJOVeYjLIFyuSx 0ugigQGCnIeb+awx6Q7Xolm8drPGSRl/Rs7tgKJDsqQuyUVmzXq0j3WwNap81FmJW3C2 OdEw== X-Gm-Message-State: APjAAAUkN5/VxKzOKSCz2xL3BUjXQzY3vfC3JvIrTo3junRUHqF5a2j+ gDZKj7rpDkIqEKdRwFpLmIE0VhDoswB0NZgw+9rFKg== X-Google-Smtp-Source: APXvYqzLViroixdWvwgkSfdGzESvEg7IzthLvM4YIe1qBBZG41IUDlSijEuWZJ2u0IYJ8EtJCMH/onHurSgYRUV9+qI= X-Received: by 2002:a1c:b342:: with SMTP id c63mr16638741wmf.84.1567151779276; Fri, 30 Aug 2019 00:56:19 -0700 (PDT) MIME-Version: 1.0 References: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com> <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> In-Reply-To: <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> From: Ines Robles Date: Fri, 30 Aug 2019 10:56:08 +0300 Message-ID: To: peter van der Stok , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="0000000000001cee7a059150f5e9" Archived-At: Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 07:56:24 -0000 --0000000000001cee7a059150f5e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Please note that new IANA considerations and related new text to a WG approved document certainly needs WG approval again. Ines and Peter On Fri, Aug 30, 2019 at 10:30 AM Peter van der Stok wrote: > Hi Authors, > > It is a bit late to change the approved draft. > It is in IANA editing; and you could write to IANA to apologize for a lat= e > addition and see how far they are in the process. > BUT, worse, how much text is needed to explain this addition? > > Adding text to an approved document sounds like opening a can of worms to > me. > > Peter > > Rahul Arvind Jadhav schreef op 2019-08-30 09:03: > > The DCO could be initiated for regular route invalidation due to path > changes or because of management decision. The status code can help > understand the reason for initiating the DCO. I like the idea of this. > > > > However, I don=E2=80=99t know, procedurally, what it means to changing th= e draft > at this stage. > > > > The changes to draft would include new IANA considerations for the status > field. > > > > *From:* Roll [mailto:roll-bounces@ietf.org] *On Behalf Of *Pascal Thubert > (pthubert) > *Sent:* 30 August 2019 14:43 > *To:* Routing Over Low power and Lossy networks > *Subject:* [Roll] suggested addition to draft-ietf-roll-efficient-npdao > > > > Dear all ; > > > > I know it=E2=80=99s late but I=E2=80=99d suggest an addition to > draft-ietf-roll-efficient-npdao. There=E2=80=99s a reserved field in the = DCO. > > My suggestion is to use it to transport RPL DAO-ACK status values as > defined in RFC 6550. This way we can signal the reason of the DCO to the > node. > > This will become significant with the RPL-unaware leaves draft, so we can > rebuild a NA(EARO) with a non-zero status based on a DCO. > > > > Else the RUL draft will have to update efficient NP DAO, which does not > look as good. > > > > Any objection to this? > > > > Pascal > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | RPLInstanceID |K|D| Flags | Reserved | DCOSequence | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + + > > | | > > + DODAGID(optional) + > > | | > > + + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Option(s)... > > +-+-+-+-+-+-+-+-+ > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0000000000001cee7a059150f5e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Please note=C2=A0 that new IANA con= siderations and related new text=C2=A0 to a WG approved document certainly = needs WG approval again.

Ines and Peter=C2=A0
<= /div>

On Fri, Aug 30, 2019 at 10:30 AM Peter van der Stok <stokcons@bbhmail.nl> wrote:
Hi Authors,

It is a bit late to change the approved draft.
It is = in IANA editing; and you could write to IANA to apologize for a late additi= on and see how far they are in the process.
BUT, worse,=C2=A0 how much t= ext is needed to explain this addition?

Adding text to an approved d= ocument sounds like opening a can of worms to me.

Peter

Rahul Arvind Jadhav schreef op 2019-08-30 09:03:

=20

The DCO could b= e initiated for regular route invalidation due to path changes or because o= f management decision. The status code can help understand the reason for i= nitiating the DCO. I like the idea of this.

=C2=A0

However, I don= =E2=80=99t know, procedurally, what it means to changing the draft at this = stage.

=C2=A0

The changes to = draft would include new IANA considerations for the status field.

=C2=A0

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: 30 August 2019 14:43
To: Routing Over Low power and= Lossy networks <roll= @ietf.org>
Subject: [Roll] suggested addition t= o draft-ietf-roll-efficient-npdao

=C2=A0

Dear all=C2=A0;

=C2=A0

I know it=E2=80=99s late but I=E2=80=99d suggest an = addition to draft-ietf-roll-efficient-npdao. There=E2=80=99s a reserved fie= ld in the DCO.

My suggestion is to use it to transport RPL DAO-ACK = status values as defined in RFC 6550. This way we can signal the reason of = the DCO to the node.

This will become significant with the RPL-unaware le= aves draft, so we can rebuild a NA(EARO) with a non-zero status based on a = DCO.

=C2=A0

Else the RUL draft will have to update efficient NP = DAO, which does not look as good.

=C2=A0

Any objection to this?

=C2=A0

Pascal

=C2=A0

=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3

=C2=A0=C2=A0=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7= 8 9 0 1 2 3 4 5 6 7 8 9 0 1

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 | RPLInstanceID |K|D|=C2=A0=C2=A0 F= lags=C2=A0=C2=A0 |=C2=A0=C2=A0 Reserved=C2=A0=C2=A0=C2=A0 | DCOSequence=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DODAGID(optional)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|

=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Option(s)...

=C2=A0=C2=A0 =C2=A0=C2=A0+-+-+-+-+-+-+-+-+

=C2=A0


_______________________________________________<= br> Roll mailing list
Roll@ietf.org
https://www.iet= f.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--0000000000001cee7a059150f5e9-- From nobody Fri Aug 30 01:10:13 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5365D120CAF for ; Fri, 30 Aug 2019 01:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=X+r/PdJn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=znAV0aVU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAkr9SaIY-8t for ; Fri, 30 Aug 2019 01:09:58 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9094F12010C for ; Fri, 30 Aug 2019 01:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20441; q=dns/txt; s=iport; t=1567152598; x=1568362198; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=UGKnza4utLA03PKVmasaLQtjk/ulC3LMVeCIhRAi8cc=; b=X+r/PdJnTR5vGNdPbPTB99sJZKKZzXTsBCwKSd2dyV+Ik91sjxXV2cyq y5puDL0MEJDMNBSbOhDYtWK8R3dL8odQG9bpWcmhwKRQdmqmMAYfqw7MK M5HkJg07EoR63nnkhLzSrgprfNLAuqg4+6af9ys27pzidCxHsSPHos0rs 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AhxJxuBxnYQnYmvDXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAACk2Ghd/5FdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBFS8kLANtViAECyoKhBeDRwOKck2CD5MPhFy?= =?us-ascii?q?BQoEQA1QJAQEBDAEBGAEKCgIBAYQ/AheCRCM3Bg4CAwgBAQQBAQECAQYEbYU?= =?us-ascii?q?uDIVKAQEBBAEBEBEKEwEBLAYGDwIBCBEEAQEoAwICAiULFAkIAQEEEyKDAAG?= =?us-ascii?q?BHU0DHQECAQuhNgKBOIhhc4EygnwBAQWFDBiCFgMGgTQBi3YYgUA/gREnH4J?= =?us-ascii?q?MPoJhAQGBKQQYMxaCXjKCJo8mhRoklykJAoIfjguGSxuCMpYtjXGBNpcDAgQ?= =?us-ascii?q?CBAUCDgEBBYFmIoFYcBU7KgGCQYJCg3KFFIU/coEpjGYBgSIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,446,1559520000"; d="scan'208,217";a="322164204" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2019 08:09:57 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x7U89vbk004390 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Aug 2019 08:09:57 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 03:09:56 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 03:09:56 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 30 Aug 2019 03:09:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jUK18kLZrSUOgu71BQ5UUKyM9NGCk1NAp7gnHY2pmZ3+erXL/HdbnODfzoSxud69rxr5B369ttwIT+OvRueWaOWTcbbg5m7qTa8gIvwwSiQkcnq0wVKAhSOTCrYr9zH2Ybh7Fxakn5IsE0B4nTlP1/cdU4fwHdoz+3Gfxwj5eg3WlIuCN+SJUDIMMMN34L/+VzzNvhFMyBGHCnJhvhsWnmJp8gzJwKn0wzpeKdC+XrFFLZwb34oNBzMAj3rPQHEr6HtEb0avcqW/+4Y0cXUcsgL3gOBnfyGb28NUu3oDiyen5m0lwxjwEJgoIM3a0Z4giS8mltNsL1OF99TboDk+iA== 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=UGKnza4utLA03PKVmasaLQtjk/ulC3LMVeCIhRAi8cc=; b=nw+Hiefzl/jPGD7lkoarZW9KRXoNqAMFZjq6eCEJGIhIh99rHJnHD1pX+Szeos08/kYpYHWkCYKKXtuopJLcjx4rcsvV0g6oJZs1IQjZ93+pekgyl4CPz4CXr4u1TsOqZbx+0euQHcXNcYOWUgEdadc2PDh/vyX0qmn6nT2StdNo41EJsqtu2pqeswCRMcjDL21h5oHlDOl+2NTiNe0HthPDrK5EHBINcYS3PP0natGFYop5BfBzty6e+xwvtmwjgat7IR1UL3nLr85pfqm4TUxvsyukCIf2ICDf6fCyTxqm+INNUWS2Qh88Ec0+z4F6ubXuMe3fy3MF/WGi/SiwCQ== 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=UGKnza4utLA03PKVmasaLQtjk/ulC3LMVeCIhRAi8cc=; b=znAV0aVUuQrlNeOC1BgtfK6nbsiTFjkKe4JIakF3CfwVh8HhtQTmV2z0IASvuu3e/8LUA4O+4EDNKANPZSDBv5rtDEVl47vTqN+efzM/a4utbyw/nYz1JhYuSwGSxg0W67xjpE+o6c581dHLpg4YHWixvqhjqlnNRatr6qttzr8= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4223.namprd11.prod.outlook.com (52.135.37.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Fri, 30 Aug 2019 08:09:55 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.013; Fri, 30 Aug 2019 08:09:55 +0000 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] suggested addition to draft-ietf-roll-efficient-npdao Thread-Index: AdVe/YcA7dtmnImrSGKYwVT3ZLHQqAAAaBpQAAFi+YAAAWbH1A== Date: Fri, 30 Aug 2019 08:09:54 +0000 Message-ID: <9ED90E26-9AC9-4FB9-86FF-3FD838CB0E60@cisco.com> References: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com>, <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> In-Reply-To: <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [91.69.164.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bfde59fd-1f34-4a7d-2f55-08d72d217129 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4223; x-ms-traffictypediagnostic: MN2PR11MB4223: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39850400004)(366004)(346002)(376002)(396003)(199004)(189003)(6306002)(81156014)(33656002)(14454004)(236005)(76116006)(66574012)(8676002)(81166006)(36756003)(86362001)(7736002)(478600001)(316002)(54896002)(2906002)(6512007)(6486002)(99286004)(966005)(6436002)(6116002)(110136005)(3846002)(66066001)(11346002)(91956017)(476003)(53936002)(2616005)(25786009)(446003)(76176011)(26005)(6246003)(66556008)(14444005)(256004)(71200400001)(71190400001)(102836004)(486006)(8936002)(606006)(53546011)(66476007)(229853002)(66946007)(66446008)(2501003)(6506007)(5660300002)(64756008)(186003)(244885003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4223; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7rE4GMjEp7eK/bszZ7hmctX59wID5LMrAkN1frvhmU3BRzYvIaYUF5eYA3Y4krTwhKnH5pL0daBx/ucrLZOybygEEtMJ3TY0ytXRx2Npc2Wa9fIfYaRLdPJT58dlaSpXEnqx1rgihP3mX1BUhGzm2TuqOgogjc6B0uf72lmhvQCu39y9cYktH7PvSrV5wK5L13xQdqBYvKwylV22CrDymr+U6PXcVKz0+k0YZJIzUpO+/Q5xi7T6OoRVzeecI6tEAWidQFxvvYEZ6OqO/9pOYG5rUFEZ4VKSsvb9QIT+Q/zk9Lrp2ChzrXOfjh8KkhfGtBF5ubCfP8lYEm+wXKuYtpQnqOH/OPY/Oy6wURB/TCqJV5j2m8bocdLd8AXeCMrVEI0aDxJIsHeECmNWPpF2hFufiaiGNCT12r9icUurl9A= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_9ED90E269AC94FB986FF3FD838CB0E60ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bfde59fd-1f34-4a7d-2f55-08d72d217129 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 08:09:54.9021 (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: BZw8QA++ShUYP4bupfjFnyAzy8I/pZz0IxIRtzN5qDU+R/YaflhlqEYnzKEDilBlOLAl70PW0pUSJ6atKJCB5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4223 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 08:10:10 -0000 --_000_9ED90E269AC94FB986FF3FD838CB0E60ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHJlZ2lzdHJ5IGRvZXMgbm90IGV4aXN0IHNvIHVubGVzcyB3ZSBkZWNpZGUgdG8gY3JlYXRl IGl0IHRoZXJlIGlzIG5vIElBTkEgIGNoYW5nZS4gQ2FsbCBpdCBhbiBvbWlzc2lvbiBpbiBSRkMg NjU1MC4NCg0KRm9yIHRoYXQgcmVhc29uIEkgaGF2ZSBhbHJlYWR5IGFkZGVkIHRleHQgaW4gdGhl IG5leHQgUlVMIHRvIGNyZWF0ZSB0aGUgcmVnaXN0cnkgKGluIGdpdGh1YikuIExldOKAmXMga2Vl cCBpdCBpbiBSVUwgdG8gbWluaW1pemUgdGhlIGNoYW5nZXMgaW4gTlBEQU8uDQoNCk1pbmltYWwg Y2hhbmdlcyB0byBOUERBTyBpcyB0byBjaGFuZ2UgdGhlIG5hbWUg4oCccmVzZXJ2ZWTigJ0gb2Yg dGhlIGZpZWxkIGluIHRoZSBkcmF3aW5nIGFuZCBhZGQgdGV4dCBzYXlpbmcgc2FtZSBzdGF0dXMg ZmllbGQgYXMgaW4gUlBMIERBTyBBQ0suDQoNCklmIHdlIHJlYWxseSB3YW50IG5ldyBzdGF0dXMg dmFsdWVzIHdlIG1heSBhbHNvIGFkZCB0aGVtIGluIE5QREFPIGFuZCBJ4oCZbGwgYWRhcHQgUlVM LiBCdXQgdGhlcmUgaXMgbm8gYWJzb2x1dGUgbmVlZCB0byBjcmVhdGUgdGhlIHJlZ2lzdHJ5IGlu IE5QREFPLg0KDQpSZWdhcmRzLA0KDQpQYXNjYWwNCg0KTGUgMzAgYW/Du3QgMjAxOSDDoCAwOToz MCwgUGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0BiYmhtYWlsLm5sPG1haWx0bzpzdG9rY29u c0BiYmhtYWlsLm5sPj4gYSDDqWNyaXQgOg0KDQpIaSBBdXRob3JzLA0KDQpJdCBpcyBhIGJpdCBs YXRlIHRvIGNoYW5nZSB0aGUgYXBwcm92ZWQgZHJhZnQuDQpJdCBpcyBpbiBJQU5BIGVkaXRpbmc7 IGFuZCB5b3UgY291bGQgd3JpdGUgdG8gSUFOQSB0byBhcG9sb2dpemUgZm9yIGEgbGF0ZSBhZGRp dGlvbiBhbmQgc2VlIGhvdyBmYXIgdGhleSBhcmUgaW4gdGhlIHByb2Nlc3MuDQpCVVQsIHdvcnNl LCAgaG93IG11Y2ggdGV4dCBpcyBuZWVkZWQgdG8gZXhwbGFpbiB0aGlzIGFkZGl0aW9uPw0KDQpB ZGRpbmcgdGV4dCB0byBhbiBhcHByb3ZlZCBkb2N1bWVudCBzb3VuZHMgbGlrZSBvcGVuaW5nIGEg Y2FuIG9mIHdvcm1zIHRvIG1lLg0KDQpQZXRlcg0KDQoNClJhaHVsIEFydmluZCBKYWRoYXYgc2No cmVlZiBvcCAyMDE5LTA4LTMwIDA5OjAzOg0KVGhlIERDTyBjb3VsZCBiZSBpbml0aWF0ZWQgZm9y IHJlZ3VsYXIgcm91dGUgaW52YWxpZGF0aW9uIGR1ZSB0byBwYXRoIGNoYW5nZXMgb3IgYmVjYXVz ZSBvZiBtYW5hZ2VtZW50IGRlY2lzaW9uLiBUaGUgc3RhdHVzIGNvZGUgY2FuIGhlbHAgdW5kZXJz dGFuZCB0aGUgcmVhc29uIGZvciBpbml0aWF0aW5nIHRoZSBEQ08uIEkgbGlrZSB0aGUgaWRlYSBv ZiB0aGlzLg0KDQpIb3dldmVyLCBJIGRvbuKAmXQga25vdywgcHJvY2VkdXJhbGx5LCB3aGF0IGl0 IG1lYW5zIHRvIGNoYW5naW5nIHRoZSBkcmFmdCBhdCB0aGlzIHN0YWdlLg0KDQpUaGUgY2hhbmdl cyB0byBkcmFmdCB3b3VsZCBpbmNsdWRlIG5ldyBJQU5BIGNvbnNpZGVyYXRpb25zIGZvciB0aGUg c3RhdHVzIGZpZWxkLg0KDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KU2VudDogMzAgQXVndXN0 IDIwMTkgMTQ6NDMNClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3Jr cyA8cm9sbEBpZXRmLm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbUm9sbF0g c3VnZ2VzdGVkIGFkZGl0aW9uIHRvIGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQtbnBkYW8NCg0K RGVhciBhbGwgOw0KDQpJIGtub3cgaXTigJlzIGxhdGUgYnV0IEnigJlkIHN1Z2dlc3QgYW4gYWRk aXRpb24gdG8gZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhby4gVGhlcmXigJlzIGEgcmVz ZXJ2ZWQgZmllbGQgaW4gdGhlIERDTy4NCk15IHN1Z2dlc3Rpb24gaXMgdG8gdXNlIGl0IHRvIHRy YW5zcG9ydCBSUEwgREFPLUFDSyBzdGF0dXMgdmFsdWVzIGFzIGRlZmluZWQgaW4gUkZDIDY1NTAu IFRoaXMgd2F5IHdlIGNhbiBzaWduYWwgdGhlIHJlYXNvbiBvZiB0aGUgRENPIHRvIHRoZSBub2Rl Lg0KVGhpcyB3aWxsIGJlY29tZSBzaWduaWZpY2FudCB3aXRoIHRoZSBSUEwtdW5hd2FyZSBsZWF2 ZXMgZHJhZnQsIHNvIHdlIGNhbiByZWJ1aWxkIGEgTkEoRUFSTykgd2l0aCBhIG5vbi16ZXJvIHN0 YXR1cyBiYXNlZCBvbiBhIERDTy4NCg0KRWxzZSB0aGUgUlVMIGRyYWZ0IHdpbGwgaGF2ZSB0byB1 cGRhdGUgZWZmaWNpZW50IE5QIERBTywgd2hpY2ggZG9lcyBub3QgbG9vayBhcyBnb29kLg0KDQpB bnkgb2JqZWN0aW9uIHRvIHRoaXM/DQoNClBhc2NhbA0KDQogICAwICAgICAgICAgICAgICAgICAg IDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgIDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0K ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgICB8IFJQTEluc3RhbmNlSUQgfEt8RHwgICBGbGFncyAgIHwgICBS ZXNlcnZlZCAgICB8IERDT1NlcXVlbmNlICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArICAgICAgICAgICAgICAgICAg ICAgICAgICAgIERPREFHSUQob3B0aW9uYWwpICAgICAgICAgICAgICAgICAgKw0KICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8 ICAgT3B0aW9uKHMpLi4uDQogICAgICstKy0rLSstKy0rLSstKy0rDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpS b2xsQGlldGYub3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFpbHRvOlJv bGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwN Cg== --_000_9ED90E269AC94FB986FF3FD838CB0E60ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PlRoZSByZWdpc3RyeSBkb2VzIG5vdCBleGlzdCBzbyB1bmxlc3Mgd2UgZGVjaWRlIHRvIGNy ZWF0ZSBpdCB0aGVyZSBpcyBubyBJQU5BICZuYnNwO2NoYW5nZS4gQ2FsbCBpdCBhbiBvbWlzc2lv biBpbiBSRkMgNjU1MC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZvciB0 aGF0IHJlYXNvbiBJIGhhdmUgYWxyZWFkeSBhZGRlZCB0ZXh0IGluIHRoZSBuZXh0IFJVTCB0byBj cmVhdGUgdGhlIHJlZ2lzdHJ5IChpbiBnaXRodWIpLiBMZXTigJlzIGtlZXAgaXQgaW4gUlVMIHRv IG1pbmltaXplIHRoZSBjaGFuZ2VzIGluIE5QREFPLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+TWluaW1hbCBjaGFuZ2VzIHRvIE5QREFPIGlzIHRvIGNoYW5nZSB0aGUgbmFtZSDigJxy ZXNlcnZlZOKAnSBvZiB0aGUgZmllbGQgaW4gdGhlIGRyYXdpbmcgYW5kIGFkZCB0ZXh0IHNheWlu ZyBzYW1lIHN0YXR1cyBmaWVsZCBhcyBpbiBSUEwgREFPIEFDSy48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PklmIHdlIHJlYWxseSB3YW50IG5ldyBzdGF0dXMgdmFsdWVzIHdlIG1heSBh bHNvIGFkZCB0aGVtIGluIE5QREFPIGFuZCBJ4oCZbGwgYWRhcHQgUlVMLiBCdXQgdGhlcmUgaXMg bm8gYWJzb2x1dGUgbmVlZCB0byBjcmVhdGUgdGhlIHJlZ2lzdHJ5IGluIE5QREFPLjxicj4NCjxi cj4NCjxkaXYgZGlyPSJsdHIiPlJlZ2FyZHMsDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QYXNj YWw8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KTGUgMzAgYW/Du3QgMjAxOSDD oCAwOTozMCwgUGV0ZXIgdmFuIGRlciBTdG9rICZsdDs8YSBocmVmPSJtYWlsdG86c3Rva2NvbnNA YmJobWFpbC5ubCI+c3Rva2NvbnNAYmJobWFpbC5ubDwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7Ojxi cj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRy Ij5IaSBBdXRob3JzLDxicj4NCjxicj4NCkl0IGlzIGEgYml0IGxhdGUgdG8gY2hhbmdlIHRoZSBh cHByb3ZlZCBkcmFmdC48YnI+DQpJdCBpcyBpbiBJQU5BIGVkaXRpbmc7IGFuZCB5b3UgY291bGQg d3JpdGUgdG8gSUFOQSB0byBhcG9sb2dpemUgZm9yIGEgbGF0ZSBhZGRpdGlvbiBhbmQgc2VlIGhv dyBmYXIgdGhleSBhcmUgaW4gdGhlIHByb2Nlc3MuPGJyPg0KQlVULCB3b3JzZSwmbmJzcDsgaG93 IG11Y2ggdGV4dCBpcyBuZWVkZWQgdG8gZXhwbGFpbiB0aGlzIGFkZGl0aW9uPzxicj4NCjxicj4N CkFkZGluZyB0ZXh0IHRvIGFuIGFwcHJvdmVkIGRvY3VtZW50IHNvdW5kcyBsaWtlIG9wZW5pbmcg YSBjYW4gb2Ygd29ybXMgdG8gbWUuPGJyPg0KPGJyPg0KUGV0ZXI8YnI+DQo8YnI+DQo8cD5SYWh1 bCBBcnZpbmQgSmFkaGF2IHNjaHJlZWYgb3AgMjAxOS0wOC0zMCAwOTowMzo8L3A+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0icGFkZGluZzogMCAwLjRlbTsgYm9yZGVyLWxlZnQ6ICMx MDEwZmYgMnB4IHNvbGlkOyBtYXJnaW46IDAiPg0KPCEtLSBodG1sIGlnbm9yZWQgLS0+PCEtLSBo ZWFkIGlnbm9yZWQgLS0+PCEtLSBtZXRhIGlnbm9yZWQgLS0+PCEtLSBtZXRhIGlnbm9yZWQgLS0+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiAjMWY0OTdkOyI+VGhlIERDTyBjb3VsZCBiZSBpbml0aWF0ZWQgZm9yIHJl Z3VsYXIgcm91dGUgaW52YWxpZGF0aW9uIGR1ZSB0byBwYXRoIGNoYW5nZXMgb3IgYmVjYXVzZSBv ZiBtYW5hZ2VtZW50IGRlY2lzaW9uLiBUaGUgc3RhdHVzIGNvZGUgY2FuIGhlbHAgdW5kZXJzdGFu ZCB0aGUgcmVhc29uIGZvciBpbml0aWF0aW5nIHRoZSBEQ08uIEkgbGlrZSB0aGUgaWRlYSBvZiB0 aGlzLjwhLS0gbyBpZ25vcmVkIC0tPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6ICMxZjQ5N2Q7Ij48IS0tIG8gaWdub3JlZCAtLT4mbmJzcDs8L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiAjMWY0OTdk OyI+SG93ZXZlciwgSSBkb27igJl0IGtub3csIHByb2NlZHVyYWxseSwgd2hhdCBpdCBtZWFucyB0 byBjaGFuZ2luZyB0aGUgZHJhZnQgYXQgdGhpcyBzdGFnZS48IS0tIG8gaWdub3JlZCAtLT48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiAjMWY0OTdk OyI+PCEtLSBvIGlnbm9yZWQgLS0+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogIzFmNDk3ZDsiPlRoZSBjaGFuZ2VzIHRvIGRyYWZ0IHdv dWxkIGluY2x1ZGUgbmV3IElBTkEgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBzdGF0dXMgZmllbGQu PCEtLSBvIGlnbm9yZWQgLS0+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjogIzFmNDk3ZDsiPjwhLS0gbyBpZ25vcmVkIC0tPiZuYnNwOzwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOiBub25lOyBib3JkZXItdG9wOiBzb2xpZCAj RTFFMUUxIDEuMHB0OyBwYWRkaW5nOiAzLjBwdCAwY20gMGNtIDBjbTsiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHN0cm9uZz5Gcm9tOjwvc3Ryb25nPiBSb2xsIFs8YSBocmVmPSJtYWlsdG86cm9s bC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxz dHJvbmc+T24gQmVoYWxmIE9mIDwvc3Ryb25nPlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk8YnI+ DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+IDMwIEF1Z3VzdCAyMDE5IDE0OjQzPGJyPg0KPHN0cm9u Zz5Ubzo8L3N0cm9uZz4gUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3Mg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+IFtSb2xsXSBzdWdnZXN0ZWQgYWRkaXRpb24g dG8gZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbzwhLS0gbyBpZ25vcmVkIC0tPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48IS0tIG8gaWdub3JlZCAtLT4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj5EZWFyIGFsbCZuYnNwOzs8IS0t IG8gaWdub3JlZCAtLT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4+PCEt LSBvIGlnbm9yZWQgLS0+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg a25vdyBpdOKAmXMgbGF0ZSBidXQgSeKAmWQgc3VnZ2VzdCBhbiBhZGRpdGlvbiB0byBkcmFmdC1p ZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvLiBUaGVyZeKAmXMgYSByZXNlcnZlZCBmaWVsZCBpbiB0 aGUgRENPLjwhLS0gbyBpZ25vcmVkIC0tPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHN1 Z2dlc3Rpb24gaXMgdG8gdXNlIGl0IHRvIHRyYW5zcG9ydCBSUEwgREFPLUFDSyBzdGF0dXMgdmFs dWVzIGFzIGRlZmluZWQgaW4gUkZDIDY1NTAuIFRoaXMgd2F5IHdlIGNhbiBzaWduYWwgdGhlIHJl YXNvbiBvZiB0aGUgRENPIHRvIHRoZSBub2RlLjwhLS0gbyBpZ25vcmVkIC0tPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMgd2lsbCBiZWNvbWUgc2lnbmlmaWNhbnQgd2l0aCB0aGUgUlBM LXVuYXdhcmUgbGVhdmVzIGRyYWZ0LCBzbyB3ZSBjYW4gcmVidWlsZCBhIE5BKEVBUk8pIHdpdGgg YSBub24temVybyBzdGF0dXMgYmFzZWQgb24gYSBEQ08uPCEtLSBvIGlnbm9yZWQgLS0+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PCEtLSBvIGlnbm9yZWQgLS0+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RWxzZSB0aGUgUlVMIGRyYWZ0IHdpbGwgaGF2ZSB0byB1cGRhdGUgZWZm aWNpZW50IE5QIERBTywgd2hpY2ggZG9lcyBub3QgbG9vayBhcyBnb29kLjwhLS0gbyBpZ25vcmVk IC0tPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjwhLS0gbyBpZ25vcmVkIC0tPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueSBvYmplY3Rpb24gdG8gdGhpcz88IS0tIG8gaWdu b3JlZCAtLT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48IS0tIG8gaWdub3JlZCAtLT4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXNjYWw8IS0tIG8gaWdub3JlZCAtLT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48IS0tIG8gaWdub3JlZCAtLT4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7IGZvbnQtZmFt aWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDM8IS0tIG8gaWdub3JlZCAtLT48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0OyBmb250LWZh bWlseTogJ0NvdXJpZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8IS0t IG8gaWdub3JlZCAtLT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTAuMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwhLS0gbyBpZ25v cmVkIC0tPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMC4wcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgUlBMSW5zdGFuY2VJRCB8S3xEfCZuYnNwOyZuYnNwOyBGbGFncyZuYnNw OyZuYnNwOw0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6IHllbGxvdzsgbXNvLWhpZ2hsaWdodDog eWVsbG93OyI+fCZuYnNwOyZuYnNwOyBSZXNlcnZlZDwvc3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsg fCBEQ09TZXF1ZW5jZSZuYnNwOyZuYnNwOyB8PCEtLSBvIGlnbm9yZWQgLS0+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDsgZm9u dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0Mzs8IS0tIG8gaWdub3JlZCAtLT48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0OyBmb250LWZhbWls eTogJ0NvdXJpZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8IS0tIG8gaWdub3JlZCAtLT48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0OyBmb250LWZhbWls eTogJ0NvdXJpZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzwhLS0gbyBpZ25vcmVkIC0tPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwhLS0gbyBpZ25vcmVkIC0tPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERPREFHSUQo b3B0aW9uYWwpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7PCEtLSBvIGlnbm9yZWQgLS0+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDt8PCEtLSBvIGlnbm9yZWQgLS0+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0Mzs8IS0tIG8gaWdub3JlZCAtLT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0OyBmb250LWZhbWlseTogJ0NvdXJp ZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8IS0tIG8gaWdub3JlZCAtLT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0OyBmb250LWZhbWlseTogJ0NvdXJp ZXIgTmV3JzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOzwhLS0gbyBpZ25vcmVkIC0tPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgT3B0aW9uKHMpLi4uPCEt LSBvIGlnbm9yZWQgLS0+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwLjBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4mbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0Mzs8IS0tIG8gaWdub3JlZCAtLT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PCEtLSBvIGlnbm9yZWQgLS0+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8IS0tIGh0 bWwgaWdub3JlZCAtLT48YnI+DQo8ZGl2IGNsYXNzPSJwcmUiIHN0eWxlPSJtYXJnaW46IDA7IHBh ZGRpbmc6IDA7IGZvbnQtZmFtaWx5OiBtb25vc3BhY2UiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUm9sbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIj5Sb2xsQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbCIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ibm9yZWZlcnJlciI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIi PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9z cGFuPjxicj4NCjxzcGFuPlJvbGwgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhy ZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj5Sb2xsQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8 c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwvYT48L3NwYW4+PGJy Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9ED90E269AC94FB986FF3FD838CB0E60ciscocom_-- From nobody Fri Aug 30 01:31:37 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A238E1200D6 for ; Fri, 30 Aug 2019 01:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTV6AwNf4j3V for ; Fri, 30 Aug 2019 01:31:33 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00688120C74 for ; Fri, 30 Aug 2019 01:31:33 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9E5571E24AC71EA32CC1 for ; Fri, 30 Aug 2019 09:31:30 +0100 (IST) Received: from lhreml725-chm.china.huawei.com (10.201.108.76) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 30 Aug 2019 09:31:29 +0100 Received: from lhreml725-chm.china.huawei.com (10.201.108.76) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 30 Aug 2019 09:31:29 +0100 Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 30 Aug 2019 09:31:29 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.145]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0439.000; Fri, 30 Aug 2019 14:01:20 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks , "consultancy@vanderstok.org" Thread-Topic: [Roll] suggested addition to draft-ietf-roll-efficient-npdao Thread-Index: AdVe/YcA7dtmnImrSGKYwVT3ZLHQqAAAaBpQ//+u5ICAAAs1AP//ozjw Date: Fri, 30 Aug 2019 08:31:20 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DFBB5B8@BLREML503-MBX.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com>, <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> <9ED90E26-9AC9-4FB9-86FF-3FD838CB0E60@cisco.com> In-Reply-To: <9ED90E26-9AC9-4FB9-86FF-3FD838CB0E60@cisco.com> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.81] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DFBB5B8BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 08:31:36 -0000 --_000_982B626E107E334DBE601D979F31785C5DFBB5B8BLREML503MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpNaW5pbWFsIGNoYW5nZXMgdG8gTlBEQU8gaXMgdG8gY2hhbmdlIHRoZSBuYW1lIOKAnHJlc2Vy dmVk4oCdIG9mIHRoZSBmaWVsZCBpbiB0aGUgZHJhd2luZyBhbmQgYWRkIHRleHQgc2F5aW5nIHNh bWUgc3RhdHVzIGZpZWxkIGFzIGluIFJQTCBEQU8gQUNLLg0KDQpJZiB3ZSByZWFsbHkgd2FudCBu ZXcgc3RhdHVzIHZhbHVlcyB3ZSBtYXkgYWxzbyBhZGQgdGhlbSBpbiBOUERBTyBhbmQgSeKAmWxs IGFkYXB0IFJVTC4gQnV0IHRoZXJlIGlzIG5vIGFic29sdXRlIG5lZWQgdG8gY3JlYXRlIHRoZSBy ZWdpc3RyeSBpbiBOUERBTy4NCltSSl0gVGhlIHN0YXR1cyBmaWVsZCB2YWx1ZXMgb2YgREFPLUFD Sy9EQ08tQUNLIGFyZSBub3Qgd2hhdCB3ZSByZXF1aXJlIHRvIGJlIHNlbnQgaW4gRENP4oCmIFdo YXQgd2Ugd2FudCBpcyBhIFJlYXNvbiBmaWVsZCBhbmQgbm90IGEgU3RhdHVzIGZpZWxkIGluIHRo ZSBEQ08uLiBIZW5jZSBJIGJlbGlldmUgdGhhdCB0aGVyZSBhcmUgY2hhbmdlcyByZXF1aXJlZCBm b3IgSUFOQS4gV2UgY2FuIHRha2UgYSBzaG9ydGN1dCBhbmQga2VlcCB0aGUgZmllbGQgc2FtZSBh cyBTdGF0dXMsIGJ1dCBpdCBzZWVtcyBsaWtlIGEgaGFjayB0byBtZS4NCg0KTGUgMzAgYW/Du3Qg MjAxOSDDoCAwOTozMCwgUGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0BiYmhtYWlsLm5sPG1h aWx0bzpzdG9rY29uc0BiYmhtYWlsLm5sPj4gYSDDqWNyaXQgOg0KSGkgQXV0aG9ycywNCg0KSXQg aXMgYSBiaXQgbGF0ZSB0byBjaGFuZ2UgdGhlIGFwcHJvdmVkIGRyYWZ0Lg0KSXQgaXMgaW4gSUFO QSBlZGl0aW5nOyBhbmQgeW91IGNvdWxkIHdyaXRlIHRvIElBTkEgdG8gYXBvbG9naXplIGZvciBh IGxhdGUgYWRkaXRpb24gYW5kIHNlZSBob3cgZmFyIHRoZXkgYXJlIGluIHRoZSBwcm9jZXNzLg0K QlVULCB3b3JzZSwgIGhvdyBtdWNoIHRleHQgaXMgbmVlZGVkIHRvIGV4cGxhaW4gdGhpcyBhZGRp dGlvbj8NCg0KQWRkaW5nIHRleHQgdG8gYW4gYXBwcm92ZWQgZG9jdW1lbnQgc291bmRzIGxpa2Ug b3BlbmluZyBhIGNhbiBvZiB3b3JtcyB0byBtZS4NCg0KUGV0ZXINCg0KUmFodWwgQXJ2aW5kIEph ZGhhdiBzY2hyZWVmIG9wIDIwMTktMDgtMzAgMDk6MDM6DQpUaGUgRENPIGNvdWxkIGJlIGluaXRp YXRlZCBmb3IgcmVndWxhciByb3V0ZSBpbnZhbGlkYXRpb24gZHVlIHRvIHBhdGggY2hhbmdlcyBv ciBiZWNhdXNlIG9mIG1hbmFnZW1lbnQgZGVjaXNpb24uIFRoZSBzdGF0dXMgY29kZSBjYW4gaGVs cCB1bmRlcnN0YW5kIHRoZSByZWFzb24gZm9yIGluaXRpYXRpbmcgdGhlIERDTy4gSSBsaWtlIHRo ZSBpZGVhIG9mIHRoaXMuDQoNCkhvd2V2ZXIsIEkgZG9u4oCZdCBrbm93LCBwcm9jZWR1cmFsbHks IHdoYXQgaXQgbWVhbnMgdG8gY2hhbmdpbmcgdGhlIGRyYWZ0IGF0IHRoaXMgc3RhZ2UuDQoNClRo ZSBjaGFuZ2VzIHRvIGRyYWZ0IHdvdWxkIGluY2x1ZGUgbmV3IElBTkEgY29uc2lkZXJhdGlvbnMg Zm9yIHRoZSBzdGF0dXMgZmllbGQuDQoNCkZyb206IFJvbGwgW21haWx0bzpyb2xsLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpTZW50OiAz MCBBdWd1c3QgMjAxOSAxNDo0Mw0KVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5 IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPj4NClN1YmplY3Q6 IFtSb2xsXSBzdWdnZXN0ZWQgYWRkaXRpb24gdG8gZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1u cGRhbw0KDQpEZWFyIGFsbCA7DQoNCkkga25vdyBpdOKAmXMgbGF0ZSBidXQgSeKAmWQgc3VnZ2Vz dCBhbiBhZGRpdGlvbiB0byBkcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvLiBUaGVyZeKA mXMgYSByZXNlcnZlZCBmaWVsZCBpbiB0aGUgRENPLg0KTXkgc3VnZ2VzdGlvbiBpcyB0byB1c2Ug aXQgdG8gdHJhbnNwb3J0IFJQTCBEQU8tQUNLIHN0YXR1cyB2YWx1ZXMgYXMgZGVmaW5lZCBpbiBS RkMgNjU1MC4gVGhpcyB3YXkgd2UgY2FuIHNpZ25hbCB0aGUgcmVhc29uIG9mIHRoZSBEQ08gdG8g dGhlIG5vZGUuDQpUaGlzIHdpbGwgYmVjb21lIHNpZ25pZmljYW50IHdpdGggdGhlIFJQTC11bmF3 YXJlIGxlYXZlcyBkcmFmdCwgc28gd2UgY2FuIHJlYnVpbGQgYSBOQShFQVJPKSB3aXRoIGEgbm9u LXplcm8gc3RhdHVzIGJhc2VkIG9uIGEgRENPLg0KDQpFbHNlIHRoZSBSVUwgZHJhZnQgd2lsbCBo YXZlIHRvIHVwZGF0ZSBlZmZpY2llbnQgTlAgREFPLCB3aGljaCBkb2VzIG5vdCBsb29rIGFzIGdv b2QuDQoNCkFueSBvYmplY3Rpb24gdG8gdGhpcz8NCg0KUGFzY2FsDQoNCiAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgUlBMSW5zdGFuY2VJRCB8S3xEfCAgIEZsYWdz ICAgfCAgIFJlc2VydmVkICAgIHwgRENPU2VxdWVuY2UgICB8DQogICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRE9EQUdJRChvcHRpb25hbCkgICAgICAgICAgICAgICAgICArDQog ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgIHwgICBPcHRpb24ocykuLi4NCiAgICAgKy0rLSstKy0rLSstKy0rLSsNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5n IGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZzxt YWlsdG86Um9sbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcm9sbA0K --_000_982B626E107E334DBE601D979F31785C5DFBB5B8BLREML503MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pbmltYWwgY2hhbmdlcyB0byBOUERBTyBpcyB0byBj aGFuZ2UgdGhlIG5hbWUg4oCccmVzZXJ2ZWTigJ0gb2YgdGhlIGZpZWxkIGluIHRoZSBkcmF3aW5n IGFuZCBhZGQgdGV4dCBzYXlpbmcgc2FtZSBzdGF0dXMgZmllbGQgYXMgaW4gUlBMIERBTyBBQ0su PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SWYgd2UgcmVhbGx5IHdhbnQgbmV3IHN0YXR1cyB2 YWx1ZXMgd2UgbWF5IGFsc28gYWRkIHRoZW0gaW4gTlBEQU8gYW5kIEnigJlsbCBhZGFwdCBSVUwu IEJ1dCB0aGVyZSBpcyBubyBhYnNvbHV0ZSBuZWVkIHRvIGNyZWF0ZSB0aGUgcmVnaXN0cnkgaW4g TlBEQU8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUkpdIFRoZSBz dGF0dXMgZmllbGQgdmFsdWVzIG9mIERBTy1BQ0svRENPLUFDSyBhcmUgbm90IHdoYXQgd2UgcmVx dWlyZSB0byBiZSBzZW50IGluIERDT+KApiBXaGF0IHdlIHdhbnQgaXMgYSBSZWFzb24gZmllbGQg YW5kIG5vdA0KIGEgU3RhdHVzIGZpZWxkIGluIHRoZSBEQ08uLiBIZW5jZSBJIGJlbGlldmUgdGhh dCB0aGVyZSBhcmUgY2hhbmdlcyByZXF1aXJlZCBmb3IgSUFOQS4gV2UgY2FuIHRha2UgYSBzaG9y dGN1dCBhbmQga2VlcCB0aGUgZmllbGQgc2FtZSBhcyBTdGF0dXMsIGJ1dCBpdCBzZWVtcyBsaWtl IGEgaGFjayB0byBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpMZSAzMCBhb8O7dCAy MDE5IMOgIDA5OjMwLCBQZXRlciB2YW4gZGVyIFN0b2sgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG9r Y29uc0BiYmhtYWlsLm5sIj5zdG9rY29uc0BiYmhtYWlsLm5sPC9hPiZndDsgYSDDqWNyaXQmbmJz cDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgQXV0aG9ycyw8YnI+DQo8YnI+DQpJdCBp cyBhIGJpdCBsYXRlIHRvIGNoYW5nZSB0aGUgYXBwcm92ZWQgZHJhZnQuPGJyPg0KSXQgaXMgaW4g SUFOQSBlZGl0aW5nOyBhbmQgeW91IGNvdWxkIHdyaXRlIHRvIElBTkEgdG8gYXBvbG9naXplIGZv ciBhIGxhdGUgYWRkaXRpb24gYW5kIHNlZSBob3cgZmFyIHRoZXkgYXJlIGluIHRoZSBwcm9jZXNz Ljxicj4NCkJVVCwgd29yc2UsJm5ic3A7IGhvdyBtdWNoIHRleHQgaXMgbmVlZGVkIHRvIGV4cGxh aW4gdGhpcyBhZGRpdGlvbj88YnI+DQo8YnI+DQpBZGRpbmcgdGV4dCB0byBhbiBhcHByb3ZlZCBk b2N1bWVudCBzb3VuZHMgbGlrZSBvcGVuaW5nIGEgY2FuIG9mIHdvcm1zIHRvIG1lLjxicj4NCjxi cj4NClBldGVyPG86cD48L286cD48L3A+DQo8cD5SYWh1bCBBcnZpbmQgSmFkaGF2IHNjaHJlZWYg b3AgMjAxOS0wOC0zMCAwOTowMzo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgRENPIGNvdWxkIGJlIGluaXRpYXRlZCBm b3IgcmVndWxhciByb3V0ZSBpbnZhbGlkYXRpb24gZHVlIHRvIHBhdGggY2hhbmdlcyBvciBiZWNh dXNlIG9mIG1hbmFnZW1lbnQgZGVjaXNpb24uIFRoZSBzdGF0dXMgY29kZSBjYW4gaGVscCB1bmRl cnN0YW5kDQogdGhlIHJlYXNvbiBmb3IgaW5pdGlhdGluZyB0aGUgRENPLiBJIGxpa2UgdGhlIGlk ZWEgb2YgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Ib3dl dmVyLCBJIGRvbuKAmXQga25vdywgcHJvY2VkdXJhbGx5LCB3aGF0IGl0IG1lYW5zIHRvIGNoYW5n aW5nIHRoZSBkcmFmdCBhdCB0aGlzIHN0YWdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlRoZSBjaGFuZ2VzIHRvIGRyYWZ0IHdvdWxkIGluY2x1ZGUgbmV3IElBTkEg Y29uc2lkZXJhdGlvbnMgZm9yIHRoZSBzdGF0dXMgZmllbGQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz5Gcm9tOjwvc3Ryb25nPiBSb2xsIFs8 YSBocmVmPSJtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cm9sbC1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxzdHJvbmc+T24gQmVoYWxmIE9mIDwvc3Ryb25nPlBhc2NhbCBUaHVi ZXJ0IChwdGh1YmVydCk8YnI+DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+IDMwIEF1Z3VzdCAyMDE5 IDE0OjQzPGJyPg0KPHN0cm9uZz5Ubzo8L3N0cm9uZz4gUm91dGluZyBPdmVyIExvdyBwb3dlciBh bmQgTG9zc3kgbmV0d29ya3MgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xs QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+IFtSb2xsXSBz dWdnZXN0ZWQgYWRkaXRpb24gdG8gZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRlYXIgYWxsJm5ic3A7Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBrbm93IGl04oCZcyBsYXRlIGJ1dCBJ4oCZZCBz dWdnZXN0IGFuIGFkZGl0aW9uIHRvIGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQtbnBkYW8uIFRo ZXJl4oCZcyBhIHJlc2VydmVkIGZpZWxkIGluIHRoZSBEQ08uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk15IHN1Z2dlc3Rpb24gaXMgdG8gdXNlIGl0IHRvIHRyYW5zcG9y dCBSUEwgREFPLUFDSyBzdGF0dXMgdmFsdWVzIGFzIGRlZmluZWQgaW4gUkZDIDY1NTAuIFRoaXMg d2F5IHdlIGNhbiBzaWduYWwgdGhlIHJlYXNvbiBvZiB0aGUgRENPIHRvIHRoZSBub2RlLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHdpbGwgYmVjb21lIHNpZ25p ZmljYW50IHdpdGggdGhlIFJQTC11bmF3YXJlIGxlYXZlcyBkcmFmdCwgc28gd2UgY2FuIHJlYnVp bGQgYSBOQShFQVJPKSB3aXRoIGEgbm9uLXplcm8gc3RhdHVzIGJhc2VkIG9uIGEgRENPLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RWxzZSB0aGUgUlVMIGRyYWZ0IHdpbGwgaGF2ZSB0byB1 cGRhdGUgZWZmaWNpZW50IE5QIERBTywgd2hpY2ggZG9lcyBub3QgbG9vayBhcyBnb29kLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW55IG9iamVjdGlvbiB0byB0aGlzPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+UGFzY2FsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgUlBMSW5zdGFuY2VJRCB8S3xEfCZuYnNwOyZuYnNwOyBGbGFncyZuYnNwOyZuYnNwOw0KPHNw YW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij58Jm5ic3A7 Jm5ic3A7IFJlc2VydmVkPC9zcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyB8IERDT1NlcXVlbmNlJm5i c3A7Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBET0RBR0lEKG9wdGlvbmFsKSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgT3B0aW9uKHMpLi4uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClJvbGwgbWFpbGluZyBsaXN0PGJy Pg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJvbGxAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9s bCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClJvbGwgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciPlJvbGxAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_982B626E107E334DBE601D979F31785C5DFBB5B8BLREML503MBXchi_-- From nobody Fri Aug 30 01:50:34 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5D7120C80 for ; Fri, 30 Aug 2019 01:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=bjrjUVCC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Zog+tBcQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1eN6Jh0zul1 for ; Fri, 30 Aug 2019 01:50:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D041201AA for ; Fri, 30 Aug 2019 01:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52024; q=dns/txt; s=iport; t=1567155030; x=1568364630; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9uZPR+U6hylDPXR3ma7yjqhK2gbcI59JlKJ5PwYE7+c=; b=bjrjUVCCYW/7UrxU+QpL/TbX9jApZGkzIoui2cUcNu4AOW7tdZdUPAW/ GFEZrNWEY7EuO6YOvJCoR5JaKtkkxjmK95hhHTE1S2uuhNTEu1lF9jO7r sw/20X++9bM1InZGlmsPRCN13Qmb4E6zRfCOxuHSunGPOBrErP3BueP// o=; IronPort-PHdr: =?us-ascii?q?9a23=3AtlJYNxNpEJxe5DjwDb4l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjMP73ZSEgAOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AAD34Whd/5hdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4EWLyQsA21WIAQLKoQhg0cDinFNgg+Xa4FCgRADUAQJAQE?= =?us-ascii?q?BDAEBGAEKCgIBAYQ/AheCRSM4EwIDCAEBBAEBAQIBBgRthS4MhUoBAQEEAQE?= =?us-ascii?q?QEQoTAQEsBgYPAgEIEQQBASEBBgMCAgIlCxQJCAEBBAESCBqDAYEdTQMdAQI?= =?us-ascii?q?MoSUCgTiIYXOBMoJ8AQEFhRAYghYDBoE0i3cYgUA/gRFGgkw+gmEBAYEpBBg?= =?us-ascii?q?EBBYVFgmCVTKCJoxBCoJbhRokgg2VHAkCgh+OC4ZmgjKWLY1xgTaXAwIEAgQ?= =?us-ascii?q?FAg4BAQWBZyGBWHAVO4JsgkKDcoUUhT9ygSmLNgEkB4InAQE?= X-IronPort-AV: E=Sophos;i="5.64,446,1559520000"; d="scan'208,217";a="617796304" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2019 08:50:29 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x7U8oTZY018622 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Aug 2019 08:50:29 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 03:50:28 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 03:50:28 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 30 Aug 2019 03:50:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b0lQyOtHrAzOk88+a6i33T2Y56DlmkgOPfhkj9ymRxePdxqdjfd6ubd2cetILPOw4fh7VxbY6urMkBQI1YlW3D3Uu9CDQ+fVG+/evYif9VinWiYpWCPuOhbCVH9mWyYxiWN9HnBSvsQADH8g3EdFuZXMhB72cdn0q2jIgByf53hdwwPHz7cX8GrVeTEaTOg4iT8XHl43jLjzwbq+nPkW1D6vEX4tK0OKTQ7QL2bqc2Ur74OLvo2aODaTU5yHEW7K/0U5wNcZzkTGA238zGhKqnlo8a6jaN0MenChsriGtyAz2oR19vEECQhacKf5U6gkn0xR3Wa0AL9CR1PNeOGUvw== 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=9uZPR+U6hylDPXR3ma7yjqhK2gbcI59JlKJ5PwYE7+c=; b=MkRyIctiFwkXr73jhAwBBP06gWFvP1SeC3lmxlGJqX5NpTWurYym0Iz+EWBjABXOz77Ji8fmReJHsq84sI+a9Coj/nUBGDW8Z5ZUMLQcBVQAPgj7tR7n4foxA1ZaZvvaHdL8fNy7CAOiEP9K+6+vmMVtAx9BaKx/35p6VfCOH+Z6oa4jYx6ivTIaLp5imG+pzJ40hdp3H8MSulUGhSW6xN2t8alTj7BHKdxcd8Hzj6elxwVpY3SpQ4E32+ryJ3q+MKYTzRokflHbSVxI7Ncozxo5cbjFLqi5NYNmV6lJLrJD5sh75H6nQIygzKv7aYbHn2OpLkeCuy4Iz/MlfoEHkA== 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=9uZPR+U6hylDPXR3ma7yjqhK2gbcI59JlKJ5PwYE7+c=; b=Zog+tBcQcsoGzjyKKAvvkoMZMq9ljiyZgXp50MK9vSI5VbpGu/FgCqGhxu2LqC+tf6dkIHpAbF0f1gSCKZL1PomDihR98xLtplJ4eCkBqekCy74svB1moJi3+HmtIObc84eNRthssjrfbab91G3V6W8tJxtgVWczmmmTmlxMr7s= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4191.namprd11.prod.outlook.com (20.179.151.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.19; Fri, 30 Aug 2019 08:50:26 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.013; Fri, 30 Aug 2019 08:50:26 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks , "consultancy@vanderstok.org" Thread-Topic: [Roll] suggested addition to draft-ietf-roll-efficient-npdao Thread-Index: AdVe/YcA7dtmnImrSGKYwVT3ZLHQqAAAaBpQAAFi+YAAAWbH1AAAv4YAAAAY5oA= Date: Fri, 30 Aug 2019 08:50:08 +0000 Deferred-Delivery: Fri, 30 Aug 2019 08:50:01 +0000 Message-ID: References: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com>, <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> <9ED90E26-9AC9-4FB9-86FF-3FD838CB0E60@cisco.com> <982B626E107E334DBE601D979F31785C5DFBB5B8@BLREML503-MBX.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DFBB5B8@BLREML503-MBX.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1003::52] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: be16a819-dc52-4233-8d7b-08d72d271a54 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4191; x-ms-traffictypediagnostic: MN2PR11MB4191: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(366004)(376002)(199004)(189003)(33656002)(25786009)(66556008)(186003)(55016002)(86362001)(76116006)(6666004)(229853002)(64756008)(11346002)(99286004)(66476007)(66446008)(66946007)(2501003)(6306002)(790700001)(478600001)(54896002)(6116002)(606006)(6436002)(236005)(8676002)(14454004)(6246003)(966005)(9686003)(14444005)(46003)(256004)(8936002)(66574012)(81156014)(76176011)(81166006)(316002)(110136005)(486006)(53936002)(2906002)(7736002)(7696005)(5660300002)(476003)(71200400001)(6506007)(74316002)(102836004)(53546011)(71190400001)(446003)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4191; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: am1UdMgCO6GKf/spGdWJkDsNCtFBUAl3jbJGecG9NQ/8Vu06Qxj78PGkCPALOxGuEpBKH9zAOgxdsrhAd5cLuMVe+V40JIE5XF03+2G2G53gwPViatWuVDba3m4ttih0yF8MWIFBow3T+OpOBbi2CLGMjfuyaT+ljihZ8APt2P/z7cVJMwricWGxjlKVY37PTOBf19Hlt6MxLagUoteDwBEP1EBlyk8ZwNAUFHUnbGm4laBRXDXrE8Qy9lh+gF4LGx0XVHO56VFZ9woN2A58VPzHyK7kVoIwVUiJwnJOblHdH4f2NXANquUulXYCxvjByJif1oo8sercFc81+/ncopYwdyn7WDaRfETDhOaPiKxHAktkKm83p8vEpU/5UA8HY2WuV1L0b/IJAo7XtER3zrF9HwV9fjVz/Je2J4xBPUY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565A86B9435F35E383885BDD8BD0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: be16a819-dc52-4233-8d7b-08d72d271a54 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 08:50:26.3658 (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: Bj5uqO+lggVlsCOkoZqfrDY/g7aOr7WtHj78CmJ9uGdJrBNx0cozfoh1OuKiHiw/7kNRIqHX/ell+Wv7XVhHAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4191 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 08:50:34 -0000 --_000_MN2PR11MB3565A86B9435F35E383885BDD8BD0MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SHVtOw0KDQpUaGUgdGVybSDigJxzdGF0dXPigJ0gbWF5IGJlIGFidXNlZCwgYnV0IGl0IHByYWN0 aWNlIGl0IG1lYW5zIG1vcmUgdGhhbiBhIHN0YXRlLiBJdCBpcyBtb3JlIGxpa2UgYSByZXR1cm4g Y29kZS4NClJVTCB1c2VzIHRoZSDigJxTdGF0dXMgdmFsdWVz4oCdIGZyb20gNkxvV1BBTiBORCBh bmQgdHJhbnNwb3J0cyB0aGVtIG9uIERDTy4NCkUuZy4sIHRoZSBiYWNrYm9uZSByb3V0ZXIgdXNl cyDigJxyZW1vdmVk4oCdIHRvIGluZGljYXRlIHRoYXQgYW5vdGhlciBCQlIgbm93IG93bnMgdGhl IGFkZHJlc3MuDQpJbiBhIDZUaVNDSCBuZXR3b3JrIHRoYXQgd291bGQgbWVhbiBpbiBhbm90aGVy IFJQTCBET0RBRywgc28gdGhlIGFkZHJlc3MgaW4gdGhpcyBET0RBRyBuZWVkcyB0byBiZSBjbGVh bmVkIHVwLiBEQ08gaXMgdGhlIHdheSB0byBkbyB0aGF0LiBTbyB0aGUgZXhwZWN0YXRpb24gaXMg YSBEQ08gd2l0aCBhIHN0YXR1cyBjb2RlIOKAmHJlbW92ZWTigJkgYXMgd2VsbC4NClRoZSA2bG8g Y2hhaXJzIGFza2VkIG1lIHRvIHJlbW92ZSB0ZXh0IG9uIFJQTCBmcm9tIHRoZSBCQlIgc28gdGhl IGFib3ZlIGlzIHN0aWxsIG51c3BlY2lmaWVkLCB3ZeKAmWxsIGRvIHRoYXQgb25jZSB0aGUgQkJS IGhhcyBzaGlwcGVkLg0KDQpJZiB5b3UgbG9vayBhdCB0aGUgdmFsdWVzIGluIFJVTCByaWdodCBu b3cgdGhleSBhcmUgZXhhY3RseSB0aGUgc29ydCBvZiB0aGluZyB5b3XigJlyZSB0YWxraW5nIGFi b3V0OyBjdXJyZW50IElBTkEgc2VjdGlvbiBvZiBSVUwgaGFzIHRoZSBmb2xsb3dpbmc6DQoNCiAg ICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0rDQogICAgfCAgVmFsdWUgIHwgICAgICAgICAgICAgICBNZWFuaW5nICAgICAg ICAgICAgICAgIHwgRGVmaW5pbmcgU3BlYyAgfA0KICAgICstLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8ICAgIDAg ICAgfCAgICAgICAgVW5xdWFsaWZpZWQgYWNjZXB0YW5jZSAgICAgICAgfCAgICBSRkM2NTUwICAg ICB8DQogICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgfA0KICAgIHwgIDEtMTI3ICB8ICAgICAgUmVzZXJ2ZWQgZm9yIFdh cm5pbmcgQ29kZXMgICAgICB8ICAgIFJGQzY1NTAgICAgIHwNCiAgICB8ICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogICAg fCAgIDEyOCAgIHwgICAgICAgICAgRHVwbGljYXRlIEFkZHJlc3MgICAgICAgICAgIHwgICAgVGhp cyBSRkMgICAgfA0KICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgMTI5ICAgfCAgICAgICAgICAgIE91 dCBvZiBTdG9yYWdlICAgICAgICAgICAgfCAgICBUaGlzIFJGQyAgICB8DQogICAgfCAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg fA0KICAgIHwgICAxMzAgICB8ICAgICAgICAgICAgICAgIE1vdmVkICAgICAgICAgICAgICAgICB8 ICAgIFRoaXMgUkZDICAgIHwNCiAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogICAgfCAgIDEzMSAgIHwgICAgICAg ICAgICAgICBSZW1vdmVkICAgICAgICAgICAgICAgIHwgICAgVGhpcyBSRkMgICAgfA0KICAgIHwg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgIHwNCiAgICB8ICAgMTMyICAgfCAgICAgICAgIFZhbGlkYXRpb24gUmVxdWVzdGVkICAg ICAgICAgfCAgICBUaGlzIFJGQyAgICB8DQogICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KICAgIHwgICAxMzMgICB8 ICAgICAgIER1cGxpY2F0ZSBTb3VyY2UgQWRkcmVzcyAgICAgICB8ICAgIFRoaXMgUkZDICAgIHwN CiAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICB8DQogICAgfCAgIDEzNCAgIHwgICAgICAgIEludmFsaWQgU291cmNlIEFk ZHJlc3MgICAgICAgIHwgICAgVGhpcyBSRkMgICAgfA0KICAgIHwgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICB8ICAg MTM1ICAgfCAgIEFkZHJlc3MgdG9wb2xvZ2ljYWxseSBpbmNvcnJlY3QgICAgfCAgICBUaGlzIFJG QyAgICB8DQogICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgfA0KICAgIHwgICAxMzYgICB8ICAgICAgIDZMQlIgUmVnaXN0 cnkgc2F0dXJhdGVkICAgICAgICB8ICAgIFRoaXMgUkZDICAgIHwNCiAgICB8ICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQog ICAgfCAgIDEzNyAgIHwgICAgICAgICAgVmFsaWRhdGlvbiBGYWlsZWQgICAgICAgICAgIHwgICAg VGhpcyBSRkMgICAgfA0KICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICB8IDEzOC0xOTIgfCBSZXNlcnZlZCBm b3IgNkxvV1BBTiBORCBjb2RlIG1hcHBpbmcgfCAgICBUaGlzIFJGQyAgICB8DQogICAgfCAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgfA0KICAgIHwgMTkzLTI1NSB8ICBSZXNlcnZlZCBmb3Igb3RoZXIgUmVqZWN0aW9uIENvZGVz ICB8ICAgIFJGQzY1NTAgICAgIHwNCiAgICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0rDQoNCkFsbCB0aGUgYmVzdCwNCg0K UGFzY2FsDQoNCkZyb206IFJvbGwgPHJvbGwtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IFJhaHVsIEFydmluZCBKYWRoYXYNClNlbnQ6IHZlbmRyZWRpIDMwIGFvw7t0IDIwMTkgMTA6MzEN ClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRm Lm9yZz47IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnDQpTdWJqZWN0OiBSZTogW1JvbGxdIHN1 Z2dlc3RlZCBhZGRpdGlvbiB0byBkcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvDQoNCg0K TWluaW1hbCBjaGFuZ2VzIHRvIE5QREFPIGlzIHRvIGNoYW5nZSB0aGUgbmFtZSDigJxyZXNlcnZl ZOKAnSBvZiB0aGUgZmllbGQgaW4gdGhlIGRyYXdpbmcgYW5kIGFkZCB0ZXh0IHNheWluZyBzYW1l IHN0YXR1cyBmaWVsZCBhcyBpbiBSUEwgREFPIEFDSy4NCg0KSWYgd2UgcmVhbGx5IHdhbnQgbmV3 IHN0YXR1cyB2YWx1ZXMgd2UgbWF5IGFsc28gYWRkIHRoZW0gaW4gTlBEQU8gYW5kIEnigJlsbCBh ZGFwdCBSVUwuIEJ1dCB0aGVyZSBpcyBubyBhYnNvbHV0ZSBuZWVkIHRvIGNyZWF0ZSB0aGUgcmVn aXN0cnkgaW4gTlBEQU8uDQpbUkpdIFRoZSBzdGF0dXMgZmllbGQgdmFsdWVzIG9mIERBTy1BQ0sv RENPLUFDSyBhcmUgbm90IHdoYXQgd2UgcmVxdWlyZSB0byBiZSBzZW50IGluIERDT+KApiBXaGF0 IHdlIHdhbnQgaXMgYSBSZWFzb24gZmllbGQgYW5kIG5vdCBhIFN0YXR1cyBmaWVsZCBpbiB0aGUg RENPLi4gSGVuY2UgSSBiZWxpZXZlIHRoYXQgdGhlcmUgYXJlIGNoYW5nZXMgcmVxdWlyZWQgZm9y IElBTkEuIFdlIGNhbiB0YWtlIGEgc2hvcnRjdXQgYW5kIGtlZXAgdGhlIGZpZWxkIHNhbWUgYXMg U3RhdHVzLCBidXQgaXQgc2VlbXMgbGlrZSBhIGhhY2sgdG8gbWUuDQoNCkxlIDMwIGFvw7t0IDIw MTkgw6AgMDk6MzAsIFBldGVyIHZhbiBkZXIgU3RvayA8c3Rva2NvbnNAYmJobWFpbC5ubDxtYWls dG86c3Rva2NvbnNAYmJobWFpbC5ubD4+IGEgw6ljcml0IDoNCkhpIEF1dGhvcnMsDQoNCkl0IGlz IGEgYml0IGxhdGUgdG8gY2hhbmdlIHRoZSBhcHByb3ZlZCBkcmFmdC4NCkl0IGlzIGluIElBTkEg ZWRpdGluZzsgYW5kIHlvdSBjb3VsZCB3cml0ZSB0byBJQU5BIHRvIGFwb2xvZ2l6ZSBmb3IgYSBs YXRlIGFkZGl0aW9uIGFuZCBzZWUgaG93IGZhciB0aGV5IGFyZSBpbiB0aGUgcHJvY2Vzcy4NCkJV VCwgd29yc2UsICBob3cgbXVjaCB0ZXh0IGlzIG5lZWRlZCB0byBleHBsYWluIHRoaXMgYWRkaXRp b24/DQoNCkFkZGluZyB0ZXh0IHRvIGFuIGFwcHJvdmVkIGRvY3VtZW50IHNvdW5kcyBsaWtlIG9w ZW5pbmcgYSBjYW4gb2Ygd29ybXMgdG8gbWUuDQoNClBldGVyDQoNClJhaHVsIEFydmluZCBKYWRo YXYgc2NocmVlZiBvcCAyMDE5LTA4LTMwIDA5OjAzOg0KVGhlIERDTyBjb3VsZCBiZSBpbml0aWF0 ZWQgZm9yIHJlZ3VsYXIgcm91dGUgaW52YWxpZGF0aW9uIGR1ZSB0byBwYXRoIGNoYW5nZXMgb3Ig YmVjYXVzZSBvZiBtYW5hZ2VtZW50IGRlY2lzaW9uLiBUaGUgc3RhdHVzIGNvZGUgY2FuIGhlbHAg dW5kZXJzdGFuZCB0aGUgcmVhc29uIGZvciBpbml0aWF0aW5nIHRoZSBEQ08uIEkgbGlrZSB0aGUg aWRlYSBvZiB0aGlzLg0KDQpIb3dldmVyLCBJIGRvbuKAmXQga25vdywgcHJvY2VkdXJhbGx5LCB3 aGF0IGl0IG1lYW5zIHRvIGNoYW5naW5nIHRoZSBkcmFmdCBhdCB0aGlzIHN0YWdlLg0KDQpUaGUg Y2hhbmdlcyB0byBkcmFmdCB3b3VsZCBpbmNsdWRlIG5ldyBJQU5BIGNvbnNpZGVyYXRpb25zIGZv ciB0aGUgc3RhdHVzIGZpZWxkLg0KDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KU2VudDogMzAg QXVndXN0IDIwMTkgMTQ6NDMNClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBu ZXR3b3JrcyA8cm9sbEBpZXRmLm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBb Um9sbF0gc3VnZ2VzdGVkIGFkZGl0aW9uIHRvIGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQtbnBk YW8NCg0KRGVhciBhbGwgOw0KDQpJIGtub3cgaXTigJlzIGxhdGUgYnV0IEnigJlkIHN1Z2dlc3Qg YW4gYWRkaXRpb24gdG8gZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhby4gVGhlcmXigJlz IGEgcmVzZXJ2ZWQgZmllbGQgaW4gdGhlIERDTy4NCk15IHN1Z2dlc3Rpb24gaXMgdG8gdXNlIGl0 IHRvIHRyYW5zcG9ydCBSUEwgREFPLUFDSyBzdGF0dXMgdmFsdWVzIGFzIGRlZmluZWQgaW4gUkZD IDY1NTAuIFRoaXMgd2F5IHdlIGNhbiBzaWduYWwgdGhlIHJlYXNvbiBvZiB0aGUgRENPIHRvIHRo ZSBub2RlLg0KVGhpcyB3aWxsIGJlY29tZSBzaWduaWZpY2FudCB3aXRoIHRoZSBSUEwtdW5hd2Fy ZSBsZWF2ZXMgZHJhZnQsIHNvIHdlIGNhbiByZWJ1aWxkIGEgTkEoRUFSTykgd2l0aCBhIG5vbi16 ZXJvIHN0YXR1cyBiYXNlZCBvbiBhIERDTy4NCg0KRWxzZSB0aGUgUlVMIGRyYWZ0IHdpbGwgaGF2 ZSB0byB1cGRhdGUgZWZmaWNpZW50IE5QIERBTywgd2hpY2ggZG9lcyBub3QgbG9vayBhcyBnb29k Lg0KDQpBbnkgb2JqZWN0aW9uIHRvIHRoaXM/DQoNClBhc2NhbA0KDQogICAwICAgICAgICAgICAg ICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQ0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgICB8IFJQTEluc3RhbmNlSUQgfEt8RHwgICBGbGFncyAg IHwgICBSZXNlcnZlZCAgICB8IERDT1NlcXVlbmNlICAgfA0KICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArICAgICAgICAgICAg ICAgICAgICAgICAgICAgIERPREFHSUQob3B0aW9uYWwpICAgICAgICAgICAgICAgICAgKw0KICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgICB8ICAgT3B0aW9uKHMpLi4uDQogICAgICstKy0rLSstKy0rLSstKy0rDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBs aXN0DQpSb2xsQGlldGYub3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFp bHRvOlJvbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGwNCg== --_000_MN2PR11MB3565A86B9435F35E383885BDD8BD0MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkh1bTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHRlcm0g4oCc c3RhdHVz4oCdIG1heSBiZSBhYnVzZWQsIGJ1dCBpdCBwcmFjdGljZSBpdCBtZWFucyBtb3JlIHRo YW4gYSBzdGF0ZS4gSXQgaXMgbW9yZSBsaWtlIGEgcmV0dXJuIGNvZGUuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJVTCB1c2Vz IHRoZSDigJxTdGF0dXMgdmFsdWVz4oCdIGZyb20gNkxvV1BBTiBORCBhbmQgdHJhbnNwb3J0cyB0 aGVtIG9uIERDTy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RS5nLiwgdGhlIGJhY2tib25lIHJvdXRlciB1c2VzIOKAnHJlbW92 ZWTigJ0gdG8gaW5kaWNhdGUgdGhhdCBhbm90aGVyIEJCUiBub3cgb3ducyB0aGUgYWRkcmVzcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkluIGEgNlRpU0NIIG5ldHdvcmsgdGhhdCB3b3VsZCBtZWFuIGluIGFub3RoZXIgUlBMIERP REFHLCBzbyB0aGUgYWRkcmVzcyBpbiB0aGlzIERPREFHIG5lZWRzIHRvIGJlIGNsZWFuZWQgdXAu IERDTyBpcyB0aGUgd2F5IHRvIGRvIHRoYXQuIFNvIHRoZSBleHBlY3RhdGlvbiBpcyBhIERDTyB3 aXRoIGENCiBzdGF0dXMgY29kZSDigJhyZW1vdmVk4oCZIGFzIHdlbGwuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgNmxvIGNo YWlycyBhc2tlZCBtZSB0byByZW1vdmUgdGV4dCBvbiBSUEwgZnJvbSB0aGUgQkJSIHNvIHRoZSBh Ym92ZSBpcyBzdGlsbCBudXNwZWNpZmllZCwgd2XigJlsbCBkbyB0aGF0IG9uY2UgdGhlIEJCUiBo YXMgc2hpcHBlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWYgeW91IGxvb2sgYXQgdGhlIHZhbHVlcyBpbiBS VUwgcmlnaHQgbm93IHRoZXkgYXJlIGV4YWN0bHkgdGhlIHNvcnQgb2YgdGhpbmcgeW914oCZcmUg dGFsa2luZyBhYm91dDsgY3VycmVudCBJQU5BIHNlY3Rpb24gb2YgUlVMIGhhcyB0aGUgZm9sbG93 aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLSYjNDM7LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0mIzQz OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBWYWx1ZSZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE1lYW5pbmcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBEZWZp bmluZyBTcGVjJm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLSYj NDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVbnF1YWxpZmll ZCBhY2NlcHRhbmNlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsgUkZDNjU1MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7IDEtMTI3Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzZXJ2ZWQg Zm9yIFdhcm5pbmcgQ29kZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyBSRkM2NTUwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsgMTI4Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgRHVwbGljYXRlIEFkZHJlc3MmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNw OyBUaGlzIFJGQyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDEyOSZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE91dCBvZiBTdG9yYWdlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsgVGhpcyBSRkMmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAxMzAmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNb3ZlZCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgUkZD Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMTMxJm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVtb3ZlZCZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgUkZDJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsgMTMyJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVmFsaWRhdGlvbiBSZXF1ZXN0ZWQmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBU aGlzIFJGQyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDEzMyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IER1cGxpY2F0ZSBTb3VyY2Ug QWRkcmVzcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoaXMgUkZDJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMTM0Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW52 YWxpZCBTb3VyY2UgQWRkcmVzcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgUkZDJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsgMTM1Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgQWRkcmVzcyB0b3BvbG9n aWNhbGx5IGluY29ycmVjdCZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo aXMgUkZDJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMTM2Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNkxCUiBSZWdpc3RyeSBzYXR1 cmF0ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyBUaGlzIFJGQyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDEz NyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFZhbGlkYXRpb24gRmFpbGVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgVGhp cyBSRkMmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCAxMzgtMTkyIHwgUmVzZXJ2ZWQgZm9yIDZMb1dQ QU4gTkQgY29kZSBtYXBwaW5nIHwmbmJzcDsgJm5ic3A7Jm5ic3A7VGhpcyBSRkMmbmJzcDsmbmJz cDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsgfCAxOTMtMjU1IHwmbmJzcDsgUmVzZXJ2ZWQgZm9yIG90aGVyIFJlamVjdGlv biBDb2RlcyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJGQzY1NTAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkFsbCB0aGUgYmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UGFzY2FsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gUm9sbCAmbHQ7cm9sbC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwv Yj5SYWh1bCBBcnZpbmQgSmFkaGF2PGJyPg0KPGI+U2VudDo8L2I+IHZlbmRyZWRpIDMwIGFvw7t0 IDIwMTkgMTA6MzE8YnI+DQo8Yj5Ubzo8L2I+IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExv c3N5IG5ldHdvcmtzICZsdDtyb2xsQGlldGYub3JnJmd0OzsgY29uc3VsdGFuY3lAdmFuZGVyc3Rv ay5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSb2xsXSBzdWdnZXN0ZWQgYWRkaXRpb24g dG8gZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk1pbmltYWwgY2hhbmdlcyB0byBOUERBTyBpcyB0byBjaGFuZ2Ug dGhlIG5hbWUg4oCccmVzZXJ2ZWTigJ0gb2YgdGhlIGZpZWxkIGluIHRoZSBkcmF3aW5nIGFuZCBh ZGQgdGV4dCBzYXlpbmcgc2FtZSBzdGF0dXMgZmllbGQgYXMgaW4gUlBMIERBTyBBQ0suPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SWYgd2UgcmVhbGx5IHdhbnQgbmV3IHN0YXR1cyB2YWx1ZXMg d2UgbWF5IGFsc28gYWRkIHRoZW0gaW4gTlBEQU8gYW5kIEnigJlsbCBhZGFwdCBSVUwuIEJ1dCB0 aGVyZSBpcyBubyBhYnNvbHV0ZSBuZWVkIHRvIGNyZWF0ZSB0aGUgcmVnaXN0cnkgaW4gTlBEQU8u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUkpdIFRoZSBzdGF0dXMg ZmllbGQgdmFsdWVzIG9mIERBTy1BQ0svRENPLUFDSyBhcmUgbm90IHdoYXQgd2UgcmVxdWlyZSB0 byBiZSBzZW50IGluIERDT+KApiBXaGF0IHdlIHdhbnQgaXMgYSBSZWFzb24gZmllbGQgYW5kIG5v dA0KIGEgU3RhdHVzIGZpZWxkIGluIHRoZSBEQ08uLiBIZW5jZSBJIGJlbGlldmUgdGhhdCB0aGVy ZSBhcmUgY2hhbmdlcyByZXF1aXJlZCBmb3IgSUFOQS4gV2UgY2FuIHRha2UgYSBzaG9ydGN1dCBh bmQga2VlcCB0aGUgZmllbGQgc2FtZSBhcyBTdGF0dXMsIGJ1dCBpdCBzZWVtcyBsaWtlIGEgaGFj ayB0byBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpMZSAzMCBhb8O7dCAyMDE5IMOg IDA5OjMwLCBQZXRlciB2YW4gZGVyIFN0b2sgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG9rY29uc0Bi YmhtYWlsLm5sIj5zdG9rY29uc0BiYmhtYWlsLm5sPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgQXV0aG9ycyw8YnI+DQo8YnI+DQpJdCBpcyBhIGJp dCBsYXRlIHRvIGNoYW5nZSB0aGUgYXBwcm92ZWQgZHJhZnQuPGJyPg0KSXQgaXMgaW4gSUFOQSBl ZGl0aW5nOyBhbmQgeW91IGNvdWxkIHdyaXRlIHRvIElBTkEgdG8gYXBvbG9naXplIGZvciBhIGxh dGUgYWRkaXRpb24gYW5kIHNlZSBob3cgZmFyIHRoZXkgYXJlIGluIHRoZSBwcm9jZXNzLjxicj4N CkJVVCwgd29yc2UsJm5ic3A7IGhvdyBtdWNoIHRleHQgaXMgbmVlZGVkIHRvIGV4cGxhaW4gdGhp cyBhZGRpdGlvbj88YnI+DQo8YnI+DQpBZGRpbmcgdGV4dCB0byBhbiBhcHByb3ZlZCBkb2N1bWVu dCBzb3VuZHMgbGlrZSBvcGVuaW5nIGEgY2FuIG9mIHdvcm1zIHRvIG1lLjxicj4NCjxicj4NClBl dGVyPG86cD48L286cD48L3A+DQo8cD5SYWh1bCBBcnZpbmQgSmFkaGF2IHNjaHJlZWYgb3AgMjAx OS0wOC0zMCAwOTowMzo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMEZGIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgRENPIGNvdWxkIGJlIGluaXRpYXRlZCBmb3IgcmVn dWxhciByb3V0ZSBpbnZhbGlkYXRpb24gZHVlIHRvIHBhdGggY2hhbmdlcyBvciBiZWNhdXNlIG9m IG1hbmFnZW1lbnQgZGVjaXNpb24uIFRoZSBzdGF0dXMgY29kZSBjYW4gaGVscCB1bmRlcnN0YW5k DQogdGhlIHJlYXNvbiBmb3IgaW5pdGlhdGluZyB0aGUgRENPLiBJIGxpa2UgdGhlIGlkZWEgb2Yg dGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCBJ IGRvbuKAmXQga25vdywgcHJvY2VkdXJhbGx5LCB3aGF0IGl0IG1lYW5zIHRvIGNoYW5naW5nIHRo ZSBkcmFmdCBhdCB0aGlzIHN0YWdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlRoZSBjaGFuZ2VzIHRvIGRyYWZ0IHdvdWxkIGluY2x1ZGUgbmV3IElBTkEgY29uc2lk ZXJhdGlvbnMgZm9yIHRoZSBzdGF0dXMgZmllbGQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz5Gcm9tOjwvc3Ryb25nPiBSb2xsIFs8YSBocmVm PSJtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cm9sbC1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxzdHJvbmc+T24gQmVoYWxmIE9mIDwvc3Ryb25nPlBhc2NhbCBUaHViZXJ0IChw dGh1YmVydCk8YnI+DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+IDMwIEF1Z3VzdCAyMDE5IDE0OjQz PGJyPg0KPHN0cm9uZz5Ubzo8L3N0cm9uZz4gUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9z c3kgbmV0d29ya3MgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+IFtSb2xsXSBzdWdnZXN0 ZWQgYWRkaXRpb24gdG8gZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRlYXIgYWxsJm5ic3A7OzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBrbm93IGl04oCZcyBsYXRlIGJ1dCBJ4oCZZCBzdWdnZXN0 IGFuIGFkZGl0aW9uIHRvIGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQtbnBkYW8uIFRoZXJl4oCZ cyBhIHJlc2VydmVkIGZpZWxkIGluIHRoZSBEQ08uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk15IHN1Z2dlc3Rpb24gaXMgdG8gdXNlIGl0IHRvIHRyYW5zcG9ydCBSUEwg REFPLUFDSyBzdGF0dXMgdmFsdWVzIGFzIGRlZmluZWQgaW4gUkZDIDY1NTAuIFRoaXMgd2F5IHdl IGNhbiBzaWduYWwgdGhlIHJlYXNvbiBvZiB0aGUgRENPIHRvIHRoZSBub2RlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHdpbGwgYmVjb21lIHNpZ25pZmljYW50 IHdpdGggdGhlIFJQTC11bmF3YXJlIGxlYXZlcyBkcmFmdCwgc28gd2UgY2FuIHJlYnVpbGQgYSBO QShFQVJPKSB3aXRoIGEgbm9uLXplcm8gc3RhdHVzIGJhc2VkIG9uIGEgRENPLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+RWxzZSB0aGUgUlVMIGRyYWZ0IHdpbGwgaGF2ZSB0byB1cGRhdGUg ZWZmaWNpZW50IE5QIERBTywgd2hpY2ggZG9lcyBub3QgbG9vayBhcyBnb29kLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QW55IG9iamVjdGlvbiB0byB0aGlzPzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+UGFzY2FsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgUlBM SW5zdGFuY2VJRCB8S3xEfCZuYnNwOyZuYnNwOyBGbGFncyZuYnNwOyZuYnNwOw0KPHNwYW4gc3R5 bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij58Jm5ic3A7Jm5ic3A7 IFJlc2VydmVkPC9zcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyB8IERDT1NlcXVlbmNlJm5ic3A7Jm5i c3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBET0RBR0lEKG9wdGlvbmFsKSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgT3B0aW9uKHMpLi4uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClJvbGwgbWFpbGluZyBsaXN0PGJyPg0KPC9z cGFuPjxhIGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJvbGxAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClJvbGwgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciPlJvbGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_MN2PR11MB3565A86B9435F35E383885BDD8BD0MN2PR11MB3565namp_-- From nobody Fri Aug 30 06:52:54 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5061201DB for ; Fri, 30 Aug 2019 06:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Al8QB50DHorT for ; Fri, 30 Aug 2019 06:52:48 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 802D412011E for ; Fri, 30 Aug 2019 06:52:47 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id t50so8117488edd.2 for ; Fri, 30 Aug 2019 06:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=fKh9mXRYNRGFASEDeoctfJRJFlN1LY2j8AnwT+w+fjQ=; b=WbdAhAy1a1GV4mIDj7oEDRfvagYFlW7UdlV7EL/gZVMCMCwTQR8MQU4hZ7b4N2g465 8XfofidczAsXANX+TqKCxnZ1FveFOgv512bvWrabLYSQ7JlwIRbkslBv8yKR/c+C3lff Gp7I3W5+3UrTSxFc0XQbc1evX1x+hACHnGGzHbQvZtl+Ju7jiMXfqEIk8PsQKtx90u9o VKD1E8JXnxGSQUabUCy6z/QRt6WpTOOw1Kc1AQDzk8sxEtho6+jMUrF0woCi8rCvxBJU RC6Mroiyac3vXrXrQiVSGLuI+BJ3nFVAQKR7Li6q2swffSofxmNK1VCpvhFuaiqiwnAZ rIBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=fKh9mXRYNRGFASEDeoctfJRJFlN1LY2j8AnwT+w+fjQ=; b=HtR4ML+5fPqfrnEYzy1IXKCGUBJcwBNzgDEneNhTl/sAKu17CDnKKhBBm+hsy4xsA3 //A2B56qFmAxdlnBzrn7u8qoIE6ANbW3XcKSevmQ66qU9cMZMFIgyUdp0b3zV1G5lcnf G+gnr9w+jPe6ulEusDmYd0jvpezVTXNs7hs2dmYx10y3UcqMcbykPipAGVT33yCBemm1 Nvg44o++2kLDdPwYvxNVPF1mz0BpXYNTtrw/1Re2Nrx23Fw5MvqxQqsnH+ACVYxY6RbS ib4SiWHqNAkThBVDPjGX3jQ5vNuO9vJe3aZqqrIFCFXrf1aCYN+A8P1AM+3uSvyW8Bel wdbg== X-Gm-Message-State: APjAAAX6h0XaAzvysKNmcl64nZCuewbZbCku6gP20rcKYifP75JuJEVZ vMWd+0LWKh9Tufx0RLhpFNDpI0LgnUUq9hq0LqlK+MgO X-Google-Smtp-Source: APXvYqx7LmJ6PBshBI5cXKCVyHB2yw/eKjDE92wK4cDJpFKBwjrRN1aq6FE2tgCBhbWqFj3Dm7Pkm4ay2nBaJWfwa1o= X-Received: by 2002:a50:86bb:: with SMTP id r56mr15503331eda.217.1567173166031; Fri, 30 Aug 2019 06:52:46 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 30 Aug 2019 06:52:44 -0700 From: Alvaro Retana In-Reply-To: References: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com> <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> <9ED90E26-9AC9-4FB9-86FF-3FD838CB0E60@cisco.com> <982B626E107E334DBE601D979F31785C5DFBB5B8@BLREML503-MBX.china.huawei.com> MIME-Version: 1.0 Date: Fri, 30 Aug 2019 06:52:44 -0700 Message-ID: To: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks , "consultancy@vanderstok.org" Content-Type: multipart/alternative; boundary="000000000000dce8a6059155efa7" Archived-At: Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 13:52:52 -0000 --000000000000dce8a6059155efa7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi! I haven=E2=80=99t looked at the implications/details=E2=80=A6but, at first = glance, I think we would need more than some changes in the IANA section=E2=80=A6probably a= lso explanations, maybe security considerations on the new field, etc.. The document is currently being Edited by the RFC Editor. The only time we can=E2=80=99t stop the process is once the publication is complete=E2=80=A6= so there is time if that is what we want to do. I think we should pause the process, have the discussion and then go back and see that the effect is. IOW, the discussion may end up in no/minor changes which we could make at this point in the process=E2=80=A6or it could result in bigger changes where some of t= he process may have to be rerun (from WGLC to IETF LC, etc..). Please don=E2= =80=99t let this last part scare anyone away from doing what may be the right thing: even if there is process, it is probably lighter than a brand new document. :-) Unless I hear otherwise in the next few hours, I will ask the RFC Editor to pause editing before my end of day. I realize that no one who has participated in this thread so far is based in the US (my timezone), but the RFC Editor staff is, and Monday is a holiday, so I rather pause now than wait until Tuesday. With any luck this conversation can be settled over the weekend and we=E2=80=99ll be ready to do then. :-) Thanks!! Alvaro. On August 30, 2019 at 4:50:43 AM, Pascal Thubert (pthubert) ( pthubert@cisco.com) wrote: Hum; The term =E2=80=9Cstatus=E2=80=9D may be abused, but it practice it means m= ore than a state. It is more like a return code. RUL uses the =E2=80=9CStatus values=E2=80=9D from 6LoWPAN ND and transports= them on DCO. E.g., the backbone router uses =E2=80=9Cremoved=E2=80=9D to indicate that a= nother BBR now owns the address. In a 6TiSCH network that would mean in another RPL DODAG, so the address in this DODAG needs to be cleaned up. DCO is the way to do that. So the expectation is a DCO with a status code =E2=80=98removed=E2=80=99 as well. The 6lo chairs asked me to remove text on RPL from the BBR so the above is still nuspecified, we=E2=80=99ll do that once the BBR has shipped. If you look at the values in RUL right now they are exactly the sort of thing you=E2=80=99re talking about; current IANA section of RUL has the fol= lowing: +---------+--------------------------------------+----------------+ | Value | Meaning | Defining Spec | +---------+--------------------------------------+----------------+ | 0 | Unqualified acceptance | RFC6550 | | | | | | 1-127 | Reserved for Warning Codes | RFC6550 | | | | | | 128 | Duplicate Address | This RFC | | | | | | 129 | Out of Storage | This RFC | | | | | | 130 | Moved | This RFC | | | | | | 131 | Removed | This RFC | | | | | | 132 | Validation Requested | This RFC | | | | | | 133 | Duplicate Source Address | This RFC | | | | | | 134 | Invalid Source Address | This RFC | | | | | | 135 | Address topologically incorrect | This RFC | | | | | | 136 | 6LBR Registry saturated | This RFC | | | | | | 137 | Validation Failed | This RFC | | | | | | 138-192 | Reserved for 6LoWPAN ND code mapping | This RFC | | | | | | 193-255 | Reserved for other Rejection Codes | RFC6550 | +---------+--------------------------------------+----------------+ All the best, Pascal *From:* Roll *On Behalf Of *Rahul Arvind Jadhav *Sent:* vendredi 30 ao=C3=BBt 2019 10:31 *To:* Routing Over Low power and Lossy networks ; consultancy@vanderstok.org *Subject:* Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao Minimal changes to NPDAO is to change the name =E2=80=9Creserved=E2=80=9D o= f the field in the drawing and add text saying same status field as in RPL DAO ACK. If we really want new status values we may also add them in NPDAO and I=E2= =80=99ll adapt RUL. But there is no absolute need to create the registry in NPDAO. [RJ] The status field values of DAO-ACK/DCO-ACK are not what we require to be sent in DCO=E2=80=A6 What we want is a Reason field and not a Status fie= ld in the DCO.. Hence I believe that there are changes required for IANA. We can take a shortcut and keep the field same as Status, but it seems like a hack to me. Le 30 ao=C3=BBt 2019 =C3=A0 09:30, Peter van der Stok = a =C3=A9crit : Hi Authors, It is a bit late to change the approved draft. It is in IANA editing; and you could write to IANA to apologize for a late addition and see how far they are in the process. BUT, worse, how much text is needed to explain this addition? Adding text to an approved document sounds like opening a can of worms to me. Peter Rahul Arvind Jadhav schreef op 2019-08-30 09:03: The DCO could be initiated for regular route invalidation due to path changes or because of management decision. The status code can help understand the reason for initiating the DCO. I like the idea of this. However, I don=E2=80=99t know, procedurally, what it means to changing the = draft at this stage. The changes to draft would include new IANA considerations for the status field. *From:* Roll [mailto:roll-bounces@ietf.org ] *On Behalf Of *Pascal Thubert (pthubert) *Sent:* 30 August 2019 14:43 *To:* Routing Over Low power and Lossy networks *Subject:* [Roll] suggested addition to draft-ietf-roll-efficient-npdao Dear all ; I know it=E2=80=99s late but I=E2=80=99d suggest an addition to draft-ietf-roll-efficient-npdao. There=E2=80=99s a reserved field in the DC= O. My suggestion is to use it to transport RPL DAO-ACK status values as defined in RFC 6550. This way we can signal the reason of the DCO to the node. This will become significant with the RPL-unaware leaves draft, so we can rebuild a NA(EARO) with a non-zero status based on a DCO. Else the RUL draft will have to update efficient NP DAO, which does not look as good. Any objection to this? Pascal 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |K|D| Flags | Reserved | DCOSequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID(optional) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --000000000000dce8a6059155efa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi!

I haven=E2=80=99t looked at the implications/details=E2=80=A6bu= t, at first glance, I think we would need more than some changes in the IAN= A section=E2=80=A6probably also explanations, maybe security considerations= on the new field, etc..

The document is currently being Edited by the RFC Editor.=C2=A0 The o= nly time we can=E2=80=99t stop the process is once the publication is compl= ete=E2=80=A6so there is time if that is what we want to do.=C2=A0 I think w= e should pause the process, have the discussion and then go back and see th= at the effect is.=C2=A0 IOW, the discussion may end up in no/minor changes = which we could make at this point in the process=E2=80=A6or it could result= in bigger changes where some of the process may have to be rerun (from WGL= C to IETF LC, etc..).=C2=A0 Please don=E2=80=99t let this last part scare a= nyone away from doing what may be the right thing: even if there is process= , it is probably lighter than a brand new document. :-)

Unless I hear otherwise in the next fe= w hours, I will ask the RFC Editor to pause editing before my end of day.= =C2=A0 I realize that no one who has participated in this thread so far is = based in the US (my timezone), but the RFC Editor staff is, and Monday is a= holiday, so I rather pause now than wait until Tuesday.=C2=A0 With any luc= k this conversation can be settled over the weekend and we=E2=80=99ll be re= ady to do then. :-)

Thanks!!
Alvaro.

On August 30, 2019 at 4:50:43 AM, Pascal T= hubert (pthubert) (pthubert@cisco.com= ) wrote:

Hum;

=C2=A0

The term =E2=80=9Cstatus=E2=80=9D may be abused, bu= t it practice it means more than a state. It is more like a return code.

RUL uses the =E2=80=9CStatus values=E2=80=9D from 6= LoWPAN ND and transports them on DCO.

E.g., the backbone router uses =E2=80=9Cremoved=E2= =80=9D to indicate that another BBR now owns the address.

In a 6TiSCH network that would mean in another RPL = DODAG, so the address in this DODAG needs to be cleaned up. DCO is the way = to do that. So the expectation is a DCO with a status code =E2=80=98removed=E2=80=99 as well.

The 6lo chairs asked me to remove text on RPL from = the BBR so the above is still nuspecified, we=E2=80=99ll do that once the B= BR has shipped.

=C2=A0

If you look at the values in RUL right now they are= exactly the sort of thing you=E2=80=99re talking about; current IANA secti= on of RUL has the following:

=C2=A0

=C2=A0=C2=A0=C2=A0 +---------+----------------------------= ----------+----------------+

=C2=A0=C2=A0=C2=A0 |=C2=A0 Value=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Meaning= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | Defining Spec=C2=A0 |

=C2=A0=C2=A0=C2=A0 +---------+----------------------------= ----------+----------------+

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Unqualified acceptance=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 RFC6550=C2=A0=C2= =A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0 1-127=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Reserved for Warning Codes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0 RFC6550=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 128=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Duplicate Address=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0 T= his RFC=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 129=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Out of Storage= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0 This RFC=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 130=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Moved=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 This RFC=C2=A0=C2= =A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 131=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Removed=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0 This RFC=C2=A0=C2=A0=C2=A0 |=

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 132=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Validation Requested=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 This RFC=C2=A0=C2= =A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 133=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Duplicate Source Address=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 This RFC=C2=A0=C2=A0=C2=A0 |<= /p>

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 134=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Invalid Source Address=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 This RFC=C2=A0=C2=A0=C2=A0 = |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 135=C2=A0=C2=A0 |=C2=A0= =C2=A0 Address topologically incorrect=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0 This RFC=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 136=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6LBR Registry saturated=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 This RFC=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 137=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Validation Failed=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Thi= s RFC=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 | 138-192 | Reserved for 6LoWPAN ND cod= e mapping |=C2=A0 =C2=A0=C2=A0This RFC=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 | 193-255 |=C2=A0 Reserved for other Re= jection Codes=C2=A0 |=C2=A0=C2=A0=C2=A0 RFC6550=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0 +---------+----------------------------= ----------+----------------+

=C2=A0

All the best,

=C2=A0

Pascal

=C2=A0

From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Arvind Jadhav
Sent: vendredi 30 ao=C3=BBt 2019 10:31
To: Routing Over Low power and Lossy networks <roll@ietf.org>; consultancy@vanderstok.org
Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-= npdao

=C2=A0

=C2=A0

Minimal changes to NPDAO is to change the name =E2= =80=9Creserved=E2=80=9D of the field in the drawing and add text saying sam= e status field as in RPL DAO ACK.

=C2=A0

If we really want new= status values we may also add them in NPDAO and I=E2=80=99ll adapt RUL. Bu= t there is no absolute need to create the registry in NPDAO.

[RJ] T= he status field values of DAO-ACK/DCO-ACK are not what we require to be sen= t in DCO=E2=80=A6 What we want is a Reason field and not a Status field in the DCO.. Hence I believe that there are changes require= d for IANA. We can take a shortcut and keep the field same as Status, but i= t seems like a hack to me.


Le 30 ao=C3=BBt 2019 =C3=A0 09:30, Peter van der Stok <stokcons@bbhmail.nl> a =C3=A9crit=C2=A0:

Hi Authors,

It is a bit late to change the approved draft.
It is in IANA editing; and you could write to IANA to apologize for a late = addition and see how far they are in the process.
BUT, worse,=C2=A0 how much text is needed to explain this addition?

Adding text to an approved document sounds like opening a can of worms to m= e.

Peter

Rahul Arvind Jadhav schreef op 2019-08-30 09:03:

The DCO could be initiated for regul= ar route invalidation due to path changes or because of management decision= . The status code can help understand the reason for initiating the DCO. I like the idea of this.

=C2=A0

However, I don=E2=80=99t know, proce= durally, what it means to changing the draft at this stage.

=C2=A0

The changes to draft would include n= ew IANA considerations for the status field.

=C2=A0

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: 30 August 2019 14:43
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] suggested addition to draft-ietf-roll-effi= cient-npdao

=C2=A0

Dear all=C2=A0;

=C2=A0

I know it=E2=80=99s late but I=E2=80=99d suggest an addition to dr= aft-ietf-roll-efficient-npdao. There=E2=80=99s a reserved field in the DCO.=

My suggestion is to use it to transport RPL DAO-ACK status values = as defined in RFC 6550. This way we can signal the reason of the DCO to the= node.

This will become significant with the RPL-unaware leaves draft, so= we can rebuild a NA(EARO) with a non-zero status based on a DCO.

=C2=A0

Else the RUL draft will have to update efficient NP DAO, which doe= s not look as good.

=C2=A0

Any objection to this?

=C2=A0

Pascal

=C2=A0

=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3

=C2=A0=C2=A0=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3= 4 5 6 7 8 9 0 1

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 | RPLInstanceID |K|D|=C2=A0=C2=A0 Flags=C2=A0= =C2=A0 |=C2=A0=C2=A0 Reserved=C2=A0=C2=A0= =C2=A0 | DCOSequence=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DODAGID(optional)=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|

=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 +

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Option(s)...

=C2=A0=C2=A0 =C2=A0=C2=A0+-+-+-+-+-+-+-+-+

=C2=A0

=C2=A0

= _______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.o= rg/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org= /mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf= .org/mailman/listinfo/roll
<= /body> --000000000000dce8a6059155efa7-- From nobody Fri Aug 30 07:20:21 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50FB12083C for ; Fri, 30 Aug 2019 07:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=JcAdhUpF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dIfwAtO3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaYht-RbJoSw for ; Fri, 30 Aug 2019 07:20:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8C2120883 for ; Fri, 30 Aug 2019 07:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56711; q=dns/txt; s=iport; t=1567174805; x=1568384405; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cLiPLudH0FnkPfZESi2ZRetKs4RlG85yiIm2ACguseI=; b=JcAdhUpF5tqCbVgd17SnrHvyxKh1+79nfjM7SrUAkWLzPR/RR7vZtX2e j/IkVgcR2FCcb3yCX7UGTnT4JkmJhXBy9fg4Lrft3PiuWW8IPA48FqaX8 n1vti3o9wcVwKgYgquKdkj6lUxwOCEQQLgTtyjrOi6h4+D36YfOSyhRGk I=; IronPort-PHdr: =?us-ascii?q?9a23=3Av+pBfxI1pilBSB2Ox9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAAAKMGld/5tdJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBgRUvJCwDbVYgBAsqCoQXg0cDinSCXIl?= =?us-ascii?q?hjguBQoEQA1AEBgMBAQEMAQEYAQoKAgEBhD8CF4JJIzcGDgIDCAEBBAEBAQI?= =?us-ascii?q?BBgRthS4MhUoBAQEEAQEQER0BASUHBgUBDwIBCA4DBAEBIQEGAwICAh8GCxQ?= =?us-ascii?q?JCAIEDgUigwABgR1NAx0BAgELoToCgTiIEwE9EHOBMoJ8AQEFhRkNC4IWAwY?= =?us-ascii?q?1fwGEf4Z4GIFAP4ERJx+CTD6CGkcBAYEpBBgEBCsWCYJVMoImjDsICoJbhRw?= =?us-ascii?q?kgg2GXo4AQAqCH44Mgk+DfBuBT2OHNo56jyiIP45PAgQCBAUCDgEBBYFmIoF?= =?us-ascii?q?YcBU7KgGCQYFLd4NyhRSFP3KBKYp3ASQHgQQBgSIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,447,1559520000"; d="scan'208,217";a="322062743" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2019 14:20:04 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x7UEK3a2032632 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Aug 2019 14:20:04 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 09:20:01 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 09:20:00 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 30 Aug 2019 09:20:00 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fc9TZTeDoNYgX/0QcdUXYMa228hUZxf1kgU31GiYWzRtjROzOxKKJMbFeQ33EvRROFSqhDjiBNkWW3J/SU15vaJzpWOFfQj+sJM3BWP+a+Z/7GbKMzlc3wBbTY2e2dcnBTKHXSE9J1n5mgPOKmoGPeBNZzOgzTA1Si6LmRSynYA+NVSRAHPAP8LX21RP5BuK3fnpGJQx9QSy6PN+Rt7SHHAM84vwXwFTCsWq4trRtTwwHB9kduW2hOMkyQNJMg3653q2JzQWHJRbW5umIdgr63Rf6TlusOQNqROek6FoxGbE5p4LIoCErDORh5xSHQx5ia/V5Ai0p4h4Qcf0ugvrqw== 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=cLiPLudH0FnkPfZESi2ZRetKs4RlG85yiIm2ACguseI=; b=X9yXuQvTmlSWBuWUGDX6kpi0wwI7r5t+9JVkttrfE+RNbVmBdoLWZa8R58R6GSD1bpm+ZrLqP/G7hSL9HCHZymvVYnV7B1DL/6W2zcrFSnJYa4L0oyULZ2P5MDxIWeuKHAqB7IeUJsmWSk2KZl92jqyOOHPX3mjf+abVamSB4PSmXfVKlsqjAZ+Not/JwdQRRbHwqNXVAtS5oNZ56mcp759PLrg1paF7oZQsrapbGQf7gitWJNIPojxfBVOCGWNNohr2a1a0JfcLNIWF5jGAaHUTdI/OPYQTU6Y6XMu5XNT6QL9cNwkT0QTwrPiJOGZBqpXpE4F2QrYvAPmuhGNHow== 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=cLiPLudH0FnkPfZESi2ZRetKs4RlG85yiIm2ACguseI=; b=dIfwAtO3E+9s997pSKT5zSmUGSyCBM9cJNJjUF4QthoiERZXhId2q+O57E3c8M1/K5wgLPlM+cEW7NKTrlPCjVv/OWOEp7BRi4+A6KAJ13p86uGJqYnDQLJwWqUp/Es7VHnuRK0V2E1NHBXA3gfFi3HWyN7UbYeZk5LQBznvJgA= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4365.namprd11.prod.outlook.com (52.135.38.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Fri, 30 Aug 2019 14:19:59 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.013; Fri, 30 Aug 2019 14:19:59 +0000 From: "Pascal Thubert (pthubert)" To: Alvaro Retana CC: Routing Over Low power and Lossy networks , "consultancy@vanderstok.org" Thread-Topic: [Roll] suggested addition to draft-ietf-roll-efficient-npdao Thread-Index: AdVe/YcA7dtmnImrSGKYwVT3ZLHQqAAAaBpQAAFi+YAAAWbH1AAAv4YAAAAY5oAACyCkAAAA86BC Date: Fri, 30 Aug 2019 14:19:59 +0000 Message-ID: <75A21EDD-A070-4A07-B7E8-F7F2025C6BBC@cisco.com> References: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com> <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> <9ED90E26-9AC9-4FB9-86FF-3FD838CB0E60@cisco.com> <982B626E107E334DBE601D979F31785C5DFBB5B8@BLREML503-MBX.china.huawei.com> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [91.69.164.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2d61a86c-e4df-492e-206a-08d72d5523c9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4365; x-ms-traffictypediagnostic: MN2PR11MB4365: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(346002)(366004)(376002)(199004)(189003)(54906003)(91956017)(316002)(6512007)(66476007)(6306002)(64756008)(236005)(66446008)(66946007)(54896002)(6246003)(76116006)(53946003)(71200400001)(36756003)(6486002)(4326008)(606006)(26005)(476003)(6116002)(486006)(11346002)(3846002)(6916009)(66556008)(446003)(6436002)(102836004)(66066001)(229853002)(2616005)(53546011)(6506007)(25786009)(33656002)(99286004)(5660300002)(8676002)(81156014)(81166006)(966005)(14454004)(66574012)(14444005)(76176011)(71190400001)(8936002)(7736002)(561944003)(186003)(2906002)(53936002)(508600001)(86362001)(256004)(79990200002)(244885003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4365; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8fdJVIA8Qqanbr3T/YnhIqhcN6NkTnRQt3DLw20vwj9Gw0CoAc+2bi3vlXmXs7SN2BwHqXyFPYRnlW12YuOjOcXZEMsnNtpdRCoOs2NSZuoFeWEap/7rI/x1EdBlzu1t9CMHjPtXbITzjxv9rAganfOK99Z08b0yFBo6c0KY0OjAqd7piqwN9rX4Q3P6hEZsXIdiY5gaH7xQVx1s8zIZGiygDZXBd7JPLoSoZPUY7W4A8xlou4a8rE5SlmPwsP4HmotQZecxypFEB7EtDlajNicILLvstHpetJUAm8QeNRQWL4SfvtdB31+Pj6ZJrBB78OS91xRPNUDyw0S+fRDsNneD7lDi36h0IYQmion7t3OjDDLA6bCHW8ZWlJ/Ev7HevDu62rPP0HdZ7zaA6hNeDHBJrTO10PFQvlfN7m4/RWwdImjlESgEUDEhgByN0F3j5XRQn537aXvhfu+kSArvYA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_75A21EDDA0704A07B7E8F7F2025C6BBCciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2d61a86c-e4df-492e-206a-08d72d5523c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 14:19:59.1368 (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: n8CrrCmROPzfdaoSRhUe3ZHy7BePPvZgUgb0PoXViThM6uullaxllE/m+6Slu28XcPhgYkJIl2N72+ohBZoWrw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4365 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 14:20:19 -0000 --_000_75A21EDDA0704A07B7E8F7F2025C6BBCciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWx2YXJvDQoNClRoZSBwcm9wb3NhbCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGJlaGF2aW9y IG9mIHRoZSBOUERBTyBidXQgYWRkcyBpbmZvcm1hdGlvbiBhYm91dCB3aHkgdGhlIE5QREFPIGlz IHNlbnQuIEFyZSB5b3UgY29uY2VybmVkIGJ5IGF0dGFja3MgbGlrZSBhIGNvdmVyIGNoYW5uZWw/ IFdlIGNvdWxkIGhhdmUgb25lIHNlbnRlbmNlIG9uIHRoYXQgYnV0IEnigJltIHVuY2xlYXIgaG93 IHRvIHByb3RlY3QgYWdhaW5zdCBpdC4NCg0KSW4gdGhlIGZ1dHVyZSBzdGF0dXMgdmFsdWVzIHRo YXQgbW9kaWZ5IHRoZSBiZWhhdmlvciBvZiBOUERBTyBtYXkgYmUgaW50cm9kdWNlZC4gQnV0IGZv ciBub3cgd2XigJlkIGJlIGxvb2tpbmcgYXQgYSB2ZXJ5IG1pbmltYWxpc3RpYyBjaGFuZ2Ugd2hl cmUgdGhlIHJlc2VydmVkIGZpZWxkIGNhcnJpZXMgYSBSUEwgc3RhdHVzIHRoYXQgZG9lcyBub3Qg YWZmZWN0IHRoZSBiZWhhdmlvciBvZiB0aGUgbm9kZXMuDQpUaGUgaG9wZSB3b3VsZCBiZSB0aGF0 IGl0IGRvZXMgbm90IGFmZmVjdCB0aGUgcmV2aWV3cyB0aGF0IHdlcmUgYWxyZWFkeSBkb25lLg0K DQoNClJlZ2FyZHMsDQoNClBhc2NhbA0KDQpMZSAzMCBhb8O7dCAyMDE5IMOgIDE1OjUzLCBBbHZh cm8gUmV0YW5hIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPG1haWx0bzphcmV0YW5hLmlldGZAZ21h aWwuY29tPj4gYSDDqWNyaXQgOg0KDQpIaSENCg0KSSBoYXZlbuKAmXQgbG9va2VkIGF0IHRoZSBp bXBsaWNhdGlvbnMvZGV0YWlsc+KApmJ1dCwgYXQgZmlyc3QgZ2xhbmNlLCBJIHRoaW5rIHdlIHdv dWxkIG5lZWQgbW9yZSB0aGFuIHNvbWUgY2hhbmdlcyBpbiB0aGUgSUFOQSBzZWN0aW9u4oCmcHJv YmFibHkgYWxzbyBleHBsYW5hdGlvbnMsIG1heWJlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9u IHRoZSBuZXcgZmllbGQsIGV0Yy4uDQoNClRoZSBkb2N1bWVudCBpcyBjdXJyZW50bHkgYmVpbmcg RWRpdGVkIGJ5IHRoZSBSRkMgRWRpdG9yLiAgVGhlIG9ubHkgdGltZSB3ZSBjYW7igJl0IHN0b3Ag dGhlIHByb2Nlc3MgaXMgb25jZSB0aGUgcHVibGljYXRpb24gaXMgY29tcGxldGXigKZzbyB0aGVy ZSBpcyB0aW1lIGlmIHRoYXQgaXMgd2hhdCB3ZSB3YW50IHRvIGRvLiAgSSB0aGluayB3ZSBzaG91 bGQgcGF1c2UgdGhlIHByb2Nlc3MsIGhhdmUgdGhlIGRpc2N1c3Npb24gYW5kIHRoZW4gZ28gYmFj ayBhbmQgc2VlIHRoYXQgdGhlIGVmZmVjdCBpcy4gIElPVywgdGhlIGRpc2N1c3Npb24gbWF5IGVu ZCB1cCBpbiBuby9taW5vciBjaGFuZ2VzIHdoaWNoIHdlIGNvdWxkIG1ha2UgYXQgdGhpcyBwb2lu dCBpbiB0aGUgcHJvY2Vzc+KApm9yIGl0IGNvdWxkIHJlc3VsdCBpbiBiaWdnZXIgY2hhbmdlcyB3 aGVyZSBzb21lIG9mIHRoZSBwcm9jZXNzIG1heSBoYXZlIHRvIGJlIHJlcnVuIChmcm9tIFdHTEMg dG8gSUVURiBMQywgZXRjLi4pLiAgUGxlYXNlIGRvbuKAmXQgbGV0IHRoaXMgbGFzdCBwYXJ0IHNj YXJlIGFueW9uZSBhd2F5IGZyb20gZG9pbmcgd2hhdCBtYXkgYmUgdGhlIHJpZ2h0IHRoaW5nOiBl dmVuIGlmIHRoZXJlIGlzIHByb2Nlc3MsIGl0IGlzIHByb2JhYmx5IGxpZ2h0ZXIgdGhhbiBhIGJy YW5kIG5ldyBkb2N1bWVudC4gOi0pDQoNClVubGVzcyBJIGhlYXIgb3RoZXJ3aXNlIGluIHRoZSBu ZXh0IGZldyBob3VycywgSSB3aWxsIGFzayB0aGUgUkZDIEVkaXRvciB0byBwYXVzZSBlZGl0aW5n IGJlZm9yZSBteSBlbmQgb2YgZGF5LiAgSSByZWFsaXplIHRoYXQgbm8gb25lIHdobyBoYXMgcGFy dGljaXBhdGVkIGluIHRoaXMgdGhyZWFkIHNvIGZhciBpcyBiYXNlZCBpbiB0aGUgVVMgKG15IHRp bWV6b25lKSwgYnV0IHRoZSBSRkMgRWRpdG9yIHN0YWZmIGlzLCBhbmQgTW9uZGF5IGlzIGEgaG9s aWRheSwgc28gSSByYXRoZXIgcGF1c2Ugbm93IHRoYW4gd2FpdCB1bnRpbCBUdWVzZGF5LiAgV2l0 aCBhbnkgbHVjayB0aGlzIGNvbnZlcnNhdGlvbiBjYW4gYmUgc2V0dGxlZCBvdmVyIHRoZSB3ZWVr ZW5kIGFuZCB3ZeKAmWxsIGJlIHJlYWR5IHRvIGRvIHRoZW4uIDotKQ0KDQpUaGFua3MhIQ0KDQpB bHZhcm8uDQoNCg0KT24gQXVndXN0IDMwLCAyMDE5IGF0IDQ6NTA6NDMgQU0sIFBhc2NhbCBUaHVi ZXJ0IChwdGh1YmVydCkgKHB0aHViZXJ0QGNpc2NvLmNvbTxtYWlsdG86cHRodWJlcnRAY2lzY28u Y29tPikgd3JvdGU6DQpIdW07DQoNClRoZSB0ZXJtIOKAnHN0YXR1c+KAnSBtYXkgYmUgYWJ1c2Vk LCBidXQgaXQgcHJhY3RpY2UgaXQgbWVhbnMgbW9yZSB0aGFuIGEgc3RhdGUuIEl0IGlzIG1vcmUg bGlrZSBhIHJldHVybiBjb2RlLg0KUlVMIHVzZXMgdGhlIOKAnFN0YXR1cyB2YWx1ZXPigJ0gZnJv bSA2TG9XUEFOIE5EIGFuZCB0cmFuc3BvcnRzIHRoZW0gb24gRENPLg0KRS5nLiwgdGhlIGJhY2ti b25lIHJvdXRlciB1c2VzIOKAnHJlbW92ZWTigJ0gdG8gaW5kaWNhdGUgdGhhdCBhbm90aGVyIEJC UiBub3cgb3ducyB0aGUgYWRkcmVzcy4NCkluIGEgNlRpU0NIIG5ldHdvcmsgdGhhdCB3b3VsZCBt ZWFuIGluIGFub3RoZXIgUlBMIERPREFHLCBzbyB0aGUgYWRkcmVzcyBpbiB0aGlzIERPREFHIG5l ZWRzIHRvIGJlIGNsZWFuZWQgdXAuIERDTyBpcyB0aGUgd2F5IHRvIGRvIHRoYXQuIFNvIHRoZSBl eHBlY3RhdGlvbiBpcyBhIERDTyB3aXRoIGEgc3RhdHVzIGNvZGUg4oCYcmVtb3ZlZOKAmSBhcyB3 ZWxsLg0KVGhlIDZsbyBjaGFpcnMgYXNrZWQgbWUgdG8gcmVtb3ZlIHRleHQgb24gUlBMIGZyb20g dGhlIEJCUiBzbyB0aGUgYWJvdmUgaXMgc3RpbGwgbnVzcGVjaWZpZWQsIHdl4oCZbGwgZG8gdGhh dCBvbmNlIHRoZSBCQlIgaGFzIHNoaXBwZWQuDQoNCklmIHlvdSBsb29rIGF0IHRoZSB2YWx1ZXMg aW4gUlVMIHJpZ2h0IG5vdyB0aGV5IGFyZSBleGFjdGx5IHRoZSBzb3J0IG9mIHRoaW5nIHlvdeKA mXJlIHRhbGtpbmcgYWJvdXQ7IGN1cnJlbnQgSUFOQSBzZWN0aW9uIG9mIFJVTCBoYXMgdGhlIGZv bGxvd2luZzoNCg0KICAgICstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsNCiAgICB8ICBWYWx1ZSAgfCAgICAgICAgICAgICAg IE1lYW5pbmcgICAgICAgICAgICAgICAgfCBEZWZpbmluZyBTcGVjICB8DQogICAgKy0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t Kw0KICAgIHwgICAgMCAgICB8ICAgICAgICBVbnF1YWxpZmllZCBhY2NlcHRhbmNlICAgICAgICB8 ICAgIFJGQzY1NTAgICAgIHwNCiAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogICAgfCAgMS0xMjcgIHwgICAgICBS ZXNlcnZlZCBmb3IgV2FybmluZyBDb2RlcyAgICAgIHwgICAgUkZDNjU1MCAgICAgfA0KICAgIHwg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgIHwNCiAgICB8ICAgMTI4ICAgfCAgICAgICAgICBEdXBsaWNhdGUgQWRkcmVzcyAgICAg ICAgICAgfCAgICBUaGlzIFJGQyAgICB8DQogICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KICAgIHwgICAxMjkgICB8 ICAgICAgICAgICAgT3V0IG9mIFN0b3JhZ2UgICAgICAgICAgICB8ICAgIFRoaXMgUkZDICAgIHwN CiAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICB8DQogICAgfCAgIDEzMCAgIHwgICAgICAgICAgICAgICAgTW92ZWQgICAg ICAgICAgICAgICAgIHwgICAgVGhpcyBSRkMgICAgfA0KICAgIHwgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICB8ICAg MTMxICAgfCAgICAgICAgICAgICAgIFJlbW92ZWQgICAgICAgICAgICAgICAgfCAgICBUaGlzIFJG QyAgICB8DQogICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgfA0KICAgIHwgICAxMzIgICB8ICAgICAgICAgVmFsaWRhdGlv biBSZXF1ZXN0ZWQgICAgICAgICB8ICAgIFRoaXMgUkZDICAgIHwNCiAgICB8ICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQog ICAgfCAgIDEzMyAgIHwgICAgICAgRHVwbGljYXRlIFNvdXJjZSBBZGRyZXNzICAgICAgIHwgICAg VGhpcyBSRkMgICAgfA0KICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICB8ICAgMTM0ICAgfCAgICAgICAgSW52 YWxpZCBTb3VyY2UgQWRkcmVzcyAgICAgICAgfCAgICBUaGlzIFJGQyAgICB8DQogICAgfCAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgfA0KICAgIHwgICAxMzUgICB8ICAgQWRkcmVzcyB0b3BvbG9naWNhbGx5IGluY29ycmVjdCAg ICB8ICAgIFRoaXMgUkZDICAgIHwNCiAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogICAgfCAgIDEzNiAgIHwgICAg ICAgNkxCUiBSZWdpc3RyeSBzYXR1cmF0ZWQgICAgICAgIHwgICAgVGhpcyBSRkMgICAgfA0KICAg IHwgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgIHwNCiAgICB8ICAgMTM3ICAgfCAgICAgICAgICBWYWxpZGF0aW9uIEZhaWxlZCAg ICAgICAgICAgfCAgICBUaGlzIFJGQyAgICB8DQogICAgfCAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KICAgIHwgMTM4LTE5 MiB8IFJlc2VydmVkIGZvciA2TG9XUEFOIE5EIGNvZGUgbWFwcGluZyB8ICAgIFRoaXMgUkZDICAg IHwNCiAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICB8DQogICAgfCAxOTMtMjU1IHwgIFJlc2VydmVkIGZvciBvdGhlciBS ZWplY3Rpb24gQ29kZXMgIHwgICAgUkZDNjU1MCAgICAgfA0KICAgICstLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsNCg0KQWxs IHRoZSBiZXN0LA0KDQpQYXNjYWwNCg0KRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgUmFodWwgQXJ2aW5k IEphZGhhdg0KU2VudDogdmVuZHJlZGkgMzAgYW/Du3QgMjAxOSAxMDozMQ0KVG86IFJvdXRpbmcg T3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPG1haWx0bzpy b2xsQGlldGYub3JnPj47IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPG1haWx0bzpjb25zdWx0 YW5jeUB2YW5kZXJzdG9rLm9yZz4NClN1YmplY3Q6IFJlOiBbUm9sbF0gc3VnZ2VzdGVkIGFkZGl0 aW9uIHRvIGRyYWZ0LWlldGYtcm9sbC1lZmZpY2llbnQtbnBkYW8NCg0KDQpNaW5pbWFsIGNoYW5n ZXMgdG8gTlBEQU8gaXMgdG8gY2hhbmdlIHRoZSBuYW1lIOKAnHJlc2VydmVk4oCdIG9mIHRoZSBm aWVsZCBpbiB0aGUgZHJhd2luZyBhbmQgYWRkIHRleHQgc2F5aW5nIHNhbWUgc3RhdHVzIGZpZWxk IGFzIGluIFJQTCBEQU8gQUNLLg0KDQpJZiB3ZSByZWFsbHkgd2FudCBuZXcgc3RhdHVzIHZhbHVl cyB3ZSBtYXkgYWxzbyBhZGQgdGhlbSBpbiBOUERBTyBhbmQgSeKAmWxsIGFkYXB0IFJVTC4gQnV0 IHRoZXJlIGlzIG5vIGFic29sdXRlIG5lZWQgdG8gY3JlYXRlIHRoZSByZWdpc3RyeSBpbiBOUERB Ty4NCltSSl0gVGhlIHN0YXR1cyBmaWVsZCB2YWx1ZXMgb2YgREFPLUFDSy9EQ08tQUNLIGFyZSBu b3Qgd2hhdCB3ZSByZXF1aXJlIHRvIGJlIHNlbnQgaW4gRENP4oCmIFdoYXQgd2Ugd2FudCBpcyBh IFJlYXNvbiBmaWVsZCBhbmQgbm90IGEgU3RhdHVzIGZpZWxkIGluIHRoZSBEQ08uLiBIZW5jZSBJ IGJlbGlldmUgdGhhdCB0aGVyZSBhcmUgY2hhbmdlcyByZXF1aXJlZCBmb3IgSUFOQS4gV2UgY2Fu IHRha2UgYSBzaG9ydGN1dCBhbmQga2VlcCB0aGUgZmllbGQgc2FtZSBhcyBTdGF0dXMsIGJ1dCBp dCBzZWVtcyBsaWtlIGEgaGFjayB0byBtZS4NCg0KTGUgMzAgYW/Du3QgMjAxOSDDoCAwOTozMCwg UGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0BiYmhtYWlsLm5sPG1haWx0bzpzdG9rY29uc0Bi YmhtYWlsLm5sPj4gYSDDqWNyaXQgOg0KSGkgQXV0aG9ycywNCg0KSXQgaXMgYSBiaXQgbGF0ZSB0 byBjaGFuZ2UgdGhlIGFwcHJvdmVkIGRyYWZ0Lg0KSXQgaXMgaW4gSUFOQSBlZGl0aW5nOyBhbmQg eW91IGNvdWxkIHdyaXRlIHRvIElBTkEgdG8gYXBvbG9naXplIGZvciBhIGxhdGUgYWRkaXRpb24g YW5kIHNlZSBob3cgZmFyIHRoZXkgYXJlIGluIHRoZSBwcm9jZXNzLg0KQlVULCB3b3JzZSwgIGhv dyBtdWNoIHRleHQgaXMgbmVlZGVkIHRvIGV4cGxhaW4gdGhpcyBhZGRpdGlvbj8NCg0KQWRkaW5n IHRleHQgdG8gYW4gYXBwcm92ZWQgZG9jdW1lbnQgc291bmRzIGxpa2Ugb3BlbmluZyBhIGNhbiBv ZiB3b3JtcyB0byBtZS4NCg0KUGV0ZXINCg0KUmFodWwgQXJ2aW5kIEphZGhhdiBzY2hyZWVmIG9w IDIwMTktMDgtMzAgMDk6MDM6DQpUaGUgRENPIGNvdWxkIGJlIGluaXRpYXRlZCBmb3IgcmVndWxh ciByb3V0ZSBpbnZhbGlkYXRpb24gZHVlIHRvIHBhdGggY2hhbmdlcyBvciBiZWNhdXNlIG9mIG1h bmFnZW1lbnQgZGVjaXNpb24uIFRoZSBzdGF0dXMgY29kZSBjYW4gaGVscCB1bmRlcnN0YW5kIHRo ZSByZWFzb24gZm9yIGluaXRpYXRpbmcgdGhlIERDTy4gSSBsaWtlIHRoZSBpZGVhIG9mIHRoaXMu DQoNCkhvd2V2ZXIsIEkgZG9u4oCZdCBrbm93LCBwcm9jZWR1cmFsbHksIHdoYXQgaXQgbWVhbnMg dG8gY2hhbmdpbmcgdGhlIGRyYWZ0IGF0IHRoaXMgc3RhZ2UuDQoNClRoZSBjaGFuZ2VzIHRvIGRy YWZ0IHdvdWxkIGluY2x1ZGUgbmV3IElBTkEgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBzdGF0dXMg ZmllbGQuDQoNCkZyb206IFJvbGwgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpTZW50OiAzMCBBdWd1c3QgMjAxOSAx NDo0Mw0KVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xs QGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPj4NClN1YmplY3Q6IFtSb2xsXSBzdWdnZXN0 ZWQgYWRkaXRpb24gdG8gZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbw0KDQpEZWFyIGFs bCA7DQoNCkkga25vdyBpdOKAmXMgbGF0ZSBidXQgSeKAmWQgc3VnZ2VzdCBhbiBhZGRpdGlvbiB0 byBkcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvLiBUaGVyZeKAmXMgYSByZXNlcnZlZCBm aWVsZCBpbiB0aGUgRENPLg0KTXkgc3VnZ2VzdGlvbiBpcyB0byB1c2UgaXQgdG8gdHJhbnNwb3J0 IFJQTCBEQU8tQUNLIHN0YXR1cyB2YWx1ZXMgYXMgZGVmaW5lZCBpbiBSRkMgNjU1MC4gVGhpcyB3 YXkgd2UgY2FuIHNpZ25hbCB0aGUgcmVhc29uIG9mIHRoZSBEQ08gdG8gdGhlIG5vZGUuDQpUaGlz IHdpbGwgYmVjb21lIHNpZ25pZmljYW50IHdpdGggdGhlIFJQTC11bmF3YXJlIGxlYXZlcyBkcmFm dCwgc28gd2UgY2FuIHJlYnVpbGQgYSBOQShFQVJPKSB3aXRoIGEgbm9uLXplcm8gc3RhdHVzIGJh c2VkIG9uIGEgRENPLg0KDQpFbHNlIHRoZSBSVUwgZHJhZnQgd2lsbCBoYXZlIHRvIHVwZGF0ZSBl ZmZpY2llbnQgTlAgREFPLCB3aGljaCBkb2VzIG5vdCBsb29rIGFzIGdvb2QuDQoNCkFueSBvYmpl Y3Rpb24gdG8gdGhpcz8NCg0KUGFzY2FsDQoNCiAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAg ICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgIHwgUlBMSW5zdGFuY2VJRCB8S3xEfCAgIEZsYWdzICAgfCAgIFJlc2VydmVk ICAgIHwgRENPU2VxdWVuY2UgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICArDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRE9EQUdJRChvcHRpb25hbCkgICAgICAgICAgICAgICAgICArDQogICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICBPcHRp b24ocykuLi4NCiAgICAgKy0rLSstKy0rLSstKy0rLSsNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0 Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3JvbGwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZzxtYWlsdG86Um9sbEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBs aXN0DQpSb2xsQGlldGYub3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= --_000_75A21EDDA0704A07B7E8F7F2025C6BBCciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI ZWxsbyBBbHZhcm8NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBwcm9wb3NhbCBkb2VzIG5v dCBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9mIHRoZSBOUERBTyBidXQgYWRkcyBpbmZvcm1hdGlvbiBh Ym91dCB3aHkgdGhlIE5QREFPIGlzIHNlbnQuIEFyZSB5b3UgY29uY2VybmVkIGJ5IGF0dGFja3Mg bGlrZSBhIGNvdmVyIGNoYW5uZWw/IFdlIGNvdWxkIGhhdmUgb25lIHNlbnRlbmNlIG9uIHRoYXQg YnV0IEnigJltIHVuY2xlYXIgaG93IHRvIHByb3RlY3QgYWdhaW5zdCBpdC48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkluIHRoZSBmdXR1cmUgc3RhdHVzIHZhbHVlcyB0aGF0IG1vZGlm eSB0aGUgYmVoYXZpb3Igb2YgTlBEQU8gbWF5IGJlIGludHJvZHVjZWQuIEJ1dCBmb3Igbm93IHdl 4oCZZCBiZSBsb29raW5nIGF0IGEgdmVyeSBtaW5pbWFsaXN0aWMgY2hhbmdlIHdoZXJlIHRoZSBy ZXNlcnZlZCBmaWVsZCBjYXJyaWVzIGEgUlBMIHN0YXR1cyB0aGF0IGRvZXMgbm90IGFmZmVjdCB0 aGUgYmVoYXZpb3Igb2YgdGhlIG5vZGVzLjwvZGl2Pg0KPGRpdj5UaGUgaG9wZSB3b3VsZCBiZSB0 aGF0IGl0IGRvZXMgbm90IGFmZmVjdCB0aGUgcmV2aWV3cyB0aGF0IHdlcmUgYWxyZWFkeSBkb25l LjwvZGl2Pg0KPGRpdj48YnI+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiIGRpcj0ibHRy Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQpSZWdhcmRzLA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ UGFzY2FsPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCkxlIDMwIGFvw7t0IDIw MTkgw6AgMTU6NTMsIEFsdmFybyBSZXRhbmEgJmx0OzxhIGhyZWY9Im1haWx0bzphcmV0YW5hLmll dGZAZ21haWwuY29tIj5hcmV0YW5hLmlldGZAZ21haWwuY29tPC9hPiZndDsgYSDDqWNyaXQmbmJz cDs6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGly PSJsdHIiPjxzdHlsZT5ib2R5e2ZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6 MTNweH08L3N0eWxlPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2Zv bnQtc2l6ZToxM3B4Ij5IaSE8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGlj YSxBcmlhbDtmb250LXNpemU6MTNweCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHgiPkkgaGF2ZW7igJl0IGxvb2tlZCBh dCB0aGUgaW1wbGljYXRpb25zL2RldGFpbHPigKZidXQsIGF0IGZpcnN0IGdsYW5jZSwgSSB0aGlu ayB3ZSB3b3VsZCBuZWVkIG1vcmUgdGhhbiBzb21lIGNoYW5nZXMgaW4gdGhlIElBTkEgc2VjdGlv buKApnByb2JhYmx5IGFsc28gZXhwbGFuYXRpb25zLCBtYXliZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBvbiB0aGUgbmV3DQogZmllbGQsIGV0Yy4uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1zaXplOjEzcHgiPjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij5UaGUgZG9j dW1lbnQgaXMgY3VycmVudGx5IGJlaW5nIEVkaXRlZCBieSB0aGUgUkZDIEVkaXRvci4mbmJzcDsg VGhlIG9ubHkgdGltZSB3ZSBjYW7igJl0IHN0b3AgdGhlIHByb2Nlc3MgaXMgb25jZSB0aGUgcHVi bGljYXRpb24gaXMgY29tcGxldGXigKZzbyB0aGVyZSBpcyB0aW1lIGlmIHRoYXQgaXMgd2hhdCB3 ZSB3YW50IHRvIGRvLiZuYnNwOyBJIHRoaW5rIHdlIHNob3VsZA0KIHBhdXNlIHRoZSBwcm9jZXNz LCBoYXZlIHRoZSBkaXNjdXNzaW9uIGFuZCB0aGVuIGdvIGJhY2sgYW5kIHNlZSB0aGF0IHRoZSBl ZmZlY3QgaXMuJm5ic3A7IElPVywgdGhlIGRpc2N1c3Npb24gbWF5IGVuZCB1cCBpbiBuby9taW5v ciBjaGFuZ2VzIHdoaWNoIHdlIGNvdWxkIG1ha2UgYXQgdGhpcyBwb2ludCBpbiB0aGUgcHJvY2Vz c+KApm9yIGl0IGNvdWxkIHJlc3VsdCBpbiBiaWdnZXIgY2hhbmdlcyB3aGVyZSBzb21lIG9mIHRo ZSBwcm9jZXNzIG1heSBoYXZlDQogdG8gYmUgcmVydW4gKGZyb20gV0dMQyB0byBJRVRGIExDLCBl dGMuLikuJm5ic3A7IFBsZWFzZSBkb27igJl0IGxldCB0aGlzIGxhc3QgcGFydCBzY2FyZSBhbnlv bmUgYXdheSBmcm9tIGRvaW5nIHdoYXQgbWF5IGJlIHRoZSByaWdodCB0aGluZzogZXZlbiBpZiB0 aGVyZSBpcyBwcm9jZXNzLCBpdCBpcyBwcm9iYWJseSBsaWdodGVyIHRoYW4gYSBicmFuZCBuZXcg ZG9jdW1lbnQuIDotKTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFy aWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNweCI+VW5sZXNzIEkgaGVhciBvdGhlcndpc2Ug aW4gdGhlIG5leHQgZmV3IGhvdXJzLCBJIHdpbGwgYXNrIHRoZSBSRkMgRWRpdG9yIHRvIHBhdXNl IGVkaXRpbmcgYmVmb3JlIG15IGVuZCBvZiBkYXkuJm5ic3A7IEkgcmVhbGl6ZSB0aGF0IG5vIG9u ZSB3aG8gaGFzIHBhcnRpY2lwYXRlZCBpbiB0aGlzIHRocmVhZCBzbyBmYXIgaXMgYmFzZWQgaW4g dGhlIFVTIChteQ0KIHRpbWV6b25lKSwgYnV0IHRoZSBSRkMgRWRpdG9yIHN0YWZmIGlzLCBhbmQg TW9uZGF5IGlzIGEgaG9saWRheSwgc28gSSByYXRoZXIgcGF1c2Ugbm93IHRoYW4gd2FpdCB1bnRp bCBUdWVzZGF5LiZuYnNwOyBXaXRoIGFueSBsdWNrIHRoaXMgY29udmVyc2F0aW9uIGNhbiBiZSBz ZXR0bGVkIG92ZXIgdGhlIHdlZWtlbmQgYW5kIHdl4oCZbGwgYmUgcmVhZHkgdG8gZG8gdGhlbi4g Oi0pPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWw7Zm9udC1z aXplOjEzcHgiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNh LEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij5UaGFua3MhITwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6SGVsdmV0aWNhLEFyaWFsO2ZvbnQtc2l6ZToxM3B4Ij48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDtmb250LXNpemU6MTNweCI+QWx2YXJv LjwvZGl2Pg0KPGJyPg0KPHAgY2xhc3M9ImFpcm1haWxfb24iPk9uIEF1Z3VzdCAzMCwgMjAxOSBh dCA0OjUwOjQzIEFNLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICg8YSBocmVmPSJtYWlsdG86 cHRodWJlcnRAY2lzY28uY29tIj5wdGh1YmVydEBjaXNjby5jb208L2E+KSB3cm90ZTo8L3A+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iY2xlYW5fYnEiPjxzcGFuPg0KPGRpdiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkh1bTs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaGUgdGVybSDigJxzdGF0dXPigJ0gbWF5IGJlIGFidXNlZCwgYnV0IGl0IHByYWN0 aWNlIGl0IG1lYW5zIG1vcmUgdGhhbiBhIHN0YXRlLiBJdCBpcyBtb3JlIGxpa2UgYSByZXR1cm4g Y29kZS4NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlJVTCB1c2VzIHRoZSDigJxTdGF0dXMgdmFsdWVz4oCdIGZyb20gNkxvV1BBTiBORCBhbmQgdHJh bnNwb3J0cyB0aGVtIG9uIERDTy4NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkUuZy4sIHRoZSBiYWNrYm9uZSByb3V0ZXIgdXNlcyDigJxyZW1vdmVk 4oCdIHRvIGluZGljYXRlIHRoYXQgYW5vdGhlciBCQlIgbm93IG93bnMgdGhlIGFkZHJlc3MuPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SW4gYSA2VGlT Q0ggbmV0d29yayB0aGF0IHdvdWxkIG1lYW4gaW4gYW5vdGhlciBSUEwgRE9EQUcsIHNvIHRoZSBh ZGRyZXNzIGluIHRoaXMgRE9EQUcgbmVlZHMgdG8gYmUgY2xlYW5lZCB1cC4gRENPIGlzIHRoZSB3 YXkgdG8gZG8gdGhhdC4gU28gdGhlIGV4cGVjdGF0aW9uIGlzIGEgRENPIHdpdGggYQ0KIHN0YXR1 cyBjb2RlIOKAmHJlbW92ZWTigJkgYXMgd2VsbC48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgNmxvIGNoYWlycyBhc2tlZCBtZSB0byByZW1vdmUg dGV4dCBvbiBSUEwgZnJvbSB0aGUgQkJSIHNvIHRoZSBhYm92ZSBpcyBzdGlsbCBudXNwZWNpZmll ZCwgd2XigJlsbCBkbyB0aGF0IG9uY2UgdGhlIEJCUiBoYXMgc2hpcHBlZC48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZiB5b3UgbG9vayBhdCB0aGUg dmFsdWVzIGluIFJVTCByaWdodCBub3cgdGhleSBhcmUgZXhhY3RseSB0aGUgc29ydCBvZiB0aGlu ZyB5b3XigJlyZSB0YWxraW5nIGFib3V0OyBjdXJyZW50IElBTkEgc2VjdGlvbiBvZiBSVUwgaGFz IHRoZSBmb2xsb3dpbmc6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7IFZhbHVlJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTWVhbmluZyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IERlZmluaW5nIFNwZWMmbmJzcDsgfDwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyAwJm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVW5xdWFsaWZpZWQgYWNjZXB0YW5jZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJGQzY1NTAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IDEtMTI3 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzZXJ2ZWQgZm9yIFdhcm5p bmcgQ29kZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyBSRkM2NTUwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAxMjgmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEdXBsaWNhdGUgQWRk cmVzcyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgUkZDJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAxMjkmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBPdXQgb2YgU3RvcmFnZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoaXMgUkZDJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAxMzAmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNb3ZlZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgUkZDJm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyAxMzEm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZW1vdmVkJm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBSRkMmbmJz cDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7IDEzMiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZhbGlkYXRpb24gUmVxdWVzdGVkJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBS RkMmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7IDEzMyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IER1cGxpY2F0ZSBTb3VyY2UgQWRkcmVzcyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgUkZDJm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyAxMzQmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJbnZhbGlkIFNvdXJjZSBBZGRyZXNzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBSRkMmbmJzcDsmbmJzcDsmbmJz cDsgfDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IDEz NSZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IEFkZHJlc3MgdG9wb2xvZ2ljYWxseSBpbmNvcnJl Y3QmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIFJGQyZuYnNwOyZu YnNwOyZuYnNwOyB8PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsgMTM2Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgNkxCUiBSZWdpc3RyeSBzYXR1cmF0ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIFJGQyZuYnNwOyZuYnNwOyZuYnNw OyB8PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgMTM3 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVmFsaWRhdGlvbiBGYWlsZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBUaGlz IFJGQyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwgMTM4LTE5MiB8IFJlc2VydmVkIGZvciA2TG9XUEFOIE5EIGNvZGUgbWFwcGluZyB8Jm5i c3A7ICZuYnNwOyZuYnNwO1RoaXMgUkZDJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCAxOTMtMjU1IHwmbmJzcDsgUmVzZXJ2ZWQgZm9yIG90 aGVyIFJlamVjdGlvbiBDb2RlcyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJGQzY1NTAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFs bCB0aGUgYmVzdCw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5QYXNjYWw8L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI2UxZTFlMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvbGwg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmciPnJvbGwtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJhaHVsIEFydmluZCBKYWRoYXY8 YnI+DQo8Yj5TZW50OjwvYj4gdmVuZHJlZGkgMzAgYW/Du3QgMjAxOSAxMDozMTxicj4NCjxiPlRv OjwvYj4gUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgJmx0OzxhIGhy ZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYub3JnPC9hPiZndDs7DQo8YSBocmVm PSJtYWlsdG86Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmciPmNvbnN1bHRhbmN5QHZhbmRlcnN0 b2sub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1JvbGxdIHN1Z2dlc3RlZCBhZGRp dGlvbiB0byBkcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5wZGFvPC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWluaW1hbCBj aGFuZ2VzIHRvIE5QREFPIGlzIHRvIGNoYW5nZSB0aGUgbmFtZSDigJxyZXNlcnZlZOKAnSBvZiB0 aGUgZmllbGQgaW4gdGhlIGRyYXdpbmcgYW5kIGFkZCB0ZXh0IHNheWluZyBzYW1lIHN0YXR1cyBm aWVsZCBhcyBpbiBSUEwgREFPIEFDSy48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPklmIHdlIHJlYWxseSB3YW50IG5ldyBzdGF0dXMg dmFsdWVzIHdlIG1heSBhbHNvIGFkZCB0aGVtIGluIE5QREFPIGFuZCBJ4oCZbGwgYWRhcHQgUlVM LiBCdXQgdGhlcmUgaXMgbm8gYWJzb2x1dGUgbmVlZCB0byBjcmVhdGUgdGhlIHJlZ2lzdHJ5IGlu IE5QREFPLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiPltSSl0gVGhlIHN0YXR1cyBmaWVs ZCB2YWx1ZXMgb2YgREFPLUFDSy9EQ08tQUNLIGFyZSBub3Qgd2hhdCB3ZSByZXF1aXJlIHRvIGJl IHNlbnQgaW4gRENP4oCmIFdoYXQgd2Ugd2FudCBpcyBhIFJlYXNvbiBmaWVsZCBhbmQgbm90DQog YSBTdGF0dXMgZmllbGQgaW4gdGhlIERDTy4uIEhlbmNlIEkgYmVsaWV2ZSB0aGF0IHRoZXJlIGFy ZSBjaGFuZ2VzIHJlcXVpcmVkIGZvciBJQU5BLiBXZSBjYW4gdGFrZSBhIHNob3J0Y3V0IGFuZCBr ZWVwIHRoZSBmaWVsZCBzYW1lIGFzIFN0YXR1cywgYnV0IGl0IHNlZW1zIGxpa2UgYSBoYWNrIHRv IG1lLjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpMZSAzMCBhb8O7dCAyMDE5IMOgIDA5OjMwLCBQZXRlciB2 YW4gZGVyIFN0b2sgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG9rY29uc0BiYmhtYWlsLm5sIj5zdG9r Y29uc0BiYmhtYWlsLm5sPC9hPiZndDsgYSDDqWNyaXQmbmJzcDs6PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhp IEF1dGhvcnMsPGJyPg0KPGJyPg0KSXQgaXMgYSBiaXQgbGF0ZSB0byBjaGFuZ2UgdGhlIGFwcHJv dmVkIGRyYWZ0Ljxicj4NCkl0IGlzIGluIElBTkEgZWRpdGluZzsgYW5kIHlvdSBjb3VsZCB3cml0 ZSB0byBJQU5BIHRvIGFwb2xvZ2l6ZSBmb3IgYSBsYXRlIGFkZGl0aW9uIGFuZCBzZWUgaG93IGZh ciB0aGV5IGFyZSBpbiB0aGUgcHJvY2Vzcy48YnI+DQpCVVQsIHdvcnNlLCZuYnNwOyBob3cgbXVj aCB0ZXh0IGlzIG5lZWRlZCB0byBleHBsYWluIHRoaXMgYWRkaXRpb24/PGJyPg0KPGJyPg0KQWRk aW5nIHRleHQgdG8gYW4gYXBwcm92ZWQgZG9jdW1lbnQgc291bmRzIGxpa2Ugb3BlbmluZyBhIGNh biBvZiB3b3JtcyB0byBtZS48YnI+DQo8YnI+DQpQZXRlcjwvcD4NCjxwPlJhaHVsIEFydmluZCBK YWRoYXYgc2NocmVlZiBvcCAyMDE5LTA4LTMwIDA5OjAzOjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjMTAxMGZmIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNS4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMWY0OTdkIj5UaGUgRENPIGNvdWxkIGJlIGluaXRpYXRl ZCBmb3IgcmVndWxhciByb3V0ZSBpbnZhbGlkYXRpb24gZHVlIHRvIHBhdGggY2hhbmdlcyBvciBi ZWNhdXNlIG9mIG1hbmFnZW1lbnQgZGVjaXNpb24uIFRoZSBzdGF0dXMgY29kZSBjYW4gaGVscCB1 bmRlcnN0YW5kDQogdGhlIHJlYXNvbiBmb3IgaW5pdGlhdGluZyB0aGUgRENPLiBJIGxpa2UgdGhl IGlkZWEgb2YgdGhpcy48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxZjQ5N2QiPkhvd2V2ZXIsIEkgZG9u4oCZdCBrbm93 LCBwcm9jZWR1cmFsbHksIHdoYXQgaXQgbWVhbnMgdG8gY2hhbmdpbmcgdGhlIGRyYWZ0IGF0IHRo aXMgc3RhZ2UuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMWY0OTdkIj5UaGUgY2hhbmdlcyB0byBkcmFmdCB3b3VsZCBp bmNsdWRlIG5ldyBJQU5BIGNvbnNpZGVyYXRpb25zIGZvciB0aGUgc3RhdHVzIGZpZWxkLjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMWY0OTdk Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI2UxZTFlMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHN0cm9uZz5Gcm9tOjwvc3Ryb25nPiBSb2xsIFs8YSBocmVm PSJtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cm9sbC1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxzdHJvbmc+T24gQmVoYWxmIE9mIDwvc3Ryb25nPlBhc2NhbCBUaHViZXJ0IChw dGh1YmVydCk8YnI+DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+IDMwIEF1Z3VzdCAyMDE5IDE0OjQz PGJyPg0KPHN0cm9uZz5Ubzo8L3N0cm9uZz4gUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9z c3kgbmV0d29ya3MgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+IFtSb2xsXSBzdWdnZXN0 ZWQgYWRkaXRpb24gdG8gZHJhZnQtaWV0Zi1yb2xsLWVmZmljaWVudC1ucGRhbzwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+RGVhciBhbGwmbmJzcDs7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkga25vdyBpdOKAmXMgbGF0ZSBidXQg SeKAmWQgc3VnZ2VzdCBhbiBhZGRpdGlvbiB0byBkcmFmdC1pZXRmLXJvbGwtZWZmaWNpZW50LW5w ZGFvLiBUaGVyZeKAmXMgYSByZXNlcnZlZCBmaWVsZCBpbiB0aGUgRENPLjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+TXkgc3VnZ2VzdGlvbiBpcyB0byB1c2UgaXQgdG8gdHJhbnNwb3J0IFJQ TCBEQU8tQUNLIHN0YXR1cyB2YWx1ZXMgYXMgZGVmaW5lZCBpbiBSRkMgNjU1MC4gVGhpcyB3YXkg d2UgY2FuIHNpZ25hbCB0aGUgcmVhc29uIG9mIHRoZSBEQ08gdG8gdGhlIG5vZGUuPC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHdpbGwgYmVjb21lIHNpZ25pZmljYW50IHdpdGggdGhl IFJQTC11bmF3YXJlIGxlYXZlcyBkcmFmdCwgc28gd2UgY2FuIHJlYnVpbGQgYSBOQShFQVJPKSB3 aXRoIGEgbm9uLXplcm8gc3RhdHVzIGJhc2VkIG9uIGEgRENPLjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FbHNlIHRoZSBSVUwg ZHJhZnQgd2lsbCBoYXZlIHRvIHVwZGF0ZSBlZmZpY2llbnQgTlAgREFPLCB3aGljaCBkb2VzIG5v dCBsb29rIGFzIGdvb2QuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkFueSBvYmplY3Rpb24gdG8gdGhpcz88L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UGFzY2Fs PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBSUExJbnN0YW5jZUlEIHxLfER8 Jm5ic3A7Jm5ic3A7IEZsYWdzJm5ic3A7Jm5ic3A7DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5 ZWxsb3ciPnwmbmJzcDsmbmJzcDsgUmVzZXJ2ZWQ8L3NwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwg RENPU2VxdWVuY2UmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0Mzs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0Mzs8L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRE9E QUdJRChvcHRpb25hbCkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0Mzs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzs8L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgT3B0 aW9uKHMpLi4uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpSb2xsIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 Um9sbEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5Sb2xsQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KUm9sbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+ Um9sbEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JvbGwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbDwvYT48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIDxicj4N ClJvbGwgbWFpbGluZyBsaXN0IDxicj4NCjxhIGhyZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj5S b2xsQGlldGYub3JnPC9hPiA8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JvbGwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbDwvYT4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9ibG9ja3F1b3RlPg0KPGRp diBjbGFzcz0iZ21haWxfc2lnbmF0dXJlIj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_75A21EDDA0704A07B7E8F7F2025C6BBCciscocom_-- From nobody Fri Aug 30 09:41:55 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5F6120B57; Fri, 30 Aug 2019 09:41:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <156718330215.25877.18169504635590428359@ietfa.amsl.com> Date: Fri, 30 Aug 2019 09:41:42 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-unaware-leaves-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 16:41:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Routing for RPL Leaves Authors : Pascal Thubert Michael C. Richardson Filename : draft-ietf-roll-unaware-leaves-03.txt Pages : 28 Date : 2019-08-30 Abstract: This specification extends RFC6550 and RFC8505 to provide unicast and multicast routing services in a RPL domain to 6LNs that are plain hosts and do not participate to RPL. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-03 https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 30 11:13:29 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01001120B78 for ; Fri, 30 Aug 2019 11:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 FL_EFQSiIXhw for ; Fri, 30 Aug 2019 11:13:15 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 E55D0120B68 for ; Fri, 30 Aug 2019 11:13:14 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id a21so8927548edt.11 for ; Fri, 30 Aug 2019 11:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=mACDTwNARat+xWh0xYKY/VCM+XTI3riu5zcHjVVul/M=; b=VZB5y97QmWpIoNM97PoCCsEJWBwkmPODpZhtzmwA+FTiIEl4QLGsNF2sxlmo3fM+Ij HEYxNBWABhF45k0ioNv+Upk0xr+JHDRY2lpmP+9LcLIVq5Gc3jUqzV2iCLTuEg30eZRU GoYMmVsZ5JhouIMNk0JS44hQcDL0/U/rTpJWWQn2BgMe+JOnw4rWWA3sfJifO1kzhWPy +HkmeHW6bO5q2D0IvN7LWDl49ADUz9wZA4Qbm/jPRj5ATMyGdejTwEoFBjUvMlW18UVH BvXBygeXPXQ7HSGZHEQdT4W6nMLJt2E7sqOUuTZ5KniNYNXYBKBHtKZfBcMbG7AL4pT7 XdFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=mACDTwNARat+xWh0xYKY/VCM+XTI3riu5zcHjVVul/M=; b=eZqWkaMtuVb0bY49W8gpkoG99KVBgJLEbCgmvRRxRl0cOHuYv2cm55Dw3/wN8vF1Br Q0VFhV/ybS/38sN9PccyOkmrrD7d561qup/sYzwujuyguB2Lpo0P/+dbCDsPe6RFsYTQ Ffz5+sC0r+qdwCGZPXZzXGjPqNwr+PMSlSZYIUrAZ2jpEGJtvBbm8/xIewjyxudfSUkJ /xOxu2/AuzhO4vTWAHkb2CTU0Gf9soo9jxSExw5rC9lcxS6cCcxvEfPS8+QMGA9ljH/E yyp9aoLOCF/TBLAqEjsRLRJ0x347TUmsplDyyDoquuLuhlAlhowL9P+hRi35F5S7bNg3 R6eA== X-Gm-Message-State: APjAAAWD+hnxCPa4GL7dW5dB14fuV3Y9v/iFvjIV/Z6hEOLMrN574wmw 8BZNnxmNnsIRWKqdqqHZMBi7b4e8v0ztDpzXF4NR4D49 X-Google-Smtp-Source: APXvYqzHEfsUqORu5mnccsgn+Ux4yLJJYQuLobEfcw3Y9h+1DgnvyGWkWXHGW4AlT/Bj+3ldPDn0/r8oSu7NlofS+cE= X-Received: by 2002:aa7:da54:: with SMTP id w20mr10745886eds.52.1567188793502; Fri, 30 Aug 2019 11:13:13 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 30 Aug 2019 11:13:12 -0700 From: Alvaro Retana In-Reply-To: <75A21EDD-A070-4A07-B7E8-F7F2025C6BBC@cisco.com> References: <982B626E107E334DBE601D979F31785C5DFBB52A@BLREML503-MBX.china.huawei.com> <11e99cd92e3b945439fce18557efc18f@bbhmail.nl> <9ED90E26-9AC9-4FB9-86FF-3FD838CB0E60@cisco.com> <982B626E107E334DBE601D979F31785C5DFBB5B8@BLREML503-MBX.china.huawei.com> <75A21EDD-A070-4A07-B7E8-F7F2025C6BBC@cisco.com> MIME-Version: 1.0 Date: Fri, 30 Aug 2019 11:13:12 -0700 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Routing Over Low power and Lossy networks , "consultancy@vanderstok.org" Content-Type: multipart/alternative; boundary="0000000000005531850591599373" Archived-At: Subject: Re: [Roll] suggested addition to draft-ietf-roll-efficient-npdao X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 18:13:28 -0000 --0000000000005531850591599373 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 30, 2019 at 10:20:05 AM, Pascal Thubert (pthubert) ( pthubert@cisco.com) wrote: Pascal: The proposal does not change the behavior of the NPDAO but adds information about why the NPDAO is sent. Are you concerned by attacks like a cover channel? We could have one sentence on that but I=E2=80=99m unclear how to = protect against it. I haven=E2=80=99t thought about it too long=E2=80=A6but, yes, that could be= one thing. Not having a mitigation is ok, as long as a potential vulnerability is explained. In the future status values that modify the behavior of NPDAO may be introduced. But for now we=E2=80=99d be looking at a very minimalistic chan= ge where the reserved field carries a RPL status that does not affect the behavior of the nodes. The hope would be that it does not affect the reviews that were already done. I hope so too=E2=80=A6but would have to see the scope of any change first. For now, I will ask the RFC Editor to pause processing. Thanks! Alvaro. --0000000000005531850591599373 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 30, 2019 at 10:20:05 AM, Pascal Thubert (pthu= bert) (pthubert@cisco.com) wrote:=

=
Pascal:

The proposal does not change the behavior of the NPDAO= but adds information about why the NPDAO is sent. Are you concerned by att= acks like a cover channel? We could have one sentence on that but I=E2=80= =99m unclear how to protect against it.

I haven=E2=80=99t thought about it too= long=E2=80=A6but, yes, that could be one thing.=C2=A0 Not having a mitigat= ion is ok, as =C2=A0long as a potential vulnerability is explained.<= /p>

In the future status values that modify the beh= avior of NPDAO may be introduced. But for now we=E2=80=99d be looking at a = very minimalistic change where the reserved field carries a RPL status that= does not affect the behavior of the nodes.
The hope= would be that it does not affect the reviews that were already done.
=

I hope so too= =E2=80=A6but would have to see the scope of any change first.

= For now, I will ask the RFC Editor to pause proces= sing.

Thanks!

Alvaro.



--0000000000005531850591599373--