From nobody Fri Mar 1 13:14:57 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 E179D13121C; Fri, 1 Mar 2019 13:10:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: roll@ietf.org, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147460791.6101.7780528857287384509.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:07 -0800 Archived-At: Subject: [Roll] roll - Requested session has been scheduled for IETF 104 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, 01 Mar 2019 21:10:21 -0000 Dear Ines Robles, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. roll Session 1 (2:00 requested) Monday, 25 March 2019, Afternoon Session II 1610-1810 Room Name: Karlin 3 size: 60 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/roll.ics Request Information: --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Ines Robles Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: anima manet 6tisch core ace Second Priority: rtgarea 6lo 6man lwig cbor t2trg Third Priority: rtgwg intarea lpwan People who must be present: Michael Richardson Peter van der Stok Alvaro Retana Ines Robles Resources Requested: Special Requests: One of the chairs leaves on Thursday afternoon, it would be nice please if we could have the meeting before Thursday. Meetecho Support --------------------------------------------------------- From nobody Fri Mar 1 18:17:08 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 ED87D13108F; Fri, 1 Mar 2019 18:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8d-3etvnOQ23; Fri, 1 Mar 2019 18:16:52 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 50C2E131084; Fri, 1 Mar 2019 18:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x222GfDV008728; Sat, 2 Mar 2019 03:16:46 +0100 (CET) Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44B8zs2ZjKz1Br6; Sat, 2 Mar 2019 03:16:41 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 2 Mar 2019 03:16:38 +0100 Message-Id: <0FB9A91D-0BA9-4286-ACDA-F2596454A3A8@tzi.org> To: lo <6lo@ietf.org>, tisch <6tisch@ietf.org>, lp-wan , lwip@ietf.org, Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF104: FINAL AGENDA 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, 02 Mar 2019 02:17:06 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF104. Remember that, even though this will now go to the printers, there is still some potential for changes. The somewhat annoying coflicts cose/teep and lpwan/t2trg remain. I also don't like that I'll have to miss the cacao BOF (vs. core), dinrg/suit, coinrg/git. rats has been swapped against the paw/saag conflict. All times are CET (Central European Time) =3D=3D UTC +1 hours. Note = that there is no daylight saving time in effect at the time in Europe (this starts on the Sunday *after* IETF). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten FRIDAY, March 22, 2019 -- Fri 0930=E2=80=931830 T2TRG Work Meeting -- Istanbul room SATURDAY/SUNDAY, March 23/24. 2019 -- Hackathon (including various interops) (Grand Hilton Ballroom) -- Sun 1700-1900 Welcome Reception - Congress Hall 1/2 -- Sun 1800-2000 Hot RFC Lightning Talks - Congress Hall 3 MONDAY, March 25, 2019 0900-1100 Morning Session I Congress H 3 ART dispatch Dispatch WG - Joint with ARTAREA Congress H 2 INT 6man IPv6 Maintenance WG Congress H 1 IRTF pearg Privacy Enhancements and Assessments = Proposed Research Group Karlin 3 RTG bier Bit Indexed Explicit Replication WG 1120-1220 Morning Session II Congress H 3 INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Karlin 3 RTG bier Bit Indexed Explicit Replication WG Congress H 2 SEC tls Transport Layer Security WG Karlin 1/2 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1350-1550 Afternoon Session I Karlin 1/2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Congress H 2 IRTF irtfopen IRTF Open Meeting Congress H 3 SEC secdispatch Security Dispatch WG 1610-1810 Afternoon Session II Congress H 2 ART httpbis Hypertext Transfer Protocol WG Congress H 3 IAB smart Stopping Malware and Researching Threats Berlin/Brussels INT dnssd Extensions for Scalable DNS Service = Discovery WG Grand BR IRTF qirg Quantum Internet Proposed Research Group Karlin 3 RTG *** roll Routing Over Low power and Lossy = networks WG Athens/Barcel. SEC oauth Web Authorization Protocol WG Congress H 1 TSV tsvwg Transport Area Working Group WG TUESDAY, March 26, 2019 0900-1100 Morning Session I Karlin 3 ART uta Using TLS in Applications WG - 1000 - = 1100 Grand BR INT homenet Home Networking WG Berlin/Brussels SEC *** cose CBOR Object Signing and Encryption WG Karlin 1/2 SEC *** teep Trusted Execution Environment = Provisioning WG Congress H 2 TSV quic QUIC WG 1120-1220 Morning Session II Athens/Barcel. INT *** lwig Light-Weight Implementation Guidance WG Congress H 1 IRTF qirg Quantum Internet Proposed Research Group Congress H 3 TSV tsvwg Transport Area Working Group WG 1350-1550 Afternoon Session I Berlin/Brussels ART *** core Constrained RESTful Environments WG Karlin 1/2 OPS anima Autonomic Networking Integrated Model = and Approach WG Congress H 1 SEC mls Messaging Layer Security WG Congress H 3 TSV tsvarea Transport Area Open Meeting 1610-1810 Afternoon Session II Grand BR INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Congress H 1 IRTF*** t2trg Thing-to-Thing Congress H 2 SEC tls Transport Layer Security WG WEDNESDAY, March 27, 2019 0900-1100 Morning Session I Karlin 1/2 IRTF*** dinrg Decentralized Internet Infrastructure Congress H 1 RTG detnet Deterministic Networking WG Grand BR RTG rift Routing In Fat Trees WG Congress H 3 SEC *** suit Software Updates for Internet of Things = WG Congress H 2 TSV quic QUIC WG 1120-1320 Morning Session II Grand BR IRTF cfrg Crypto Forum - 12:20 - 13:20 Grand BR SEC acme Automated Certificate Management = Environment WG - 11:20 - 12:20 1500-1700 Afternoon Session I Grand BR OPS wgtlgo Technology Deep Dive - Modern Router = Architecture BOF THURSDAY, March 28, 2019 0900-1030 Morning Session I Karlin 3 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Congress H 3 IRTF panrg Path Aware Networking RG Athens/Barcel. RTG babel Babel routing protocol WG Congress H 1 SEC mls Messaging Layer Security WG Berlin/Brussels SEC oauth Web Authorization Protocol WG 1050-1220 Morning Session II Congress H 3 GEN git GitHub Integration and Tooling WG Congress H 1 IRTF coinrg Computing in the Network Congress H 2 IRTF maprg Measurement and Analysis for Protocols 1350-1550 Afternoon Session I Congress H 3 ART httpbis Hypertext Transfer Protocol WG Grand BR INT *** paw Predictable and Available Wireless BOF Athens/Barcel. OPS v6ops IPv6 Operations WG Congress H 1 SEC saag Security Area Open Meeting 1610-1810 Afternoon Session II Athens/Barcel. INT intarea Internet Area Working Group WG Grand BR SEC *** rats Remote ATtestation ProcedureS BOF FRIDAY, March 29, 2019 0900-1030 Morning Session I Grand BR ART *** core Constrained RESTful Environments WG Congress H 1 INT 6man IPv6 Maintenance WG Berlin/Brussels SEC cacao Collaborative Automated Course of Action = Operations for Cyber Security BOF 1050-1250 Morning Session II Berlin/Brussels INT ipwave IP Wireless Access in Vehicular = Environments WG Karlin 1/2 IRTF icnrg Information-Centric Networking Congress H 1 SEC *** ace Authentication and Authorization for = Constrained Environments WG Athens/Barcel. TSV taps Transport Services WG From nobody Thu Mar 7 16:59:58 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 45580131128; Thu, 7 Mar 2019 16:59:48 -0800 (PST) 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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <155200678823.5406.7265933862545936809@ietfa.amsl.com> Date: Thu, 07 Mar 2019 16:59:48 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-aodv-rpl-06.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, 08 Mar 2019 00:59:48 -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 : Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) Authors : Satish Anamalamudi Mingui Zhang Charles E. Perkins S.V.R Anand Bing Liu Filename : draft-ietf-roll-aodv-rpl-06.txt Pages : 25 Date : 2019-03-07 Abstract: Route discovery for symmetric and asymmetric Point-to-Point (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol. Paired Instances are used to construct directional paths, in case some of the links between source and target node are asymmetric. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-06 https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 7 17:00: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 521C71310E8; Thu, 7 Mar 2019 17:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm0_h5ItLhZr; Thu, 7 Mar 2019 17:00:29 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (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 B700413123B; Thu, 7 Mar 2019 17:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1552006824; bh=W211nNSt6/9A9QTOjGPNJq/ZF50wEKc2xOvH NMCRG3I=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=GCN86bWLiWapAqL3CX05R5oMaOLZni8zz 2FMk7hO78yoIo19sPSBj101voCGf9e4Reu05nEU+vh9lARVH8f02rohiU5LQFtJGgqR QQ00Q1qlnwYIqVW1WpiF7ErkAgA2o4ChQ5wLOnapGmPU5w3zO/E9qvdOv4NglWLTJ+P 81D2L0cauQMd3XlpSgPQwd/dzS10R7gPf4iUmYoqzsETFBmvUx0QxFDVb/WL2o+i9As jEP09l19yGGvx6O3zdD9zX7seVmBd+eO4EMrIvfIBu0zBp1sjSEcpSqC04ChwVyCXAN oDAFgMw56l9K+XZY0199sYr3PX1eUxwFmm5endP0g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=hL++B0YsKVIyVACXV3CvLYolDZ4m01P2XCZnogWw5q7E3mIr7ONrPC5kOfB+Pn9o/vANL/WCJnEqAAyllM2stAz5CIVuKxClQbbeurlvcI/s9n91KTPCjh4n7ExaGVGHCzYepVNRHutZw59uuCOmVvVbNwLJcbUnB1ih4JDzbIIC2qj/g2mIdA2VPhjbIhDTI0G7nVZKcunTHHCHKIm5a13uCS4kn70f+Z/4hKap+gFQgdWZoNjr4o8BH6VFpqyGtdqAB4zoyKocrf+1O4VF94g0uspEoSEqKF7VpigWyUdHUzS3HSVXy3KSHqVr3lNsJpaZ+DGM0Qphl2g/Pofe8Q==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1h23s6-0002s2-PX; Thu, 07 Mar 2019 20:00:22 -0500 To: Peter van der Stok , Roll , Draft-ietf-roll-aodv-rpl References: <7e90f9a49be79a88261a3e77bc6e27f7@bbhmail.nl> From: Charlie Perkins Message-ID: <73f19e3d-1cc1-b06f-80e0-9e7c9e10d574@earthlink.net> Date: Thu, 7 Mar 2019 17:00:18 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <7e90f9a49be79a88261a3e77bc6e27f7@bbhmail.nl> Content-Type: multipart/alternative; boundary="------------B2A202FB9294794948E213B1" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95e9b6793e299fe64cbe5e414deed96f82350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [Roll] aodv-rpl review 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, 08 Mar 2019 01:00:32 -0000 This is a multi-part message in MIME format. --------------B2A202FB9294794948E213B1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Peter, I think our new revision will resolve most or all of your comments.  We have greatly expanded the Security Considerations, and added clarifications about the relationship with RFC 6997.  I also added some explanation about the difference between "application-specific" versus P2P routing.  They are pretty much different and I hope that comes through better. Thanks for all of the suggestions! Regards, Charlie P. On 11/28/2018 1:06 AM, Peter van der Stok wrote: > Hi aodv-rpl co-authors, > > I promised to do a quick review of the document before passing it to > the shepherd. > > The document reads rather smoothly, and seems to be complete. > Question: are there any implementations, and has there been an > interop? I vaguely remember the subject being mentioned, but do not > remember the answer. > > I like the appendix A, it helps enormously to understand the > bidirectional asymmetric link concept. > > Major question: what is the relation with 6997 P2P-RPL. > Does this document replace RFC 6997. To me it seems that in the case > of symmetric links only, AODV-RPL degrades to P2P-RPL. Probably not in > an interoperable way given the different MOP etc. > May be you can explain your ideas in this respect. > RFC 6997 is "experimental" to go to STD when more experience was gained. > Does that also apply to this document, or is there an operational > direct need identified. > > Should 5548, 5673, 5826, 5867 not go to informational; you don't need > them to implement the spec. > > Last but not least: section 10 security Considerations is more than > terse; I am afraid that the security review will judge this > inadequate. You can look what has been done in the npdao draft; but I > cannot guarantee that this is sufficient. > The MANET WG has been active in describing threats in RFC 7985; may be > you can find inspiration there to categorize the problems and identify > the ones applying to AODV-RPL. > > Some minor syntactical things that hit my eye. > > You never write out RPL, although the other acronyms have been honored > as such. > In section 1 the term TargNode appears all of the sudden; suggest to > use Target Node in section 1. > You use application-specific routing and P2P routing; what is the > difference? > section 3: s/established are/are established/ > section 6.1: s/increse/increase/ > s/previous/previously/ > s/increased number/sequence number/ > > Greetings, > and thanks for the work, > > Peter > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > , stokcons@bbhmail.nl > > www: www.vanderstok.org > tel NL: +31(0)492474673     F: +33(0)966015248 --------------B2A202FB9294794948E213B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Peter,

I think our new revision will resolve most or all of your comments.  We have greatly expanded the Security Considerations, and added clarifications about the relationship with RFC 6997.  I also added some explanation about the difference between "application-specific" versus P2P routing.  They are pretty much different and I hope that comes through better.

Thanks for all of the suggestions!

Regards,
Charlie P.


On 11/28/2018 1:06 AM, Peter van der Stok wrote:
Hi aodv-rpl co-authors,

I promised to do a quick review of the document before passing it to the shepherd.

The document reads rather smoothly, and seems to be complete.
Question: are there any implementations, and has there been an interop? I vaguely remember the subject being mentioned, but do not remember the answer.

I like the appendix A, it helps enormously to understand the bidirectional asymmetric link concept.

Major question: what is the relation with 6997 P2P-RPL. 
Does this document replace RFC 6997. To me it seems that in the case of symmetric links only, AODV-RPL degrades to P2P-RPL. Probably not in an interoperable way given the different MOP etc.
May be you can explain your ideas in this respect.
RFC 6997 is "experimental" to go to STD when more experience was gained.
Does that also apply to this document, or is there an operational direct need identified.

Should 5548, 5673, 5826, 5867 not go to informational; you don't need them to implement the spec.

Last but not least: section 10 security Considerations is more than terse; I am afraid that the security review will judge this inadequate. You can look what has been done in the npdao draft; but I cannot guarantee that this is sufficient.
The MANET WG has been active in describing threats in RFC 7985; may be you can find inspiration there to categorize the problems and identify the ones applying to AODV-RPL.

Some minor syntactical things that hit my eye.

You never write out RPL, although the other acronyms have been honored as such.
In section 1 the term TargNode appears all of the sudden; suggest to use Target Node in section 1.
You use application-specific routing and P2P routing; what is the difference?
section 3: s/established are/are established/
section 6.1: s/increse/increase/
s/previous/previously/
s/increased number/sequence number/

Greetings,
and thanks for the work,

Peter
--
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248
--------------B2A202FB9294794948E213B1-- From nobody Mon Mar 11 07:27:17 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 A409C131074; Mon, 11 Mar 2019 07:27:09 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <155231442963.23110.3172802492151998023@ietfa.amsl.com> Date: Mon, 11 Mar 2019 07:27:09 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-25.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: Mon, 11 Mar 2019 14:27:10 -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 : Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane Authors : Maria Ines Robles Michael C. Richardson Pascal Thubert Filename : draft-ietf-roll-useofrplinfo-25.txt Pages : 51 Date : 2019-03-11 Abstract: This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC 6553 adding a change to the RPL Option Type. Additionally, this document updates RFC 6550 to indicate about this change and updates RFC8138 as well to consider the new Option Type when RPL Option is decompressed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 10:23:14 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 EFF18131155 for ; Mon, 11 Mar 2019 10:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qor5IlbKUsh9 for ; Mon, 11 Mar 2019 10:23:05 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 888F4131172 for ; Mon, 11 Mar 2019 10:23:05 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id m35so4716816ede.10 for ; Mon, 11 Mar 2019 10:23:05 -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=DlemaZ+VNgfA0OL4HvETz+dXCWTje1E5cfZVHy/ZZ8A=; b=L0uEawPPbb1TOim6XUcQySJUKNKRAhhOkhCB18WhmVKI8le0i3Kpzjh7YXD1yN2Kc9 PGRR9XxYMn2CCvDVAwCgL7VNQj6YI0VT9ty+aq0WkpadVJ8iYai22SBmpjoQScYuTT1+ A5uXBMzlbgKhSNKpDfma3jatutL2p21CZUZyluj+nZHzLXW/PfFsLm2DPbq4b0Z/LaNZ Bo5vi2/mnRz7StL/dHaM5xmEQPI/6vDWO6xNJyUtMOIyDae0OVFuv4zSVR3YQDNGlnQu gjOczD5GAK2hFB1ZH/U3BDulW1pLNBRfqGugAP8HA/jVl3fuTRKvLa0FdP/F+Au2xWqR ol+g== 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=DlemaZ+VNgfA0OL4HvETz+dXCWTje1E5cfZVHy/ZZ8A=; b=IRtkgMcgJBTxTbDuqyF4mREelazElCKZ9vla75SfmQgELR02W6kvNgy4siKRA++yLY wZvyWd4pNrueDXeg6V/7BCjNP/jhBNYHy4+8zeSjf9TAEk2kSX3tWA6O6xR0M6ZNZZ6b n57duupLMsN4meNSzPlFs9ho7nenqWF1doLRalSsYL2NZwBal+NrxdPxS3ldFJBHKvJT olM9Qp5ktHgVPRBXQs+ZKsAFCGDYu7xuQc+plvZbkAiqu+6stMwR3ettt4kdP1oRXYEP YEjh0cQFaY3b7s7+yW8uYv+DolC6uqZlAEcrBx71beWUm6Cr9DVS6mYFMONt3CTI0B/+ skbw== X-Gm-Message-State: APjAAAWpxP7PWZeyoihqxhIHIeG3vwQ03+ur6I7Wf7AdAjhxOascJstv LDTu+Ex+4xtRZ5oUv4JNq24FRCrj/uTjQ0frvKOnFQ== X-Google-Smtp-Source: APXvYqwNvPtOpr/mmG2NNg5d0sOAFZc3s5BpPUlsm15MOZNV2kgcrkXQ8uK4vQbzrd3O71n5GShnV4xVnxewkTMDh8o= X-Received: by 2002:a50:eb82:: with SMTP id y2mr44508375edr.38.1552324983408; Mon, 11 Mar 2019 10:23:03 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Mon, 11 Mar 2019 19:22:51 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000364d130583d4d364" Archived-At: Subject: [Roll] IETF 104 - Agenda published - version 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, 11 Mar 2019 17:23:13 -0000 --000000000000364d130583d4d364 Content-Type: text/plain; charset="UTF-8" Dear all, Please find below the link to the agenda for the IETF 104 https://datatracker.ietf.org/meeting/104/materials/agenda-104-roll-00 Dear presenters, please send us the slides in PDF format before 22th March. Thank you very much in advance :-) Comments welcome, Cheers, Ines and Peter --000000000000364d130583d4d364 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find = below the link to the agenda for the IETF 104


Dear presenters, please se= nd us the slides in PDF format before 22th=C2=A0March. Thank you very much = in advance :-)

Comments welcome,

Cheers,

Ines and Peter
--000000000000364d130583d4d364-- From nobody Mon Mar 11 15:22:00 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 02EC4131083; Mon, 11 Mar 2019 15:21:53 -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.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <155234291297.23082.12705498031600999644@ietfa.amsl.com> Date: Mon, 11 Mar 2019 15:21:53 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-nsa-extension-01.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: Mon, 11 Mar 2019 22:21:53 -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 : RPL DAG Metric Container Node State and Attribute object type extension Authors : Remous-Aris Koutsiamanis Georgios Papadopoulos Nicolas Montavont Pascal Thubert Filename : draft-ietf-roll-nsa-extension-01.txt Pages : 14 Date : 2019-03-11 Abstract: Implementing Packet Replication and Elimination from / to the RPL root requires the ability to forward copies of packets over different paths via different RPL parents. Selecting the appropriate parents to achieve ultra-low latency and jitter requires information about a node's parents. This document details what information needs to be transmitted and how it is encoded within a packet to enable this functionality. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-01 https://datatracker.ietf.org/doc/html/draft-ietf-roll-nsa-extension-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-nsa-extension-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 11 15:43:24 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 9C32F1279AA for ; Mon, 11 Mar 2019 15:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.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 jLTz9TqIIUzP for ; Mon, 11 Mar 2019 15:43:18 -0700 (PDT) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B101228B7 for ; Mon, 11 Mar 2019 15:43:17 -0700 (PDT) Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 0E4FBA45 for ; Mon, 11 Mar 2019 23:43:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1552344195; bh=XbHDRCaT1fPnelwNhLnTzND8FhkjwasS+J0lY9Q4lLc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vkK2tyB7Kwor9+mquexorQ9+en9TjzjqKP5sgwehgfdXhQPZtgz10Q11nCFc42tJX c4HWhlrX7RSYonfJSfXoCR5VK92AV0R1uhR5gqPGoGwQCgafvZ8BrrazQNFHGx3S4s uJZRNrPq+6e2rjE5+oznPyFAMi9vr2zTcyQyjncyock56zcRzySqB0ePxarmF/954A FJtukxBEPl63D+CXuRFTEbUn1BCDfK0GtPJ7zBrFGdvefKvHqzE/hgi7jjNU2fXsjU GpJVomfGNZK/ubMp+hypiCRuUzeExI2Pbsl6FQqeN5gV0lhzCGcsEZ/xFnsJwO/ck6 LpPEH2ftvMFBw== Received: from mail-it1-f171.google.com ([209.85.166.171]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Mon, 11 Mar 2019 23:43:10 +0100 (CET) Received: by mail-it1-f171.google.com with SMTP id e24so1343531itl.1 for ; Mon, 11 Mar 2019 15:43:09 -0700 (PDT) X-Gm-Message-State: APjAAAU1XYnAf2Z8IpH4uzSFzaprQHsnRBnnLL0Dub/ZGrPlnRyhA96N sGwMTfR4sTIPyFv0j6/hbxACQmWNWODlJiOlhGY= X-Google-Smtp-Source: APXvYqww12o7fp3Tz8Ee/l7JuAVu7tSLDeDznfwtZqXkQa3C9LhRl1yiiWbRAs/Ibng6vY4pxRCXKdYTrJJHllr5Qv4= X-Received: by 2002:a24:3655:: with SMTP id l82mr365235itl.107.1552344187129; Mon, 11 Mar 2019 15:43:07 -0700 (PDT) MIME-Version: 1.0 References: <982B626E107E334DBE601D979F31785C5DCE9361@BLREML503-MBX.china.huawei.com> In-Reply-To: From: Remous-Aris Koutsiamanis Date: Mon, 11 Mar 2019 23:43:12 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000d7d6210583d94b8a" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] Traffic aware OF -03 review 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, 11 Mar 2019 22:43:23 -0000 --000000000000d7d6210583d94b8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, thank you very much for the constructive comments Rahul. I think they will significantly improve the quality of the draft. I have responded inline to each point. I have also just submitted an updated version of the draft named: draft-koutsiamanis-roll-traffic-aware-of-00 https://datatracker.ietf.org/doc/draft-koutsiamanis-roll-traffic-aware-of/ Kind regards, Aris On Tue, Nov 6, 2018 at 1:21 PM Rahul Arvind Jadhav wrote: > Hello Authors-of-TAOF, > > > > Network lifetime is a known problem in the space and I am glad to see > something been done in the context. Following are some thoughts I have: > > > > > 1. Handling Config: DIO may need to carry OF configuration > parameters .. i.e. all the nodes need to agree on the unit for e.g. for > THROUGHPUT_PERIOD defined in the draft. It is necessary that all the node= s > agree on the time unit. > You are absolutely right and this is something that concerned me as well when we first introduced it. For starters, to be more accurate I have renamed THROUGHPUT_PERIOD to THROUGHPUT_WINDOW since a sliding window is specified explicitly. See Section 5. So at this point I have tried to offer flexibility. One can either configure THROUGHPUT_WINDOW in the whole network in any external way desired (e.g. compile-time constant, via COAP or other higher-level configuration mechanism) or provide this information along with the RT value with some overhead in the DIO. As is customary for optional information, I have defined a TLV for this value. I followed the same approach for the unit (i.e. either configure externally or provide optional TLV) new introduced as THROUGHPUT_WINDOW_UNIT. See Section 6. I hope that although these options do incur overhead in the packet size, they allow for maximum flexibility. If someone wants to avoid some or all of the overhead they can still hard-code some or all of the TLVs and sacrifice some flexibility. > During ROLL session, Pascal mentioned that parent oscillations should be > avoided and suggested use of multiple parents while the transition is in > progress. Another way to handle this is to involve hysteresis in this dra= ft > and give guidelines/recommendations for configuring thresholds. > This was a very good point raised and my view is that we need to perform some experimental evaluations to get an idea of what will work well. Unfortunately, at this point we have not yet completed this evaluation, although we plan to. We might have some results in time for the IETF but I am not sure about it yet. Therefore, at this point, I think that the idea for carrying the RT metric is relatively solid but some more work is needed to specify how the TAOF might use it. I have added a reference to this idea in the draft but no concrete solution is provided at this time. 2. Certain deployments have roughly similar data stream generated > from all nodes .. for e.g. metering.. Current draft requires throughtput > measurement on 6LRs .. In all cases this throughput calc may not be > required .. But there is still a case to balance the network nonetheless = .. > Is it possible to consider balancing based on the sub-dodag size rooted a= t > 6lr (naturally works only for storing MOP) ? In this sense, the work > qasem-load-balancing was trying to do was similar considering nodes have > similar traffic patterns. > Yes, I am aware of the qasem-load-balancing work, basically counting the number of children. In my opinion this is, as you say, an approximation or simplification for the case where the nodes all generate more or less the same traffic. Actually measuring the traffic is more accurate, in my opinion, so it should be preferred if possible. So the question is: are there any downsides to having to measure traffic? In terms of computational resources, the overhead should be minimal for adding an entry in a list every time a packet is sent and counting the packets in a window every time a DIO is sent. There might be some measurable memory overhead if the window is very large *and* the traffic load is high. I wouldn't expect this to be the case in our use cases, however. Finally, there is a potential additional implementation complexity from adding this tracking. Given that we have already done this -if maybe not very efficiently- in Contiki, the modifications were a few hundred lines of code. I'm sorry I don't have specific numbers right now. If you think this an important issue, I'll be more than happy to count bytes, cycles, and lines of code :) to get some actual data. So in my view it all depends on what weighs more important, flexibility and accuracy with a little bit of overhead vs a simpler solution for one case. Any thoughts? > 3. Section 6: There are several bits that needs to be defined in > context for every routing metric (as per 6551) .. These are P, C, O, R, A > bits. It is better you clarify the bits in RT context. I am specifically > interested in understanding in how to handle this metric at multiple hops= . > How to do additive RT metric? > You are absolutely right. I have added a new Section "6.1. DAG Metric Container fields" in the draft which explains these fields. Also, the semantics of the RT metric (*remaining* throughput) are not really useful in an additive metric context. At least I couldn't think of a way to use it meaningfully this way. In our implementation, we use the minimum metric function, i.e. a node A with parent P reports in its DIO: DIO_RT(A) =3D MIN(DIO_RT(P), RT(A)) where RT(A) is the locally calculated remaining throughput at node A and DIO_RT(P) is the RT value of its parent P received via a DIO from P. > 4. I don=E2=80=99t understand why enrollment aspect was brought (th= is was > not present in earlier draft) .. The relay chosen during enrollment and > parent chosen during routing could be different. Enrollment can choose a > different set of metrics from routing.. Enrollment of nodes happens few > times during the lifetime of the device. The metrics enrollment could > consider could be completely different from routing metrics. > You are correct that the two processes are independent, and the relay and preferred parent do not necessarily coincide. However, we discussed whether it would be useful for accelerating the enrollment. If one has a large number of devices which need to connect, it can be useful for each device to be able to pick as quickly as possible a good DODAG and preferred parent. Since each relay will probably only be part of one DODAG, using RT to affect the pan priority helps the node pick a relay in a less congested DODAG, instead of picking a relay, joining to its DODAG (congested) and waiting for DIOs from other DODAGs or parents to optimise connectivity. I agree this is an optimisation for a specific use case, but my impression is that this is a desired feature to have. At the end of the day, it just specifies how to convert an RT value into a pan priority value. > > > Regards, > > Rahul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000d7d6210583d94b8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

thank you very much for the construc= tive comments Rahul. I think they will significantly improve the quality of= the draft. I have responded inline to each point.
I have also ju= st submitted an updated version of the draft named: draft-koutsiamanis-roll-traffic-aware-of-00


On Tue, Nov 6, 2018 at 1:21 PM Rahul Arvind Jadhav <rahul.jadhav@huawei.com>= wrote:

Hello Authors-of-TAOF,

=C2=A0

Network lifetime is a known problem in the space and= I am glad to see something been done in the context. Following are some th= oughts I have:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=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 Handling Config: DIO may need to carry OF configuratio= n parameters .. i.e. all the nodes need to agree on the unit for e.g. for T= HROUGHPUT_PERIOD defined in the draft. It is necessary that all the nodes a= gree on the time unit.

You are absolutely = right and this is something that concerned me as well when we first introdu= ced it.
For starters, to be more accurate I have renamed THROUGHP= UT_PERIOD to THROUGHPUT_WINDOW since a sliding window is specified explicit= ly. See Section 5.
So at this point I have tried to offer fle= xibility. One can either configure THROUGHPUT_WINDOW in the whole network i= n any external way desired (e.g. compile-time constant, via COAP or other h= igher-level configuration mechanism) or provide this information along with= the RT value with some overhead in the DIO.
As is customary= for optional information, I have defined a TLV for this value.
I followed the same approach for the unit (i.e. either configure externa= lly or provide optional TLV) new introduced as THROUGHPUT_WINDOW_UNIT.
See Section 6.

I hope that although thes= e options do incur overhead in the packet size, they allow for maximum flex= ibility.
If someone wants to avoid some or all of the overhead th= ey can still hard-code some or all of the TLVs and sacrifice some flexibili= ty.

During ROLL session, Pascal mentioned that parent oscillations s= hould be avoided and suggested use of multiple parents while the transition= is in progress. Another way to handle this is to involve hysteresis in thi= s draft and give guidelines/recommendations for configuring thresholds.

This was a very good point raised and my view is that we need= to perform some experimental evaluations to get an idea of what will work = well. Unfortunately, at this point we have not yet completed this evaluatio= n, although we plan to.
We might have some results in time for th= e IETF but I am not sure about it yet.
Therefore, at this point, = I think that the idea for carrying the RT metric is relatively solid but so= me more work is needed to specify how the TAOF might use it. I have added a= reference to this idea in the draft but no concrete solution is provided a= t this time.

2.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Certain deployments have roughly similar data stream generate= d from all nodes .. for e.g. metering.. Current draft requires throughtput = measurement on 6LRs .. In all cases this throughput calc may not be require= d .. But there is still a case to balance the network nonetheless .. Is it possible to consider ba= lancing based on the sub-dodag size rooted at 6lr (naturally works only for= storing MOP) ? In this sense, the work qasem-load-balancing was trying to = do was similar considering nodes have similar traffic patterns.

Yes, I am = aware of the qasem-load-balancing work, basically counting the number of ch= ildren.
In my opinion this is, as you say, an approximation or si= mplification for the case where the nodes all generate more or less the sam= e traffic.
Actually measuring the traffic is more accurate, in my= opinion, so it should be preferred if possible.
So the question = is: are there any downsides to having to measure traffic?
In term= s of computational resources, the overhead should be minimal for adding an = entry in a list every time a packet is sent and counting the packets in a w= indow every time a DIO is sent.
There might be some measurable me= mory overhead if the window is very large *and* the traffic load is high. I= wouldn't expect this to be the case in our use cases, however.
Finally, there is a potential additional implementation complexity f= rom adding this tracking. Given that we have already done this -if maybe no= t very efficiently- in Contiki, the modifications were a few hundred lines = of code.
I'm sorry I don't have specific numbers right no= w. If you think this an important issue, I'll be more than happy to cou= nt bytes, cycles, and lines of code :) to get some actual data.
So in my view it all depends on what weighs more important, flexibility = and accuracy with a little bit of overhead vs a simpler solution for one ca= se.
Any thoughts?
=C2=A0

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 6: There are several bits that needs to be def= ined in context for every routing metric (as per 6551) .. These are P, C, O= , R, A bits. It is better you clarify the bits in RT context. I am specific= ally interested in understanding in how to handle this metric at multiple hops. How to do additive RT metri= c?

You are absolutely right. I have added = a new Section "6.1. DAG Metric Container fields" in the draft whi= ch explains these fields.
Also, the semantics of the RT metr= ic (*remaining* throughput) are not really useful in an additive metric con= text. At least I couldn't think of a way to use it meaningfully this wa= y. In our implementation, we use the minimum metric function, i.e. a node A= with parent P reports in its DIO:
DIO_RT(A) =3D MIN(DIO_RT(P), R= T(A))
where RT(A) is the locally calculated remaining throughput = at node A and DIO_RT(P) is the RT value of its parent P received via a DIO = from P.
=C2=A0

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I don=E2=80=99t understand why enrollment aspect was b= rought (this was not present in earlier draft) .. The relay chosen during e= nrollment and parent chosen during routing could be different. Enrollment c= an choose a different set of metrics from routing.. Enrollment of nodes happens few times during the lifetime o= f the device. The metrics enrollment could consider could be completely dif= ferent from routing metrics.

You are correct that the two processes are independent, and the relay and = preferred parent do not necessarily coincide.
However, we discuss= ed whether it would be useful for accelerating the enrollment.
If= one has a large number of devices which need to connect, it can be useful = for each device to be able to pick as quickly as possible a good DODAG and = preferred parent.
Since each relay will probably only be part of = one DODAG, using RT to affect the pan priority helps the node pick a relay = in a less congested DODAG, instead of picking a relay, joining to its DODAG= (congested) and waiting for DIOs from other DODAGs or parents to optimise = connectivity.
I agree this is an optimisation for a specific use = case, but my impression is that this is a desired feature to have. At the e= nd of the day, it just specifies how to convert an RT value into a pan prio= rity value.


=C2=A0

=C2=A0

Regards,

Rahul

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000d7d6210583d94b8a-- From nobody Mon Mar 11 15:47: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 EAADB12870E for ; Mon, 11 Mar 2019 15:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.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 wSwZ-IMaWP0F for ; Mon, 11 Mar 2019 15:47:06 -0700 (PDT) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3382A1286C8 for ; Mon, 11 Mar 2019 15:47:06 -0700 (PDT) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id DD9C19C9 for ; Mon, 11 Mar 2019 23:47:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1552344424; bh=NtQHqq2QvKExMAGawlx8skkDBl1cy6/AJ02pKP8pj9w=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Mv0ENeSGXzLbVvPFiUO+luAbradBjX44ArhdeCEDw7d0qIdXFEHWUja7A15T4tEMk px8k7rngvNkS1YKSSidFU7Wdgl39TPw5oN9UUmTJjWAwlm2/maJ+Y64yV5GvwTOqqs s25AVXbIGijI1sTe1/6lhcZHCl7wEEVkxTcbMMZQFDvvWKmN+DBhYBfDB7frH//QWF SEIXZMoRXalilba1388nBQwF5IdGjT3JKe7/8XHpfZNJxP9yiuwNvz36Z5M6OewVxa M6u2Wn5++Rc7TUK7H2zZ86V4grLRaFZrF/GBHqA3kdMx2yDndKRvYY5KgG3lk20FFF hhZtRC+DFWkWA== Received: from mail-it1-f170.google.com ([209.85.166.170]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Mon, 11 Mar 2019 23:46:59 +0100 (CET) Received: by mail-it1-f170.google.com with SMTP id x189so1328266itd.3 for ; Mon, 11 Mar 2019 15:46:58 -0700 (PDT) X-Gm-Message-State: APjAAAVb6JGv4WAXGHeeJHXGUKWaWviSfx5FOMvx5Xq+7PVffXdMGFhV 8tr1CfsgC4VyUoIGHNx9/W2lgTjm7aZ5I25Wm/8= X-Google-Smtp-Source: APXvYqw1SLUAlUZlcta3EP/32PFpCUG/bhjotWQ699NvgI//JwDcy/CnKB+C0B0yjla6zTuoGon0WzCxOVWaWGUkCs8= X-Received: by 2002:a02:8c3:: with SMTP id 186mr11961026jac.69.1552344417850; Mon, 11 Mar 2019 15:46:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Remous-Aris Koutsiamanis Date: Mon, 11 Mar 2019 23:47:01 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000985d4b0583d95922" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] ROLL-NSA extension for PRE 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, 11 Mar 2019 22:47:09 -0000 --000000000000985d4b0583d95922 Content-Type: text/plain; charset="UTF-8" Hello, thank you so much Rahul for your very helpful comments. I have responded inline to each. We have also published a new version of the draft taking into account your comments: draft-ietf-roll-nsa-extension-01 https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/ Kind regards, Aris On Sun, Feb 24, 2019 at 6:41 PM Rahul Jadhav wrote: > Hello All, > > Following is my review of draft-ietf-roll-nsa-extension-00: > > PRE could be an interesting technique that can be applied to subset of > traffic which is critical or requires low-latency. The draft talks > about extending NSA to send the node's parent-set in the DIO such that > the receiving child node could use this information to choose the > alternate paths appropriately. > > 1. Section 3 talks about three policies for alternative parent > selection. As i understand different nodes could use any of the > policies (strict, medium, relaxed) without having to worry about > interop. Also it will be optimum to choose strict policy followed by > medium and relaxed respectively. Is this correct? > Yes, your intuition is correct on the interop issue and we have added some clarification in Section 3.4 "Usage". For the method priority, you are correct. First try to find an Alternative Parent (AP) with the strict method, if you fail try the medium and if you still fail try the relaxed. However, this draft only lists these methods as examples to illustrate the use of the proposed PS extension. I think it is out-of-scope to propose a specific algorithm for the AP selection process itself. 2. Regarding compression, i didnt find a dispatch-like bit identifying > whether the PS addresses are compressed or not. Isn't it required for > the recipient to know whether the PS is compressed? > You have a good point. I have implemented this in Contiki and I enable/disable 6LoRH compression of the addresses with a #define. So when enabled, it is ALWAYS used and when disabled it is NEVER used. So in this case all the nodes in the network either use compression or don't. I didn't consider a mixed environment. The problem is that adding a dispatch bit - at a minimum - requires 1 byte. At the same time using 6LoRH compression the overhead is 1 byte, for the 6LoRH type field. So, it is the same and we could just mandate that 6LoRH compression MUST be used. In terms of implementation complexity, this does put an extra burden on implementers, but if someone wants to avoid implementing full 6LoRH compression, and are willing to be less interoperable, they can just support the 6LoRH type = 4 (i.e. full/uncompressed 16 byte IPv6 addresses) with just the 1 byte overhead. Is there a chance someone will object to this 1 byte overhead, when sending even one IPv6 address is so big? I have added a description in Section 4. of how exactly the field is to be laid-out and mandated 6LoRH compression in Section 4.2. 3. Most of the text is 6tisch specific and specifically says 6tisch > nodes whilst explaining the technique. I believe the technique is > generically applicable to non-6tisch scenarios as well. True? > To my mind yes. The idea behind PRE is general and the information in the PS is strictly RPL specific. It does not have a dependency on 6TiSCH. It's just we are implementing and testing on 6TiSCH. I have removed this dependency, although I have left mentions to 6TiSCH. 4. I think a section on reparenting is needed. How would the child > node behave when its parent is reparenting? During reparenting, the > parent might send its updated DIO with its new parent set. The > implications of using CA strict policy in this case might result in > child choosing a different AP which certainly is not desirable if the > parent still has connectivity to its old parent and the reparenting is > done based on metric changes. > The scenario you describe is definitely possible. Depending on the case it might go differently: - While still using strict, select another AP - Fallback to Medium, select the same AP - Fallback to Medium, select another AP - Fallback to Relaxed, select the same AP - Fallback to Relaxed, select another AP It is not clear to me what can be done. Maybe a hysteresis function can be applied to the AP like it is applied to the preferred parent. However, my impression from discussing the draft at the last IETF is that this specific document should be relatively focused on the - relatively small - extension to the MC NSA fields. The issue you highlight is important but I think that either we do another separate document addressing them, or we expand the scope of this document and we cover not only re-parenting but also specific suggestions for AP selection methods and maybe other issues. > 5. I am wondering if it is possible to attach a field "such as > min-priority [1]" field which is a derivative of the metric > calculation in context to every parent in the parent-set. This greatly > helps the child nodes in deciding the CA policy to use even though as > I understand that the parent-set is already attached in NSA in the > decreasing preference order. > This is an interesting idea. If I understand correctly, you would like a value which quantifies how "good/available" each parent in the parent set is. Via [1], you already have this for a node's parent set, with the inclusion of this information in the PS information, we could have this information for each node's grandparent set. While the parents in the PS are ordered, the ordering does not quantify how much better/worse the parents are. An idea would be: We can use one of the unused bits (below P) of the 6LoRH type field (only 5 out of 8 are used) to signify presence of an extra "preference" field. If P=1 then before each address there is a field (say 1 byte) with expresses the "goodness/availability" of the corresponding parent. If P=0, then there is no such field, it's just compressed IP addresses. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |=>MC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res | Flags |A|O| PS type | PS Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=>NSA |P| 6LoRH type | Opt: Pref 1 |IPv6 address 1 .... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Opt: Pref 2 |IPv6 address 2 .... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Opt: Pref 3 |IPv6 address 3 .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alternatively, we can have a second TLV just for the "goodness/availability" which would have an overhead of 2 bytes (for the TLV's Type and Length fields). What are your thoughts? Regards, > Rahul > > [1] draft-richardson-6tisch-roll-enrollment-priority-01 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000985d4b0583d95922 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

thank you so much Rahul for your= very helpful comments. I have responded inline to each.
We have = also published a new version of the draft taking into account your comments: draft-ietf-roll-nsa-extension-01

Kind regards,
Aris

On Sun, Feb 24, 2019 at 6:41 PM Rahul Jadhav <rahul.ietf@gmail.com> wrote:
=
Hello All,

Following is my review of draft-ietf-roll-nsa-extension-00:

PRE could be an interesting technique that can be applied to subset of
traffic which is critical or requires low-latency. The draft talks
about extending NSA to send the node's parent-set in the DIO such that<= br> the receiving child node could use this information to choose the
alternate paths appropriately.

1. Section 3 talks about three policies for alternative parent
selection. As i understand different nodes could use any of the
policies (strict, medium, relaxed) without having to worry about
interop. Also it will be optimum to choose strict policy followed by
medium and relaxed respectively. Is this correct?
=C2= =A0
Yes, your intuition is correct on the interop issue and we ha= ve added some clarification in Section 3.4 "Usage".
For the method priority, you are correct. First try to find an = Alternative Parent (AP) with the strict method, if you fail try the medium = and if you still fail try the relaxed. However, this draft only lists these= methods as examples to illustrate the use of the proposed PS extension.
I think it is out-of-scope to propose a specific algorithm for the = AP selection process itself.

2. Regarding compression, i didnt find a dispatch-like bit identifying
whether the PS addresses are compressed or not. Isn't it required for the recipient to know whether the PS is compressed?
= =C2=A0
You have a good point. I have implemented this in Contiki = and I enable/disable 6LoRH compression of the addresses with a #define.
So when enabled, it is ALWAYS used and when disabled it is NEVE= R used. So in this case all the nodes in the network either use compression= or don't.
I didn't consider a mixed environment.
The problem is that adding a dispatch bit - at a minimum - requires 1 by= te. At the same time using 6LoRH compression the overhead is 1 byte, for th= e 6LoRH type field.
So, it is the same and we could just mandate = that 6LoRH compression MUST be used.
In terms of implementation c= omplexity, this does put an extra burden on implementers, but if someone wa= nts to avoid implementing full 6LoRH compression, and are willing to be les= s interoperable, they can just support the 6LoRH type =3D 4 (i.e. full/unco= mpressed 16 byte IPv6 addresses) with just the 1 byte overhead.
I= s there a chance someone will object to this 1 byte overhead, when sending = even one IPv6 address is so big?

I have added a de= scription in Section 4. of how exactly the field is to be laid-out and mand= ated 6LoRH compression in Section 4.2.

3. Most of the text is 6tisch specific and specifically says 6tisch
nodes whilst explaining the technique. I believe the technique is
generically applicable to non-6tisch scenarios as well. True?

To my mind yes. The idea behind PRE is general and t= he information in the PS is strictly RPL specific. It does not have a depen= dency on 6TiSCH. It's just we are implementing and testing on 6TiSCH.
I have removed this dependency, although I have left mentions to 6= TiSCH.

4. I think a section on reparenting is needed. How would the child
node behave when its parent is reparenting? During reparenting, the
parent might send its updated DIO with its new parent set. The
implications of using CA strict policy in this case might result in
child choosing a different AP which certainly is not desirable if the
parent still has connectivity to its old parent and the reparenting is
done based on metric changes.

The scena= rio you describe is definitely possible. Depending on the case it might go = differently:
- While still using strict, select another AP
<= div>- Fallback to Medium, select the same AP
- Fallback to Medium= , select another AP
- Fallback to Relaxed, select the same AP
=
- Fallback to Relaxed, select another AP

It is not clear to me what can be done. Maybe a hysteresis function = can be applied to the AP like it is applied to the preferred parent. Howeve= r, my impression from discussing the draft at the last IETF is that this sp= ecific document should be relatively focused on the - relatively small - ex= tension to the MC NSA fields.
The issue you highlight is importan= t but I think that either we do another separate document addressing them, = or we expand the scope of this document and we cover not only re-parenting = but also specific suggestions for AP selection methods and maybe other issu= es.
=C2=A0
5. I am wondering if it is possible to attach a field "such as
min-priority [1]" field which is a derivative of the metric
calculation in context to every parent in the parent-set. This greatly
helps the child nodes in deciding the CA policy to use even though as
I understand that the parent-set is already attached in NSA in the
decreasing preference order.

This is an= interesting idea. If I understand correctly, you would like a value which = quantifies how "good/available" each parent in the parent set is.= Via [1], you already have this for a node's parent set, with the inclu= sion of this information in the PS information, we could have this informat= ion for each node's grandparent set. While the parents in the PS are or= dered, the ordering does not quantify how much better/worse the parents are= .
An idea would be:
We can use one of the unused bi= ts (below P) of the 6LoRH type field (only 5 out of 8 are used) to signify = presence of an extra "preference" field.=C2=A0
If P=3D1= then before each address there is a field (say 1 byte) with expresses the = "goodness/availability" of the corresponding parent.
If= P=3D0, then there is no such field, it's just compressed IP addresses.=
=C2=A00=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=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=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A=C2=A0=C2=A0 |=C2= =A0 Prec | Length (bytes)| |=3D>MC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=C2=A0=C2=A0=C2=A0=C2=A0 Res=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Flags=C2=A0=C2=A0=C2=A0 |A|O|=C2=A0=C2= =A0=C2=A0 PS=C2=A0 type=C2=A0=C2=A0 |=C2=A0=C2=A0 PS=C2=A0 Length=C2=A0 | |=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=3D&= gt;NSA
|P| 6LoRH type=C2=A0 | Opt: Pref 1=C2=A0=C2=A0 |IPv6 address 1 ..= .. =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 | |
+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |<= br>| Opt: Pref 2=C2= =A0=C2=A0 |IPv6 address 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 | |
+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + |
| Opt:= Pref 3 =C2=A0 |IPv6 address 3 .... =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2= =A0
Alternatively, we can have a second TLV= just for the "goodness/availability" which would have an overhea= d of 2 bytes (for the TLV's Type and Length fields).

What are your though= ts?


Regards,
Rahul

[1] draft-richardson-6tisch-roll-enrollment-priority-01

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000985d4b0583d95922-- From nobody Tue Mar 12 01:09:04 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 15AE2130F01 for ; Tue, 12 Mar 2019 01:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myoJ7OjK7F7F for ; Tue, 12 Mar 2019 01:09:00 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 12E5B130E64 for ; Tue, 12 Mar 2019 01:09:00 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id h58so1468389edb.5 for ; Tue, 12 Mar 2019 01:08:59 -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=ONcmVtS/XI176xN/ihcifH6vovJ3ZnxducETZe+etag=; b=ChOq4uszKrtYDp4VsrXpg+g4Y7zBR/03rUCHn2d3/dP+T9B4T57xj0CztwOD4pOZnd UZivZ1mv+VT7UaOCRwS40bYrM36OqlHwKKRtsbJRltWzCN2TRbDoLQcJaGEnVqenQC7A HrE1qaxRLD34ku3V/cqmvMR7SijFLC4hRWU4ayKiPrUCxqcyNHrIJyhrpEPyfZEV/zH8 99BNyIEBk6tGW0aXaH6CqpRxwKc0rKsXbA+qW7m5b60Fwf2b/smT64RazfsaMbzd74Da YVAuTxWKlIzeLX1Q93eUX8KtBBDmGXwgedEBc5uxEtOAx+oRsZsKRTifxJtbo242dsnj P+6A== 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=ONcmVtS/XI176xN/ihcifH6vovJ3ZnxducETZe+etag=; b=PlkBPj6y5/ru7lHYuAwUctMsMB5yZmREmiq7RVN+AdfObcKMzRbBIGPFuP/n7X+5lL 9kio/mK4FolBGfArwsQjn9YEqPImvWwYTyaPHAwSa22sL0EDpJlvqNTdqEsIYn3Uqzs0 xetxv9NDGKIuWzVt8gQ7IKYhG/M/lmGRNT0i9uC0C9m+inTN3JoEvFBJF3xX/5z4o3Dm faDIYkCJcugimsUiuJez8GmSxxoSs4vNhfTpJvbA24NP1HyOzf4UgyPmqSe36PuvTXcT xN/uDz8cuxSIentewAwxkhPbNTIUU9MbwSttsZ+P8WowvFrmZ5jtSbLfM5RO5Q83XFnC ZmUQ== X-Gm-Message-State: APjAAAUEM1IxpGm5xgHZn/nU8aOFLTRQ6vQ3t0alIuKjQnwdSGvKaX/T FitRVs8EgNpu515BFm++CBdDclpsPHSAkI2MBKTOIzPG X-Google-Smtp-Source: APXvYqyGImknKgA44driuzs4ezy8/UpmG4FhoN41nG0q2NdWcSoSkQOjrFUDFr8p3xxf8OOS6NpgbvgkfczLhBt8OpY= X-Received: by 2002:a50:976a:: with SMTP id d39mr2379954edb.289.1552378137956; Tue, 12 Mar 2019 01:08:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Tue, 12 Mar 2019 10:08:46 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="0000000000007856200583e133d7" Archived-At: Subject: Re: [Roll] IETF 104 - Agenda published - version 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: Tue, 12 Mar 2019 08:09:02 -0000 --0000000000007856200583e133d7 Content-Type: text/plain; charset="UTF-8" Dear all, Please find an update to the agenda. https://datatracker.ietf.org/meeting/104/materials/agenda-104-roll-01 We have added also the slots assigned to the discussion of RPL-BIER as side meetings that we believe fits better the time to the ones involved, please let us know asap if otherwise. Comments welcome, Cheers, Ines and Peter On Mon, Mar 11, 2019 at 7:22 PM Ines Robles wrote: > Dear all, > > Please find below the link to the agenda for the IETF 104 > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-roll-00 > > Dear presenters, please send us the slides in PDF format before > 22th March. Thank you very much in advance :-) > > Comments welcome, > > Cheers, > > Ines and Peter > --0000000000007856200583e133d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please f= ind an update to the agenda.

<= br>
We have added also the slots assigned to the discussion of RP= L-BIER as side meetings that we believe fits better the time to the ones in= volved, please let us know asap if otherwise.

Comm= ents welcome,

Cheers,

Ine= s and Peter

On Mon, Mar 11, 2019 at 7:22 PM Ines Robles <mariainesrobles@googlemail.c= om> wrote:
Dear all,

Please fin= d below the link to the agenda for the IETF 104

https://datatracker.ietf.org/meeting/104/materials/a= genda-104-roll-00

Dear presenters, please = send us the slides in PDF format before 22th=C2=A0March. Thank you very muc= h in advance :-)

Comments welcome,

<= /div>
Cheers,

Ines and Peter
--0000000000007856200583e133d7-- From nobody Tue Mar 12 02:44: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 24349130F0F for ; Tue, 12 Mar 2019 02:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qF5TVCpXpAON for ; Tue, 12 Mar 2019 02:44:17 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 95B7F130F0B for ; Tue, 12 Mar 2019 02:44:17 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id n17so1650477edt.13 for ; Tue, 12 Mar 2019 02:44:17 -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=yUDFvFKjW0jMa4smliM7aJdQ74EBzD2CWXdbK44KxdM=; b=in4h1BBtSggjLiyr+1vtSWeoI/7bN4Z0bETwpdStf2G+32Lrpgs5icFXxuISFxr3p3 TDZvYjgCMTNZxyfEtbvMZ0AjRCkyFlkdFqabt+MZOdpYSFImcJQMTFeKBaRfL8d9EqZW xnNZ7wAkckLOM3lYvTvTR/YePAoFgtXqyz4qMpvnVbl2RnSES6E4oO9H2fEOyDdXoauh xi/WNmUvfmV9bkNhavw4h5ep6t983ANQDOzbRhGjHVFgJmEB6T6N2KUxMbGDA28JBos+ LXXRAcKBckEu1NqQCw2T+dVV6aTv37BfYySvlS+qnuJmGKmmCG9EF5fFEMMuOhBqYSh+ Ro8Q== 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=yUDFvFKjW0jMa4smliM7aJdQ74EBzD2CWXdbK44KxdM=; b=QiZ5JCDQNAsbvVoWwd74GJCUczmWav/rgGDInhxUKDGHU3hheC6ftAqVWyPuB+1S92 yTDsf40s9MsNMkPH8Vo7uwM6kxmermvXCFgIgpPng4BosVnQo8AHirJ1OBRPGjj2PVhz 33TZVzuR5dWiqvbcFQYa1xkIuoAk6fACKm/mtoqHkw6J40k9KKI/wxq5sHVmdag+tmL6 kCFXMWINlbtZPUWxJ+E9532A0w/2tqQvwcmpHLiC1/NiuN5UfrQnqK/vktgDsl/f/s8v 9R3T0fPKr4VVbA4OXCEaXGHS4OkEaEuk8cZIMUll5dvRXqO4sWnOEaOizuHIS/XSG9U0 y0dw== X-Gm-Message-State: APjAAAVwXSIUR3e9IknHwnYrIsSBH80Ss4enYta1K1yLNXtHxy9HBiwb mXg8XHUSct5u5HdqCayMiIFB5zVFs6wNt9wlrbgquw== X-Google-Smtp-Source: APXvYqzWjElq+kv3hPewNYA5fbJVI7mqzofGh0pmqbqoEIUt7EaqkBMiGz/OKzNUQYgS8StN/J7qdPKfijo8YdJWXow= X-Received: by 2002:a50:ed07:: with SMTP id j7mr2631767eds.168.1552383855528; Tue, 12 Mar 2019 02:44:15 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Tue, 12 Mar 2019 11:44:04 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000438ff60583e28849" Archived-At: Subject: [Roll] Minute Taker - Jabber Scriber for IETF 104 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, 12 Mar 2019 09:44:19 -0000 --000000000000438ff60583e28849 Content-Type: text/plain; charset="UTF-8" Dear all, Please let us know if you could kindly be the Minute Taker or the Jabber Scribe for the IETF 104. Really appreciated :-) Thank you, Ines and Peter. --000000000000438ff60583e28849 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please let us know if you= could kindly be the Minute Taker or the Jabber Scribe for the IETF 104.

Really appreciated :-)

Than= k you,

Ines and Peter.
--000000000000438ff60583e28849-- From nobody Tue Mar 12 03:06:58 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 9D3A9129A85 for ; Tue, 12 Mar 2019 03:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn-7GDTTYlJH for ; Tue, 12 Mar 2019 03:06:54 -0700 (PDT) Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901011274D0 for ; Tue, 12 Mar 2019 03:06:53 -0700 (PDT) Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id 59FBDA08DD; Tue, 12 Mar 2019 11:06:51 +0100 (CET) Received: from smtps.univ-grenoble-alpes.fr (mailhost.u-ga.fr [152.77.1.30]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id 5616AE008F; Tue, 12 Mar 2019 11:06:51 +0100 (CET) Received: from kyushu.imag.fr (kyushu.imag.fr [129.88.55.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: heussem@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id 52355125EC0; Tue, 12 Mar 2019 11:06:51 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Martin Heusse In-Reply-To: Date: Tue, 12 Mar 2019 11:06:51 +0100 Cc: Henry Audeoud Content-Transfer-Encoding: quoted-printable Message-Id: <02772B82-CEFA-464D-8297-58BAAE4FB357@imag.fr> References: To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3445.102.3) X-Greylist: Whitelist-UGA SMTP Authentifie (heussem@univ-grenoble-alpes.fr) via smtps-465 ACL (112) Archived-At: Subject: Re: [Roll] IETF 104 - Agenda published - version 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: Tue, 12 Mar 2019 10:06:56 -0000 Hi Ines,=20 please note that the presenter for = draft-audeoudh-rpl-asymmetric-links-00 will be Henry. M. Heusse > Le 12 mars 2019 =C3=A0 09:08, Ines Robles = a =C3=A9crit : >=20 > Please find an update to the agenda. >=20 From nobody Tue Mar 12 03:24:08 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 22A5012F19D for ; Tue, 12 Mar 2019 03:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW5dbU2c4gbI for ; Tue, 12 Mar 2019 03:24:05 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 33E98129A85 for ; Tue, 12 Mar 2019 03:24:05 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id p27so1786770edc.6 for ; Tue, 12 Mar 2019 03:24:05 -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=M3iCGUOPWNTl3rKJRaHJPRw9LdimAB13aQaLaHSDk/g=; b=slZ8ty63JGLsuqFgz+m9arPRKjyTeHHZjxp2uqHeS8wzSmiOTpMmYB+M0EQ1mVOKmp 2TSf8uhxJqcbJ3/6HD9Y26G6EmbBrogE7twVI2vmVxHtgacWioO1A/1F4o12PGs06E4e GeAbGYoVNDbGY8KL9R704drK+8vSTGlmQS/fN+ZQU2dkjeZ1Dd99h1211g+WEn622Eg8 k/t0vFMVtiDRrrbriiW+kl3sQMwysFdZ9IX8zb/RvRUj3BFcpQZ+CttRCf+zU+hEy68M ht+PRG6cgLEwNDwXkp1FllpAYc9RaB5xH+5575VQ3eWXK5PN7Yd5LXdCLMxH6P5de0qg DMpA== 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=M3iCGUOPWNTl3rKJRaHJPRw9LdimAB13aQaLaHSDk/g=; b=LqhIEVsKOxVp0L9r8FTv+0gnCpHoL8tXaggdayBGtlYP5wDIr84a9agqlOzHHPrayS cj8YbpKJSOOcDaS5Quseqmz8PnUV3IsEOyrTIs2BelnTmfgLuzcDt5j1hOuZ8QqutHHC 3B9IHnuQ8G+dA2UhFssBQ9i01DOtj05n6XedAJgB1SmniMlz01Zx8Ib+tPvjPIEiFeLI G9MIEkz6urP2stn+wayX78ENioXBa1F226KMK/feGGdswZ9TxtSRS+g/fAJnxfH12KC/ a4BsHgFexIyU8lo2mPugips3oMZFrX79Yp1CFFlUDyKFUEVyvYBzzzIZc2PZh4/pT9ei Vmkg== X-Gm-Message-State: APjAAAWuR462BfuWkC+7zuOrpGZItUPWZ9sgB4qyWasjZhcg7MVQN94a sMGZfkZDKYPRyssZLeXzYhQwa3/5azXZLN1EP9hy8guu X-Google-Smtp-Source: APXvYqylAeLBr7pMlC19W9LVBXca6Oni7BwaFS7jiB5YcqjZCx9jSPVCnmMEjp9s9odwsN1U8eV0cdaC1unPYWdzrNc= X-Received: by 2002:aa7:d914:: with SMTP id a20mr2770446edr.167.1552386242678; Tue, 12 Mar 2019 03:24:02 -0700 (PDT) MIME-Version: 1.0 References: <02772B82-CEFA-464D-8297-58BAAE4FB357@imag.fr> In-Reply-To: <02772B82-CEFA-464D-8297-58BAAE4FB357@imag.fr> From: Ines Robles Date: Tue, 12 Mar 2019 12:23:51 +0200 Message-ID: To: Routing Over Low power and Lossy networks Cc: Henry Audeoud , peter van der Stok Content-Type: multipart/alternative; boundary="0000000000008c95080583e316b2" Archived-At: Subject: Re: [Roll] IETF 104 - Agenda published - version 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: Tue, 12 Mar 2019 10:24:07 -0000 --0000000000008c95080583e316b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Martin for let us know, Dear all, please find an updated agenda below: https://datatracker.ietf.org/meeting/104/materials/agenda-104-roll-02 Comments welcome, Ines and Peter On Tue, Mar 12, 2019 at 12:07 PM Martin Heusse wrote: > Hi Ines, > please note that the presenter for draft-audeoudh-rpl-asymmetric-links-00 > will be Henry. > M. Heusse > > > Le 12 mars 2019 =C3=A0 09:08, Ines Robles 40googlemail.com@dmarc.ietf.org> a =C3=A9crit : > > > > Please find an update to the agenda. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0000000000008c95080583e316b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Martin for let us know,
Dear all, please find an updated agenda below:

=
On Tue, Mar 12, 2019 at 12:07 PM Mart= in Heusse <Martin.Heusse@imag.f= r> wrote:
Hi Ines,
please note that the presenter for draft-audeoudh-rpl-asymmetric-links-00 w= ill be Henry.
M. Heusse

> Le 12 mars 2019 =C3=A0 09:08, Ines Robles <mariainesrobles=3D40googlemail= .com@dmarc.ietf.org> a =C3=A9crit :
>
> Please find an update to the agenda.
>

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--0000000000008c95080583e316b2-- From nobody Tue Mar 12 10:08:57 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 DE1FD13107E for ; Tue, 12 Mar 2019 10:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm6IwdxyRhFt for ; Tue, 12 Mar 2019 10:08:54 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 CDB5A130F19 for ; Tue, 12 Mar 2019 10:08:53 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id f19so2938657eds.12 for ; Tue, 12 Mar 2019 10:08:53 -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=YbMmVz2fqcftgBiiqfDoYrSqTi5ml7WikACYZ2pgsBo=; b=gF8QikurHYJAbZCbETuYOlnJ8VM32u6Nd3fmM7Qv1wa3MOtpXqq5Qcuy0q6rwYu9du JdBYNoDQlrzt3r5Lr27pKS9/5Xql96/q4mJZJ4yO7Niji3WjX/a0m3Ck0GPduWRIpqUP eNtbqBF3jbZm2/duKlGbNo6CKH6ss9Gfj7MxCMRUNNha7YArZIQT0sS3qiw2uT3pEFAu /4YyVqdN368Dq8GbPO/8K6SCphXKyasRXxsfpGkJiWpw2Jce256ouIQpSoYpTpa8k3QQ fhSEWVqTVslSJrklPauXkEKN8BFFmjMSgOF2R+Eg4f++qyKCs73Bo7k55ZO24Dr9S0TZ c/lA== 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=YbMmVz2fqcftgBiiqfDoYrSqTi5ml7WikACYZ2pgsBo=; b=uHUrRoT1koh2oTpo61PZbiLemZLlC5MF2KmAhMn/6s778/lNoN66G+QQGEOrNXmCqE BCEpk0ZQpv3tiAa8xg9BfnhTt8TfLJ55rg2vtbxrUUtEX6iRpxR63XF8/NbCOz8U/O8r /FGmiJ0jdxj8ZFFVmLVkixZe4JMHZHK9qr6+Iqo2MWfV6bvl2bAZdRuHv7+rFxL6HgAF KVbANIejf3/SoQAD/RXzEFlJim/Z0wY0jT1qxuAL+bv3GEMwc0RUgQUwJwGvByZPeToI gACYIcYmo0Jb27Hrw4cRoFYyU1O88z3M0Yivl0l9UVbMusKAeLRDmW4L8YDiCazgBIpw AX/w== X-Gm-Message-State: APjAAAXb7gpGhNUDeKb9qUNe5VdG3e9c5NRcz/S4GexJzf0a36SpeqbB AYbA2s1RK3BL72EefAs9jmfYAGsw7rmo2XeiETLUsZry X-Google-Smtp-Source: APXvYqzs4SXU8HrasS9vcLfpJKlLcjGm5mI1jAa85JKmNwKeCcTpIgSH4xTEy7sSVFuTcAtmjgF3mNUJVRI16PY2TiM= X-Received: by 2002:a17:906:70d6:: with SMTP id g22mr26690848ejk.215.1552410531664; Tue, 12 Mar 2019 10:08:51 -0700 (PDT) MIME-Version: 1.0 References: <02772B82-CEFA-464D-8297-58BAAE4FB357@imag.fr> In-Reply-To: From: Ines Robles Date: Tue, 12 Mar 2019 19:08:40 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="00000000000049191a0583e8beae" Archived-At: Subject: Re: [Roll] IETF 104 - Agenda published - version 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: Tue, 12 Mar 2019 17:08:56 -0000 --00000000000049191a0583e8beae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Please find below the link to an updated agenda. https://datatracker.ietf.org/meeting/104/materials/agenda-104-roll-03 We have changed the slots for the RPL-BIER side meeting, we have eliminated the one from Monday at 14hs, since people are not able to attend and created a new one on Wednesday from 15 till 16:30. Comments welcome, Ines and Peter On Tue, Mar 12, 2019 at 12:23 PM Ines Robles wrote: > Thank you Martin for let us know, > > Dear all, please find an updated agenda below: > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-roll-02 > > Comments welcome, > > Ines and Peter > > On Tue, Mar 12, 2019 at 12:07 PM Martin Heusse > wrote: > >> Hi Ines, >> please note that the presenter for draft-audeoudh-rpl-asymmetric-links-0= 0 >> will be Henry. >> M. Heusse >> >> > Le 12 mars 2019 =C3=A0 09:08, Ines Robles > 40googlemail.com@dmarc.ietf.org> a =C3=A9crit : >> > >> > Please find an update to the agenda. >> > >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > --00000000000049191a0583e8beae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

P= lease find below the link to an updated agenda.=C2=A0

<= div>https://datatracker.ietf.org/meeting/104/materials/agenda-104-ro= ll-03

We have changed the slots for the RP= L-BIER side meeting, we have eliminated the one from Monday at 14hs, since = people are not able to attend and created a new one on Wednesday from 15 ti= ll 16:30.

Comments welcome,=C2=A0
Ines and Peter

On Tue, Mar 12, 2019 at 12:23 PM Ines Robles &l= t;mariainesrobles@googlem= ail.com> wrote:
Thank you Martin for let us know,<= div>
Dear all, please find an updated agenda below:


Commen= ts welcome,

Ines and Peter

On Tue, Mar = 12, 2019 at 12:07 PM Martin Heusse <Martin.Heusse@imag.fr> wrote:
Hi Ines,
please note that the presenter for draft-audeoudh-rpl-asymmetric-links-00 w= ill be Henry.
M. Heusse

> Le 12 mars 2019 =C3=A0 09:08, Ines Robles <mariainesrobles=3D40googlemail= .com@dmarc.ietf.org> a =C3=A9crit :
>
> Please find an update to the agenda.
>

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--00000000000049191a0583e8beae-- From nobody Wed Mar 13 03:52: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 6B7B7130EED for ; Wed, 13 Mar 2019 03:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zdByggCZkvJQ for ; Wed, 13 Mar 2019 03:52:19 -0700 (PDT) Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2955A130E8F for ; Wed, 13 Mar 2019 03:52:18 -0700 (PDT) Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id 18838A05E1 for ; Wed, 13 Mar 2019 11:52:17 +0100 (CET) Received: from smtps.univ-grenoble-alpes.fr (smtps1.u-ga.fr [152.77.1.30]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id 144C0E0091 for ; Wed, 13 Mar 2019 11:52:17 +0100 (CET) Received: from patmos.imag.fr (patmos.imag.fr [129.88.55.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: audeoudh@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id 0CB9F125EBA for ; Wed, 13 Mar 2019 11:52:17 +0100 (CET) Date: Wed, 13 Mar 2019 11:52:13 +0100 From: Henry-Joseph =?utf-8?Q?Aud=C3=A9oud?= To: ROLL Message-ID: <20190313105213.GA4953@patmos.imag.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline User-Agent: Mutt/1.11.3 (2019-02-01) X-Greylist: Whitelist-UGA SMTP Authentifie (audeoudh@univ-grenoble-alpes.fr) via smtps-465 ACL (112) Archived-At: Subject: [Roll] Fwd: New Version Notification for draft-audeoudh-rpl-asymmetric-links-00.txt 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, 13 Mar 2019 10:52:21 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear all, We have just submitted a new draft (draft-draft-audeoudh-rpl-asymmetric-links) summarizing some observations we have made on RPL, using the Contiki's implementation. It will be discussed at the ROLL meeting in Prague. Here are the abstract and the links. Best, > Name: draft-audeoudh-rpl-asymmetric-links > Revision: 00 > Title: Experimental observation of RPL: routing protocol overhead and as= ymmetric links > Document date: 2019-03-11 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-audeoudh-rpl-a= symmetric-links-00.txt > Status: https://datatracker.ietf.org/doc/draft-audeoudh-rpl-asymm= etric-links/ > Htmlized: https://tools.ietf.org/html/draft-audeoudh-rpl-asymmetric= -links-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-audeoudh-rpl-= asymmetric-links >=20 >=20 > Abstract: > This document summarizes our observations of the behavior of RPL on a > testbed composed of tens of IEEE 802.15.4 nodes. Our first > observation is that the continuous task of estimating the link metric > to all candidate neighbors causes a significant background load. > This traffic is persistent, even in a stable network where DIO > transmissions are eventually widely spaced. Next, this document > focuses on the case of the presence of an asymmetric link, due to > either a muted or a deaf node. In these circumstances, the standard > RPL mechanisms may well generate hundreds of routing messages per > node and per hour. --=20 Henry-Joseph Aud=C3=A9oud Univ. Grenoble Alpes - Grenoble INP - LIG --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEj/nQzNEBY0JlOinAmLdSqWbHevgFAlyI4NoACgkQmLdSqWbH evhy3BAAmgYcPnRCabzGE9Z2tOLRrQdkzoDBL3bP2yJgQNZIPtwclCREqS2MvwAl 7B8NdzUHrflwZ2Rf5pZQld63fD5n04GW/32g8e1yaPWnUZL6+4sGG6bj0vA1Gl0i GdMa+yeUSf8hhRvL9teAT/iZA9F0HlrAdXqwMjB3rFZhyUt5slDZ79WvOLpYz5zh OW1nQxylOMwfJK9TEt+ZJIsEDKDmJiiGdOXNW7rG6Z4Y/2OYHajt2o20vi3iu2QK 6NLMD+DpoApdGshFZxYAFKCv/woTZPsTuFb8r2oUyImxf5pmZX5TfAxrgyKtf9Vr /217pEtT25vQ26vs9cy0WKPEc2ob94p6bfI4pB4BjgaX6CQ8qwmolRT/TX9lu66O hZqXZFYArBhXsK9pmNhF7mh6F2sTCwuWxIutXH4c9ClGPYuHbr9ehZb3uJ3zM1EW nt/QqHKnH6mgF9plgHSYdQqxXV997zY2RqZKHysWXMhbVARpfiDpXVYBGQHwqvns awceH2BwuVVNd8g/0QCi0F5ybXtpApugmtunWTA3EvpU7kys1H+1t7SA+nDdG1Nz rZLnRh6hvKR4RG6oN/OOO3b8RtjKMT7kcdVWsEoMni/UvhMnolCEi3eQAOcQ7Kpi YcaeTYlbqsWxbB7ILXFmrXM5wdjiZHga9viBFjBOelX5B+7AsMs= =5Ins -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From nobody Wed Mar 13 05:32:48 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 3D990130EFA for ; Wed, 13 Mar 2019 05:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=T6n3YPUO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cwTQ8A77 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 xZkn7vuDjIRT for ; Wed, 13 Mar 2019 05:32:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39580130EBC for ; Wed, 13 Mar 2019 05:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3454; q=dns/txt; s=iport; t=1552480363; x=1553689963; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wXzI39w6KmxyiaGXugb8Gp3TqpqIUj5mQXGTRVrwnS8=; b=T6n3YPUO8R7ZYI+DDpqelQQSfZAVVH/rgIBjCW3281k48H98WtZFh9q5 vwpk8eRRHiVoPDqzqnVYPYjD+IB0hIP53ZrBGNwvqbTzNvJpSXyrxZx1l xqlJZTyX+EsR9CjKghvDlStcaK3NXaACS/+zcCUtGsNKs2pgRc/RV1DVq E=; IronPort-PHdr: =?us-ascii?q?9a23=3AiV/6UhMOD1AJRmUefXIl6mtXPHoupqn0MwgJ65?= =?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?A0A8AAAW94hc/4UNJK1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVAMBAQELAYE8UANodAQLJ4QKg0cDjy5Kgg2YP4EQA1QLAQEjCYR?= =?us-ascii?q?AAheELiI3Bg0BAQMBAQkBAwJtHAyFSgEBAQQjEQwBATUDCwQCAQgRBAEBAwI?= =?us-ascii?q?mAgICMBUICAIEEwiDG4FdAxUBAgyjNwKKFHGBL4J4AQEFgTUCDkGDBBiCDAM?= =?us-ascii?q?FgQskAYssF4FAP4ERRoFOfoIGgRgBAQIBAYElOoMIMYImjFOEJ5M6CQKHU4t?= =?us-ascii?q?ZgXqJLogWkGWMawIEAgQFAg4BAQWBXSKBVnAVGoMNggojE4M4hRSFP3KBKJA?= =?us-ascii?q?bAQE?= X-IronPort-AV: E=Sophos;i="5.58,474,1544486400"; d="scan'208";a="524526978" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Mar 2019 12:32:41 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x2DCWgbH031154 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Mar 2019 12:32:42 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 13 Mar 2019 07:32:41 -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; Wed, 13 Mar 2019 08:32:40 -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; Wed, 13 Mar 2019 07:32:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wXzI39w6KmxyiaGXugb8Gp3TqpqIUj5mQXGTRVrwnS8=; b=cwTQ8A77T0429lWs2KyxbsJb3H1cnLnUADujUdZzeZ8mrdG5jWGEiQ9J41fRid/0yDNR4SrFE7vHpO31rdAn1A9p4RhP3mQZwnYJy9QClD23LzTQXhzzgiIypuVbjXREfWDQ1lr4Ug00TcHCkgmtO6eEpwybA/wqdZC3+ABOU10= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4159.namprd11.prod.outlook.com (20.179.150.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Wed, 13 Mar 2019 12:32:38 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1686.021; Wed, 13 Mar 2019 12:32:38 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Fwd: New Version Notification for draft-audeoudh-rpl-asymmetric-links-00.txt Thread-Index: AQHU2Yrt/gN0+n8FLEW1gq0kbnWMWqYJfRIg Date: Wed, 13 Mar 2019 12:32:10 +0000 Deferred-Delivery: Wed, 13 Mar 2019 12:31:41 +0000 Message-ID: References: <20190313105213.GA4953@patmos.imag.fr> In-Reply-To: <20190313105213.GA4953@patmos.imag.fr> 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=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c0beb65-3fca-42b1-5ebd-08d6a7affad3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB4159; x-ms-traffictypediagnostic: MN2PR11MB4159: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 09752BC779 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(39860400002)(376002)(346002)(13464003)(189003)(199004)(6306002)(305945005)(8676002)(9686003)(6436002)(46003)(7736002)(14444005)(55016002)(33656002)(53936002)(256004)(99286004)(6916009)(229853002)(81156014)(66574012)(81166006)(5660300002)(6506007)(6246003)(8936002)(25786009)(53546011)(74316002)(6666004)(7696005)(68736007)(476003)(102836004)(486006)(966005)(478600001)(76176011)(15650500001)(2906002)(14454004)(186003)(105586002)(11346002)(86362001)(446003)(71200400001)(6116002)(316002)(71190400001)(52536013)(97736004)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4159; 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: +5elOg6X9o50naaIzltKtwCuvdPR+Z0wSUGM45XMdTPnHqvUxdK/lFfQkXopG+TS2pryUAPMW/7ucZ0trp/FNzCgWWrQhzZEHSEj3RXLidpoRphv48cptU/N2rSCkRtTRL0tA/frrLbYLchcYhx4SxkMTc12i0Op3n/xxtL/LMn6oC68Ae4DHD5a7o8wnHFNKIStZbW0mrbnaX6DEDGSWcqXB2WZDdI7tvy7W1MezR42Z46nE/FGjnP1acEtqFecP+rnn9xbWwwLMuXxqZ28mu/mOm4l1aTcRXHaq49+cGifD7MBKO1RkEdd/b9qA8XX6Jpn9dW6kz1Q7CwZDpgy60hSRuoDatJiaBJYxobO4vxkB3ebkNWuCoeTyXyFSTyorLBpeQ2sPz8C2cCVcwC+vvJKgHKaCZLyga66NbB2Gcs= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5c0beb65-3fca-42b1-5ebd-08d6a7affad3 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2019 12:32:38.8045 (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-Transport-CrossTenantHeadersStamped: MN2PR11MB4159 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Roll] Fwd: New Version Notification for draft-audeoudh-rpl-asymmetric-links-00.txt 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, 13 Mar 2019 12:32:47 -0000 TWFueSB0aGFua3MgdG8gdGhlIGF1dGhvcnMsIHRoaXMgaXMgYSBncmVhdCByZWFkLg0KDQpUaGlz IHRlbGxzIG1lIHRoYXQgd2Ugc2hvdWxkIGNvbXBsZXRlIHRoZSB3b3JrIG9uIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtZGlzLW1vZGlmaWNhdGlvbnMgd2hpY2gg d2FzIG1vc3RseSBtaXNzaW5nIGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IChlLmcuLCBuZXR3 b3JrIGJvb3RzdHJhcCB2cy4gbmV3IGNvdW50ZXIgaW4gYW4gZXhpc3RpbmcgbmV0d29yayB1c2Ug Y2FzZXMsIGFuZCBtYXliZSBhbHNvIHJldml2ZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtdGh1YmVydC1yb2xsLWFzeW1saW5rLTAyLi4uIA0KDQpBbGwgdGhlIGJlc3QsDQoNClBh c2NhbA0KDQo+ICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gICBGcm9tOiBSb2xsIDxy b2xsLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBIZW5yeS1Kb3NlcGggQXVkw6lvdWQN Cj4gICBTZW50OiBtZXJjcmVkaSAxMyBtYXJzIDIwMTkgMTE6NTINCj4gICBUbzogUk9MTCA8cm9s bEBpZXRmLm9yZz4NCj4gICBTdWJqZWN0OiBbUm9sbF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWF1ZGVvdWRoLXJwbC0NCj4gICBhc3ltbWV0cmljLWxpbmtzLTAwLnR4 dA0KPiAgIA0KPiAgIERlYXIgYWxsLA0KPiAgIA0KPiAgIFdlIGhhdmUganVzdCBzdWJtaXR0ZWQg YSBuZXcgZHJhZnQNCj4gICAoZHJhZnQtZHJhZnQtYXVkZW91ZGgtcnBsLWFzeW1tZXRyaWMtbGlu a3MpIHN1bW1hcml6aW5nIHNvbWUgb2JzZXJ2YXRpb25zDQo+ICAgd2UgaGF2ZSBtYWRlIG9uIFJQ TCwgdXNpbmcgdGhlIENvbnRpa2kncyBpbXBsZW1lbnRhdGlvbi4NCj4gICBJdCB3aWxsIGJlIGRp c2N1c3NlZCBhdCB0aGUgUk9MTCBtZWV0aW5nIGluIFByYWd1ZS4gIEhlcmUgYXJlIHRoZSBhYnN0 cmFjdCBhbmQNCj4gICB0aGUgbGlua3MuDQo+ICAgDQo+ICAgQmVzdCwNCj4gICANCj4gICANCj4g ICA+IE5hbWU6CQlkcmFmdC1hdWRlb3VkaC1ycGwtYXN5bW1ldHJpYy1saW5rcw0KPiAgID4gUmV2 aXNpb246CTAwDQo+ICAgPiBUaXRsZToJCUV4cGVyaW1lbnRhbCBvYnNlcnZhdGlvbiBvZiBSUEw6 IHJvdXRpbmcgcHJvdG9jb2wgb3ZlcmhlYWQNCj4gICBhbmQgYXN5bW1ldHJpYyBsaW5rcw0KPiAg ID4gRG9jdW1lbnQgZGF0ZToJMjAxOS0wMy0xMQ0KPiAgID4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gICA+IFBhZ2VzOgkJMTANCj4gICA+IFVSTDogICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYXVkZW91ZGgtcnBsLQ0KPiAgIGFz eW1tZXRyaWMtbGlua3MtMDAudHh0DQo+ICAgPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXVkZW91ZGgtcnBsLQ0KPiAgIGFzeW1tZXRyaWMt bGlua3MvDQo+ICAgPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWF1ZGVvdWRoLXJwbC1hc3ltbWV0cmljLQ0KPiAgIGxpbmtzLTAwDQo+ICAgPiBIdG1s aXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1h dWRlb3VkaC1ycGwtDQo+ICAgYXN5bW1ldHJpYy1saW5rcw0KPiAgID4NCj4gICA+DQo+ICAgPiBB YnN0cmFjdDoNCj4gICA+ICAgIFRoaXMgZG9jdW1lbnQgc3VtbWFyaXplcyBvdXIgb2JzZXJ2YXRp b25zIG9mIHRoZSBiZWhhdmlvciBvZiBSUEwgb24gYQ0KPiAgID4gICAgdGVzdGJlZCBjb21wb3Nl ZCBvZiB0ZW5zIG9mIElFRUUgODAyLjE1LjQgbm9kZXMuICBPdXIgZmlyc3QNCj4gICA+ICAgIG9i c2VydmF0aW9uIGlzIHRoYXQgdGhlIGNvbnRpbnVvdXMgdGFzayBvZiBlc3RpbWF0aW5nIHRoZSBs aW5rIG1ldHJpYw0KPiAgID4gICAgdG8gYWxsIGNhbmRpZGF0ZSBuZWlnaGJvcnMgY2F1c2VzIGEg c2lnbmlmaWNhbnQgYmFja2dyb3VuZCBsb2FkLg0KPiAgID4gICAgVGhpcyB0cmFmZmljIGlzIHBl cnNpc3RlbnQsIGV2ZW4gaW4gYSBzdGFibGUgbmV0d29yayB3aGVyZSBESU8NCj4gICA+ICAgIHRy YW5zbWlzc2lvbnMgYXJlIGV2ZW50dWFsbHkgd2lkZWx5IHNwYWNlZC4gIE5leHQsIHRoaXMgZG9j dW1lbnQNCj4gICA+ICAgIGZvY3VzZXMgb24gdGhlIGNhc2Ugb2YgdGhlIHByZXNlbmNlIG9mIGFu IGFzeW1tZXRyaWMgbGluaywgZHVlIHRvDQo+ICAgPiAgICBlaXRoZXIgYSBtdXRlZCBvciBhIGRl YWYgbm9kZS4gIEluIHRoZXNlIGNpcmN1bXN0YW5jZXMsIHRoZSBzdGFuZGFyZA0KPiAgID4gICAg UlBMIG1lY2hhbmlzbXMgbWF5IHdlbGwgZ2VuZXJhdGUgaHVuZHJlZHMgb2Ygcm91dGluZyBtZXNz YWdlcyBwZXINCj4gICA+ICAgIG5vZGUgYW5kIHBlciBob3VyLg0KPiAgIA0KPiAgIC0tDQo+ICAg SGVucnktSm9zZXBoIEF1ZMOpb3VkDQo+ICAgVW5pdi4gR3Jlbm9ibGUgQWxwZXMgLSBHcmVub2Js ZSBJTlAgLSBMSUcNCg== From nobody Fri Mar 15 13:49:06 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 B3E0A130F28; Fri, 15 Mar 2019 13:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9IX8gFicaAd; Fri, 15 Mar 2019 13:48:37 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 45DE61274D0; Fri, 15 Mar 2019 13:48:36 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id m12so8720898edv.4; Fri, 15 Mar 2019 13:48:36 -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=E210ESYiGYpdze7FZhv+9Tl/gsuhdawpxOfw0uYTQwM=; b=eZESQLpOdM/lwoUnhaw13xkOWxCyfS5SYBLp/bNV5gnpdpGIwWHddwi82apVwaD8gL RP2TK3X+QjKqfEV+lfc0+kT0PSbiXUxtGIA3ZMDbYrPBk01WedhJJKPB/GCFk+BCoesC ryS6TZcd49Gq/JUJ5/WsdhOxBWxTUDBb41AOnIdSgF/ZOtu4Yd0RhcIQjPxIgk6UD1L9 3EJM17/j/DQ1vrFrh5Q3hd/84HIfLw/hMMfK6ZadoIjmwwwPKIDsDMN6L/anKbvGd7DZ 2eD9McvFIvTi8NyZ3pAhiuOo9EdGshvDXs2bAmazBHmFbMgEeFwLWMlkJ6cvrQKmAe8L nahA== 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=E210ESYiGYpdze7FZhv+9Tl/gsuhdawpxOfw0uYTQwM=; b=V6whxldWt9a1Uuxa+YPsUwCelCcvlc2RTx3/+u2hQ2fwSA3qi8fWC/B3E9wo5CbPaS 1eRZwidF9M29YbuhjkT2GcvSaC5g67eE84H25if9vOucB76CTQLYxcg43ws3ajWqwUsd urZUneYJnv33JHAnzVNxF94cB5NzL990bfTcJoHhKt7ZNxi/LEy0Ln62GHLKO6zftbSM 20h0T0zjTG+xqYzrz6GAt56FzJ4UhoVyNJzd8vok6FsNZ9Uv1GgrJQJvSDwU9hUJwcuY AWd0Oy5hKFgCseNtrvqv7dsLwASOFhbkvDuxDAYZy936OGwt34Gl70sJiWlTL97+j5os vy8Q== X-Gm-Message-State: APjAAAVveJxeLvAuPKBvck5fgS8j/w+Nc8vt+qqaDOp54YTeOyaRCsBH PfYDkM9RBwORdLz2EAyqMqnqMNoE9BsblolZvOcZ6cWm X-Google-Smtp-Source: APXvYqx9u12tirRg8LFg/6tjdNTRgLsTIMoqC/g+AGF8gxxj08R5hjD8cRCa7VSLzojORvQMMhZZv5j4WgERRrpN5D8= X-Received: by 2002:a17:906:4c82:: with SMTP id q2mr3411451eju.215.1552682914463; Fri, 15 Mar 2019 13:48:34 -0700 (PDT) MIME-Version: 1.0 References: <153427390944.27108.4373520532151309638.idtracker@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Fri, 15 Mar 2019 22:48:22 +0200 Message-ID: To: Alvaro Retana Cc: draft-ietf-roll-useofrplinfo@ietf.org, roll , roll-chairs , Peter van der Stok Content-Type: multipart/alternative; boundary="00000000000090c42f058428298b" Archived-At: Subject: Re: [Roll] Datatracker State Update Notice: 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, 15 Mar 2019 20:48:42 -0000 --00000000000090c42f058428298b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Thanks again for your review. We believe that the new version address all your comments. Please see in-line. On Wed, Jan 30, 2019 at 6:01 PM Alvaro Retana wrote: > On January 23, 2019 at 5:06:24 PM, Ines Robles ( > mariainesrobles@googlemail.com) wrote: > > [Explicitly adding the Chairs, the Shepherd and the Authors=E2=80=99 alia= s=E2=80=A6just > for completeness, even though everyone should be in the WG list and there= =E2=80=99s > overlap. ;-) ] > > Ines: > > Hi! > > I have some comments below, please take a look. Many of these comments > are minor and nits =E2=80=94 the significant items that I think we should= settle on > before starting the IETF LC are: > > - =E2=80=9Cnormative examples=E2=80=9D (point #1 below): I=E2=80=99ll let= you chose how you want > to move forward (see below) > - Operational Considerations (=C2=A79) is WIP > - dependency on I-D.thubert-roll-unaware-leaves (look for line 894) > > Thanks!! > > Alvaro. > > > ... > > (1) [major] Where is the specification of the data-plane behavior? > > >> This document does a couple of things: it Updates several other RFCs, an= d >> presents a list of *example* flows where the expected behavior is >> illustrated. The Updates are mostly about the new RPI value (0x23), but >> not about the behavior of the nodes. >> >> Most of the examples are worded such that they describe actions >> (encapsulate, remove, etc.)...and some even include rfc2119 Normative >> Keywords. But they are called examples! So...my questions are: is the >> behavior illustrated in =C2=A76 and =C2=A77 intended to be Normative? > > > > [authors]The examples are intended to illustrate the result of the > normative language in RFC8200 and RFC6553. > So the examples are intended to be normative explanation of the results o= f > executing that language. > > > >> IOW, do these sections include both examples and specify the behavior >> expected in the LLN? Is the behavior already specified somewhere else (= and >> this document is just illustrating)? > > > [authors]The normative language is in RFC8200 (ipv6bis) section 4.2 and > section 4, =E2=80=9CThe Hop-by-Hop Options=E2=80=A6=E2=80=9D > Combined with the desired results of RFC6553, we conclude that we have t= o > change the option value in order to make things work. > > I understand what you=E2=80=99re trying to do. > To me, a =E2=80=9CNormative example=E2=80=9D is an impossible oxymoron: i= t=E2=80=99s either an > example or it is a Normative specification of the behavior. > > In this document, the scenarios (maybe a better word than example, > specially given how exhaustive the document is in considering all the > possibilities) are not consistently treated as not all of them are > described using Normative language. Being consistent is *very* important > given that we=E2=80=99re dealing with Normative language... > > **But** my heartburn really flares up when you mention "the normative > language in RFC8200...=E2=80=9D because rfc8200 doesn=E2=80=99t use rfc21= 19 keywords at > all. :-( The use of rfc2119 language is a completely separate discussion= , > but using it here as an interpretation of what is meant in rfc8200 is a > stretch=E2=80=A6at least to me. > > What do I want to see? I would prefer to see the scenarios described NOT > using rfc2119 keywords: simply changing the case would be enough. > We did that, changed to non-normative language. > > I don=E2=80=99t want to turn this review into a debate around rfc2119 and= much > less about how to interpret rfc8200. If you really, really prefer to kee= p > the Normative language, please be consistent (use it in all the > scenarios). We can see if anyone else in the IESG picks up on this same > point or not=E2=80=A6 > > ... > > (2) [major] Operational Considerations >> >> Non-storing mode networks don't need the change to 0x23 (=C2=A78.2)...bu= t >> making the change creates a flag day, and even then, implementations sho= uld >> still process both values (=C2=A73.1). I would really like to see text = about >> the operational considerations of introducing 0x23. It concerns me that= a >> significant change that most[*] networks don't need is being introduced. >> Please take a look at rfc5706 (Guidelines for Considering Operations and >> Management of New Protocols and Protocol Extensions), specially =C2=A72. >> >> [*] Most deployed networks work in non-storing mode, right? >> > > [authors]following our understanding, mostly yes. > but, e.g. Anima network in storing mode. Not having loop detection. > > https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-18#s= ection-6.11.1.3 > > > Thanks for including Operational Considerations. =C2=A78 looks good to m= e=E2=80=A6and > I see that =C2=A79 is still WIP. > Operational considerations is completed now. > > ... > > [nit] I think the Introduction would benefit from an overview of the >> document; something like "section X talks about abc, section Y presents >> examples, etc.". > > > [authors]added > > This new section mentions the old =C2=A79. > fixed > > ... > > 187 Flag day: A "flag day" is a procedure in which the network, or a pa= rt >> 188 of it, is changed during a planned outage, or suddenly, causing an >> 189 outage while the network recovers [RFC4192] >> >> [nit] rfc4192 seems like an odd place to pull a reference to "flag day" >> -- specially as it is being defined as "a procedure" and not the effect = it >> causes, which seems to be how it is used in the text: "creates a flag da= y", >> "will experience a flag day", "avoid a flag day". This is not a big iss= ue >> -- if it was up to me, I would either make my own definition, or just no= t >> define it at all: I think it is a well known term... >> > > [authors]fixed. rewritten > > New text: > > 217 Flag Day: A transition that involves have a network with different > 218 values of RPL Option Type. Thus the network do not work correctly= . > > s/involves have a network/involves having a network > > s/network do not work/network does not work > > Also, the reference to rfc4192 is not needed anymore. > Thanks, fixed > > ... > > ... > > 266 When forwarding packets, implementations SHOULD use the same value = as >> 267 it was received (This is required because, RPI type code can not b= e >> 268 changed by [RFC8200]). It allows to the network to be incremental= ly >> 269 upgraded, and for the DODAG root to know which parts of the networ= k >> 270 are upgraded. >> >> [major] There seems to be a contradiction above: "SHOULD use the same >> value...this is required..." If required by rfc8200, why not use MUST? >> > [authors]rewritten > >> >> 272 When originating new packets, implementations SHOULD have an optio= n >> 273 to determine which value to originate with, this option is >> controlled >> 274 by the DIO option described below. >> >> [minor] =C2=A73.3 defines the option...but it doesn't explicitly say wha= t the >> receivers should do with it. It may be obvious, but it should be explic= it >> for completeness. >> > [authors]rewritten > >> >> [major] It seems to me that the paragraph above may be out of place, >> doesn't say much, may be wrong...or maybe all 3. The text says that the >> originating value is controlled by the option in =C2=A73.3 (again, but t= hat >> section doesn't explicitly say what should be done)...but it also says >> (with the SHOULD) that an implementation may have valid reasons to not p= ay >> attention to the option -- what are those?? >> > > [authors]rewritten to > "In the cases where a forwarding node is forwarding traffic that is not > addressed directly to it (such as when the outer IPv6-in-IPv6 > header is not a Link-Local address), > then RFC8200 forbids changing the RPI type code when forwardin= g. > > When forwarding traffic that is wrapped in Link-Local > IPv6-in-IPv6 headers, > the forwarding node is in effect originating new packets, > and it MAY make a choice as to whether to use the old (0x63) > RPI Type code, > or the new (0x23) RPI Type code. In that situation, > implementations SHOULD > use the same value as was received. This allows to the networ= k > to be incrementally upgraded, > and in some cases may allow the DODAG root to know which parts > of the network are upgraded." > > Ok, that looks good. > > You also added: > > 323 Non-constrained uses of RPL are not in scope of this document, and > 324 applicability statements for those uses MAY provide different advi= ce, > 325 E.g. [I-D.ietf-anima-autonomic-control-plane]. > > If out of scope, don=E2=80=99t use Normative language there. > Thanks, fixed > > ... > > 613 Figure 7: IP-in-IP encapsulation in Storing mode. > > > > [nit] The table above is called Figure=E2=80=A6 There are also some Table= s. Maybe > be consistent about what is called a Table and what is called a Figure. > Personally, I don=E2=80=99t care=E2=80=A6I just would prefer consistency. > We used artwork, to display a nice table , based on the xml2rfc FAQ "Note: for tables that are more complex, inserting the table as a figure (i.e., inside of
tags) might be the best option." [ https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html]. We additionally, added some clarification in the text. > > ... > > 894 Note that there is a requirement that the final node be able to > > 895 remove one or more IP-in-IP headers which are all addressed to it, >> 896 mentioned in [I-D.thubert-roll-unaware-leaves] : >> >> 898 "RPL data packets are often encapsulated using IP in IP. The 6LN >> 899 MUST be able to decapsulate a packet when it is the destination of >> 900 the outer header and process correctly the inner header." >> >> [major] I realize that we're not reviewing >> I-D.thubert-roll-unaware-leaves at this point, but how can a requirement= be >> placed on a not-RPL-aware-leaf if, by definition, it is not aware of RPL= ?? >> ...and I don't think we can assume it is aware of any other requirement= ... >> > [authors] We understand that the requirements are placed on the 6LR that > accepts the 6LN > registration and also inject the relevant routing information on its > behalf. > > The text above talks abut the 6LN, not the 6LR. > > If this document depends on the requirement in >> I-D.thubert-roll-unaware-leaves, then the reference should be Normative = (it >> is now listed as Informative). >> > [authors]fixed > > I still don=E2=80=99t feel too good about depending on requirements for > not-RPL-aware nodes in the network=E2=80=A6. In this case, this document = will not > be able to be published as an RFC until that *individual* draft is > published. Is that what you want? Is there any way to work around this > dependency? Why isn=E2=80=99t rfc8200 support enough in this case? > Thanks, fixed. The new paragraph does not depend of this document, it states: The final node should be able to remove one or more IPv6-in-IPv6 headers which are all addressed to it. Furhter details about this are mentioned in [I-D.thubert-roll-unaware-leaves ], which specifies RPL routing for a 6LN acting as a plain host and not aware of RPL. > ... > > 1194 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root >> >> 1196 In non-storing mode the leaf node uses default routing to send >> 1197 traffic to the root. The RPI header must be included to >> avoid/detect >> 1198 loops. >> >> [major] Should that "must" be Normative? >> > [authors] fixed. > > 1322 In non-storing mode the leaf node uses default routing to send > 1323 traffic to the root. The RPI header MUST be included since conta= ins > 1324 the rank information, which is used to avoid/detect loops. > > s/be included since contains/be included since it contains > Fixed. > ... > > 1254 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf > > ... >> 1267 In 6LBR the RH3 is added, it is modified at each intermediate 6LR >> 1268 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n= ), >> 1269 but left there. If RPI is left present, the IPv6 node which does >> not >> 1270 understand it will ignore it (following RFC8200), thus >> encapsulation >> 1271 is not necesary. Due the complete knowledge of the topology at t= he >> 1272 root, the 6LBR may optionally address the IP-in-IP header to the >> last >> 1273 6LR, such that it is removed prior to the IPv6 node. >> >> s/necesary/necessary >> >> [major] So...encapsulation is not needed, but an IP-in-IP header is >> optional. When? Are there advantages, disadvantages? Same questions >> about the RPI. >> > [authors]rewritten. > > s/Due the complete/Due to the complete > Fixed > > ... > > 1731 9. 6LoRH Compression cases > > >> 1733 The [RFC8138] proposes a compression method for RPI, RH3 and >> IPv6-in- >> 1734 IPv6. >> >> 1736 In Storing Mode, for the examples of Flow from RPL-aware-leaf to >> non- >> 1737 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf >> comprise >> 1738 an IP-in-IP and RPI compression headers. The type of this case i= s >> 1739 critical since IP-in-IP is encapsulating a RPI header. >> >> 1741 >> +--+-----+---+--------------+-----------+-------------+-------------+ >> 1742 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN >> IPHC | >> 1743 >> +--+-----+---+--------------+-----------+-------------+-------------+ >> >> 1745 Figure 9: Critical IP-in-IP (RPI). >> >> [major] Shouldn't this section also be an Update to rfc8138? >> >> [major] 6LoRH Type 6 is defined in rfc8138 as an elective type, but it i= s >> introduced as Critical here. The header must then be completely specifi= ed >> in this document and the appropriate registry must be updated (in the IA= NA >> Consideration section). >> >> Specifically...referring to rfc8138... >> - the meaning of the TSE depends on the Type (=C2=A74.2), >> - the Hop Limit is defined in =C2=A77, should it have the same >> behavior/meaning here? >> - does the "RPI - 6LoRH" field correspond to the RPI-6LoRH header >> (=C2=A76.3)? >> - I'm assuming that the "LOWPAN IPHC" field refers to LOWPAN_IPHC >> (rfc6282). >> > > [authors] we think that the confusion is because we wrote: =E2=80=9CThe t= ype of > this case=E2=80=9D... > which sounds like we are changing 8138, when what we mean is that use of > this elective type is a MUST for RPL. > Type 6 (compressed RPI) is elective in 8138 because non-RPL uses of > 6lowpan do not > need to support (compressed) RPI headers, but this document makes it a > MUST because > RPL uses of 6lowpan need it. Is there text that we need to update? > > I see that you moved this text to =C2=A73.2. The Figure (now 3) is still > labeled as =E2=80=9Ccritical=E2=80=9D. > figure fixed. > > ... >> 1774 11. Security Considerations > > > Your responses to trisection indicated several times =E2=80=9CDiscussion = on the > list=E2=80=9D, but I could=E2=80=99t find those discussions. Did they ha= ppen already? > > I would prefer it if the document has mitigation suggestions (at least) i= n > it; that usually makes the SecDir happier. ;-) But that is not an absolu= te > requirement before moving this document forward. > We added new paragraph based on the comment of the ML. If an attack comes from inside of LLN, it can be alleviated with SAVI (Source Address Validation Improvement) using [RFC8505 ] with [I-D.ietf-6lo-ap-nd ]. The attacker will not be able to source with an address that is not registered, and the registration checks for topological correctness. Notice that there is an L2 authentication in most of the cases. If an attack comes from outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, but RH3 is protected by its definition. > ... > > [major] What does "SHOULD be suspicious" mean? How is that a Normative >> behavior? Would being suspicious include dropping the packet or some ot= her >> similar action? When would the router *not* be suspicious? Why is that >> not a "MUST"? > > > [authors]The presence of the second RH3 means that there is a configurati= on > mistake somewhere else in the network. It would be reasonable to > increment > a counter in a MIB (if we had a MIB) when this occurs. Based upon the > Postel > doctrine, ignoring the extra header (not acting on it), is the best > policy. > An RH3 header was not completely consumed is discussed in RFC > > https://tools.ietf.org/html/rfc6554#section-4.2 says that an RH3 header > with > additional =E2=80=9Cnon-zero Segments Left value, if the IPv6 Destinatio= n Address > is > not on-link=E2=80=9D should be dropped. In this case, the RH3 header i= s *inside* > the outer IPv6-in-IPv6 header, which has then been forwarded. > We think that this header should simply be ignored in processing the > packet. > To do otherwise (such as forwarding) would permit external attackers to > send > traffic that appears to originate inside the LLN. > > To be discussed on list > > Ok=E2=80=A6whatever the outcome is, to =E2=80=9Cbe suspicious=E2=80=9D is= not something that can > be enforced normatively. SHOULD log and error, etc..is something > actionable. > fixed. Thank you very much Alvaro again, Ines. --00000000000090c42f058428298b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Alvaro,

=
=C2=A0Thanks again for your review. We believe that the new vers= ion address all your comments. Please see in-line.

On Wed, Jan 30, 201= 9 at 6:01 PM Alvaro Retana <ar= etana.ietf@gmail.com> wrote:
On January 23, 2019 at 5:06:24= PM, Ines Robles (mariainesrobles@googlemail.com) wrote:

[Explicitly adding the Chairs, the Shep= herd and the Authors=E2=80=99 alias=E2=80=A6just for completeness, even tho= ugh everyone should be in the WG list and there=E2=80=99s overlap. ;-) =C2= =A0]

Ines:

Hi!

I have some comments below, please take a = look.=C2=A0 Many of these comments are minor and nits =E2=80=94 the signifi= cant items that I think we should settle on before starting the IETF LC are= :

=
- =E2=80=9Cnormat= ive examples=E2=80=9D (point #1 below): I=E2=80=99ll let you chose how you = want to move forward (see below)
- Operational Considerations (=C2=A79) is WIP
- dependency on=C2= =A0I-D.thubert-roll-unaware-leaves (look for line 894)

Thanks!!

Alvaro.


...
=
<= div dir=3D"ltr">
(1) [major] Where is= the specification of the data-plane behavior?

This document does a couple of things= : it Updates several other RFCs, and presents a list of *example* flows whe= re the expected behavior is illustrated.=C2=A0 The Updates are mostly about= the new RPI value (0x23), but not about the behavior of the nodes.

= Most of the examples are worded such that they describe actions (encapsulat= e, remove, etc.)...and some even include rfc2119 Normative Keywords.=C2=A0 = But they are called examples!=C2=A0 So...my questions are: is the behavior = illustrated in =C2=A76 and =C2=A77 intended to be Normative?=C2=A0


[authors]The examples are intended to illustrate= the result of the normative language in RFC8200 and RFC6553.
So = the examples are intended to be normative explanation of the results of exe= cuting that language.=C2=A0

=C2=A0=C2=A0
IOW, do these sections = include both examples and specify the behavior expected in the LLN?=C2=A0 I= s the behavior already specified somewhere else (and this document is just = illustrating)?

[authors]The normative = language is in RFC8200 (ipv6bis) section 4.2 and section 4, =E2=80=9CThe Ho= p-by-Hop Options=E2=80=A6=E2=80=9D
Combined with the desired resu= lts of=C2=A0 RFC6553, we conclude that we have to change the option value i= n order to make things work.

I understand what you=E2=80=99re = trying to do.

To me, a =E2=80=9CNormative example=E2=80=9D is an im= possible oxymoron: it=E2=80=99s either an example or it is a Normative spec= ification of the behavior. =C2=A0

In this document= , the scenarios (maybe a better word than example, specially given how exha= ustive the document is in considering all the possibilities) are not consis= tently treated as not all of them are described using Normative language.= =C2=A0 Being consistent is *very* important given that we=E2=80=99re dealin= g with Normative language...

**But** my heartburn = really flares up when you mention "the normative language in RFC8200..= .=E2=80=9D because rfc8200 doesn=E2=80=99t use rfc2119 keywords at all. :-(= =C2=A0The use of rfc2119 language is a completely separate discussion, but= using it here as an interpretation of what is meant in rfc8200 is a stretc= h=E2=80=A6at least to me.

What do I want to = see?=C2=A0 I would prefer to see the scenarios described NOT using rfc2119 = keywords: simply changing the case would be enough.

We did that, changed to non-normative language.=C2=A0<= /div>

I don=E2=80=99t want to turn this= review into a debate around rfc2119 and much less about how to interpret r= fc8200.=C2=A0 If you really, really prefer to keep the Normative language, = please be consistent (use it in all the scenarios).=C2=A0 We can see if any= one else in the IESG picks up on this same point or not=E2=80=A6
=

...

<= div dir=3D"ltr">
(2) [major] Opera= tional Considerations

Non-storing mode networks don't need the c= hange to 0x23 (=C2=A78.2)...but making the change creates a flag day, and e= ven then, implementations should still process both values (=C2=A73.1).=C2= =A0 I would really like to see text about the operational considerations of= introducing 0x23.=C2=A0 It concerns me that a significant change that most= [*] networks don't need is being introduced.=C2=A0 Please take a look a= t rfc5706 (Guidelines for Considering Operations and Management of New Prot= ocols and Protocol Extensions), specially =C2=A72.

[*] Most deployed= networks work in non-storing mode, right?

<= div>[authors]following our understanding, mostly yes.
but, e.g. A= nima network in storing mode. Not having loop detection.
=
=
=

Thanks = for including Operational Considerations. =C2=A0=C2=A78 looks good to me=E2= =80=A6and I see that =C2=A79 is still WIP.

Operational considerations is completed now.=C2=A0
=


...

[ni= t] I think the Introduction would benefit from an overview of the document;= something like "section X talks about abc, section Y presents example= s, etc.".

[authors]added=C2=A0

= This new section mentions the old =C2=A79.

fixed=C2=A0


...

187=C2=A0 =C2=A0Flag day: A= "flag day" is a procedure in which the network, or a part
188= =C2=A0 =C2=A0of it, is changed during a planned outage, or suddenly, causin= g an
189=C2=A0 =C2=A0outage while the network recovers [RFC4192]

= [nit] rfc4192 seems like an odd place to pull a reference to "flag day= " -- specially as it is being defined as "a procedure" and n= ot the effect it causes, which seems to be how it is used in the text: &quo= t;creates a flag day", "will experience a flag day", "a= void a flag day".=C2=A0 This is not a big issue -- if it was up to me,= I would either make my own definition, or just not define it at all: I thi= nk it is a well known term...

[authors]= fixed. rewritten=C2=A0

New text:

217	   Flag Day: A transiti=
on that involves have a network with different
218	   values of RPL Option Type.  Thus the network do not work correctly.

s/involves have a network/involves having a network

s/networ= k do not work/network does not work

Also, the reference to rfc4192 is= not needed anymore.

Tha= nks, fixed=C2=A0
...
<= div dir=3D"ltr">
...
266=C2=A0 =C2=A0When forwarding pack= ets, implementations SHOULD use the same value as
267=C2=A0 =C2=A0it was= received (This is required because, RPI type code can not be
268=C2=A0 = =C2=A0changed by [RFC8200]).=C2=A0 It allows to the network to be increment= ally
269=C2=A0 =C2=A0upgraded, and for the DODAG root to know which part= s of the network
270=C2=A0 =C2=A0are upgraded.

[major] There seem= s to be a contradiction above: "SHOULD use the same value...this is re= quired..."=C2=A0 =C2=A0If required by rfc8200, why not use MUST?
[authors]rewritten=C2=A0

272=C2=A0 =C2=A0When originating new packets, impl= ementations SHOULD have an option
273=C2=A0 =C2=A0to determine which val= ue to originate with, this option is controlled
274=C2=A0 =C2=A0by the D= IO option described below.

[minor] =C2=A73.3 defines the option...bu= t it doesn't explicitly say what the receivers should do with it.=C2=A0= It may be obvious, but it should be explicit for completeness.
[authors]rewritten=C2=A0

[major] It seems to me that the paragraph above may be o= ut of place, doesn't say much, may be wrong...or maybe all 3.=C2=A0 The= text says that the originating value is controlled by the option in =C2=A7= 3.3 (again, but that section doesn't explicitly say what should be done= )...but it also says (with the SHOULD) that an implementation may have vali= d reasons to not pay attention to the option -- what are those??

[authors]rewritten to
"In the case= s where a forwarding node is forwarding traffic that is not
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addressed directly to it (such as whe= n the outer IPv6-in-IPv6 header is not a Link-Local address),
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then RFC8200 forbids changing the RPI= type code when forwarding.

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0When forwarding traffic that is wrapped in Link-Local I= Pv6-in-IPv6 headers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the= forwarding node is in effect originating new packets,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and it MAY make a choice as to whether to us= e the old (0x63) RPI Type code,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0or the new (0x23) RPI Type code. In that situation, implementatio= ns SHOULD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use the same v= alue as was received.=C2=A0 This allows to the network to be incrementally = upgraded,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and in some ca= ses may allow the DODAG root to know which parts of the network are upgrade= d."=C2=A0
<= /div><= /div><= /div>=

Ok, that looks good.

You also added:

32=
3	   Non-constrained uses of RPL are not in scope of this document, and
324	   applicability statements for those uses MAY provide different advice=
,
325	   E.g.  [I-D.ietf-anima-autonomic-control-plane].

If out of scope, don=E2=80=99t use Normative language there.


Thanks, fixed=C2=A0
=

...
=
<= div dir=3D"ltr">
=
<= div dir=3D"ltr">
=
<= div dir=3D"ltr">
=
<= div dir=3D"ltr">
613=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fig= ure 7: IP-in-IP encapsulation in Storing mode.
<= /div>
<= /div>
<= /div>

=
=
=
<= /div><= /div><= /div>

[ni= t] The table above is called Figure=E2=80=A6 There are also some Tables.=C2= =A0 Maybe be consistent about what is called a Table and what is called a F= igure.=C2=A0 Personally, I don=E2=80=99t care=E2=80=A6I just would prefer c= onsistency.

We used artwork, to display a=C2=A0 nice table , based on = the xml2rfc FAQ "Note: for tables that are more complex,= inserting the table as a figure (i.e., inside of <figure> <artwor= k> tags) might be the best option." [https://xml2rfc.tools.ietf.org/xml2rfcF= AQ.html]. We additionally, added some clarification in the text.=C2=A0<= /div>

...=
894=C2=A0 =C2=A0Note that there is= a requirement that the final node be able to
895=C2=A0 =C2=A0remove one or more IP-in-I= P headers which are all addressed to it,
896=C2=A0 =C2=A0mentioned in [I= -D.thubert-roll-unaware-leaves] :

898=C2=A0 =C2=A0"RPL data pac= kets are often encapsulated using IP in IP.=C2=A0 The 6LN
899=C2=A0 =C2= =A0MUST be able to decapsulate a packet when it is the destination of
90= 0=C2=A0 =C2=A0the outer header and process correctly the inner header."= ;

[major] I realize that we're not reviewing I-D.thubert-roll-un= aware-leaves at this point, but how can a requirement be placed on a not-RP= L-aware-leaf if, by definition, it is not aware of RPL??=C2=A0 =C2=A0...and= I don't think we can assume it is aware of any other requirement...
[authors] We understand that the requirements are placed= on the 6LR that accepts the 6LN
=C2=A0 =C2=A0registration and al= so inject the relevant routing information on its behalf.=C2=A0
=
= = =

The = text above talks abut the 6LN, not the 6LR.

If this document depends on the requirement in I-D.thubert-ro= ll-unaware-leaves, then the reference should be Normative (it is now listed= as Informative).
[authors]fixed=C2=A0
<= /div>
<= /div>
<= /div>

I still = don=E2=80=99t feel too good about depending on requirements for not-RPL-awa= re nodes in the network=E2=80=A6. In this case, this document will not be a= ble to be published as an RFC until that *individual* draft is published.= =C2=A0 Is that what you want?=C2=A0 Is there any way to work around this de= pendency?=C2=A0 Why isn=E2=80=99t rfc8200 support enough in this case?

<= /div>
Thanks, fi= xed. The new paragraph does not depend of this document, it states:

T=
he final node should be able to remove one or more IPv6-in-IPv6
   headers which are all addressed to it.  Furhter details about this
   are mentioned in [I-D.thubert-roll-unaware-leaves], which specifi=
es
   RPL routing for a 6LN acting as a plain host and not aware of RPL.

=


...

=
1194 7.1.1.=C2=A0 Non-SM: Example of Flow from RPL-awa= re-leaf to root

1196=C2=A0 =C2=A0In non-storing mode the leaf node u= ses default routing to send
1197=C2=A0 =C2=A0traffic to the root.=C2=A0 = The RPI header must be included to avoid/detect
1198=C2=A0 =C2=A0loops.<= br>
[major] Should that "must" be Normative?
<= div>[authors] fixed.=C2=A0
<= /div>
<= /div>
<= /div>
<= /div>
1322	   In non-storing mode the leaf no=
de uses default routing to send
1323	   traffic to the root.  The RPI header MUST be included since contain=
s
1324	   the rank information, which is used to avoid/detect loops.

= s/be included since contains/be included since it contains

<= /div>
Fixed.=C2=A0

...

<= div>
1254 7.1.3.=C2=A0 Non-SM: Example of Flow= from root to not-RPL-aware-leaf
...
1267=C2=A0 =C2=A0In 6LBR the RH3 is added, it is= modified at each intermediate 6LR
1268=C2=A0 =C2=A0(6LR_1 and so on) an= d it is fully consumed in the last 6LR (6LR_n),
1269=C2=A0 =C2=A0but lef= t there.=C2=A0 If RPI is left present, the IPv6 node which does not
1270= =C2=A0 =C2=A0understand it will ignore it (following RFC8200), thus encapsu= lation
1271=C2=A0 =C2=A0is not necesary.=C2=A0 Due the complete knowledg= e of the topology at the
1272=C2=A0 =C2=A0root, the 6LBR may optionally = address the IP-in-IP header to the last
1273=C2=A0 =C2=A06LR, such that = it is removed prior to the IPv6 node.

s/necesary/necessary

[m= ajor] So...encapsulation is not needed, but an IP-in-IP header is optional.= =C2=A0 When?=C2=A0 Are there advantages, disadvantages?=C2=A0 =C2=A0Same qu= estions about the RPI.
[authors]rewritten.=C2=A0
=
=
=
=
<= p>s/Due the complete/Due to the complete

<= /div>
Fixed=C2=A0


...

=
1731 9.=C2=A0 6LoRH Compression cases

1733=C2=A0 = =C2=A0The [RFC8138] proposes a compression method for RPI, RH3 and IPv6-in-=
1734=C2=A0 =C2=A0IPv6.

1736=C2=A0 =C2=A0In Storing Mode, for the= examples of Flow from RPL-aware-leaf to non-
1737=C2=A0 =C2=A0RPL-aware= -leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
1738=C2=A0 = =C2=A0an IP-in-IP and RPI compression headers.=C2=A0 The type of this case = is
1739=C2=A0 =C2=A0critical since IP-in-IP is encapsulating a RPI heade= r.

1741=C2=A0 =C2=A0+--+-----+---+--------------+-----------+-------= ------+-------------+
1742=C2=A0 =C2=A0|1 | 0|0 |TSE| 6LoRH Type 6 | Hop= Limit | RPI - 6LoRH | LOWPAN IPHC |
1743=C2=A0 =C2=A0+--+-----+---+----= ----------+-----------+-------------+-------------+

1745=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 9: Criti= cal IP-in-IP (RPI).

[major] Shouldn't this section also be an Up= date to rfc8138?

[major] 6LoRH Type 6 is defined in rfc8138 as an el= ective type, but it is introduced as Critical here.=C2=A0 The header must t= hen be completely specified in this document and the appropriate registry m= ust be updated (in the IANA Consideration section).

Specifically...r= eferring to rfc8138...
=C2=A0 =C2=A0- the meaning of the TSE depends on = the Type (=C2=A74.2),
=C2=A0 =C2=A0- the Hop Limit is defined in =C2=A77= , should it have the same behavior/meaning here?
=C2=A0 =C2=A0- does the= "RPI - 6LoRH" field correspond to the RPI-6LoRH header (=C2=A76.= 3)?
=C2=A0 =C2=A0- I'm assuming that the "LOWPAN IPHC" fie= ld refers to LOWPAN_IPHC (rfc6282).

[au= thors] we think that the confusion is because we wrote: =E2=80=9CThe type o= f this case=E2=80=9D...
which sounds like we are changing 8138, w= hen what we mean is that use of this elective type is a MUST for RPL.
=
Type 6 (compressed RPI) is elective in 8138 because non-RPL uses of 6l= owpan do not
need to support (compressed) RPI headers, but this d= ocument makes it a MUST because
RPL uses of 6lowpan need it. Is t= here text that we need to update?=C2=A0
=
=
=
=
<= /div>

I see that you moved this text to =C2=A73.2.=C2=A0 The Figure= (now 3) is still labeled as =E2=80=9Ccritical=E2=80=9D.

figure fixed.=C2=A0

=
...
1774 11.=C2=A0 Security Considerati= ons


<= /div>
<= /div>
<= /div>
<= /span>
Your responses to trisection indicated several time= s =E2=80=9CDiscussion on the list=E2=80=9D, but I could=E2=80=99t find thos= e discussions.=C2=A0 Did they happen already? =C2=A0

I would prefer it if the document has mitigation suggestions (at least) = in it; that usually makes the SecDir happier. ;-) =C2=A0But that is not an = absolute requirement before moving this document forward.
=

We added new paragraph based o= n the comment of the ML.=C2=A0



   If an attack comes from inside of LLN, it can be alleviated with SAVI
   (Source Address Validation Improvement) using [RFC8505] with
   [I-D.ietf-6lo-ap-nd].  The atta=
cker will not be able to source with
   an address that is not registered, and the registration checks for
   topological correctness.  Notice that there is an L2 authentication
   in most of the cases.  If an attack comes from outside LLN IPv6-in-
   IPv6 can be used to hide inner routing headers, but RH3 is protected
   by its definition.

<= /div>
...
[major] What does &q= uot;SHOULD be suspicious" mean?=C2=A0 How is that a Normative behavior= ?=C2=A0 Would being suspicious include dropping the packet or some other si= milar action?=C2=A0 When would the router *not* be suspicious?=C2=A0 Why is= that not a "MUST"?
=C2=A0
[authors]Th= e presence of the second RH3 means that there is a configuration
= =C2=A0mistake somewhere else in the network.=C2=A0 It would be reasonable t= o increment
=C2=A0 a counter in a MIB (if we had a MIB) when this= occurs.=C2=A0 Based upon the Postel
=C2=A0 =C2=A0doctrine, ignor= ing the extra header (not acting on it), is the best policy.
<= /div>
<= /div>
<= /div>
<= /div>

Ok=E2=80=A6whatever the outcome is, to = =E2=80=9Cbe suspicious=E2=80=9D is not something that can be enforced norma= tively.=C2=A0 SHOULD log and error, etc..is something actionable.

=

=
Thank you very much Alvaro again,

Ines.
= --00000000000090c42f058428298b-- From nobody Fri Mar 15 16:22:57 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 DAAC112008A for ; Fri, 15 Mar 2019 16:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kcl.ac.uk 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 p-DZ9M0-OSxq for ; Fri, 15 Mar 2019 16:22:51 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150120.outbound.protection.outlook.com [40.107.15.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267F612787D for ; Fri, 15 Mar 2019 16:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kcl.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ExdpcZ79X0b4O68HGPvC58sFcxszuA/jFXcYxE91eGA=; b=avaYT9SmFV1g6sRI66iwsEmiwqElpwOUw/iQCIhKsTO2sNpfsfBwdTV7fQuYUqkuIetAAymTFmS/Ptpq9t6OX/PsErv+umjQ6/+/AlnvIyIWaTSDndvYfN3BORXGVMCn5/vogdAw+E/g3uC4UrEYu0dniIl95LSqwIn70CDDX0Q= Received: from DB7PR03MB4523.eurprd03.prod.outlook.com (20.176.234.147) by DB7PR03MB4617.eurprd03.prod.outlook.com (20.176.234.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Fri, 15 Mar 2019 23:22:46 +0000 Received: from DB7PR03MB4523.eurprd03.prod.outlook.com ([fe80::5577:768:8c8a:91be]) by DB7PR03MB4523.eurprd03.prod.outlook.com ([fe80::5577:768:8c8a:91be%2]) with mapi id 15.20.1709.011; Fri, 15 Mar 2019 23:22:46 +0000 From: "Ghassemian, Mona" To: "roll@ietf.org" Thread-Topic: ***IEEE CSCN 2019*** Thread-Index: AQHU24X/jvzvNE+kP02QAL6pgtOMiA== Date: Fri, 15 Mar 2019 23:22:46 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mona.ghassemian@kcl.ac.uk; x-originating-ip: [2a00:23c6:6288:e100:cf1:30ca:72f2:711] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d7459352-c94f-4e3f-78a4-08d6a99d21d4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DB7PR03MB4617; x-ms-traffictypediagnostic: DB7PR03MB4617: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(346002)(39860400002)(136003)(199004)(189003)(83716004)(25786009)(6486002)(2616005)(53936002)(36756003)(66574012)(2501003)(53946003)(478600001)(2351001)(5640700003)(106356001)(6436002)(71190400001)(6916009)(14454004)(71200400001)(186003)(86362001)(6306002)(6512007)(54896002)(105586002)(8676002)(74482002)(74826001)(476003)(486006)(2906002)(99286004)(236005)(82746002)(606006)(8936002)(1730700003)(81156014)(68736007)(81166006)(46003)(6506007)(14444005)(256004)(966005)(7736002)(316002)(33656002)(6116002)(5660300002)(786003)(102836004)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR03MB4617; H:DB7PR03MB4523.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: kcl.ac.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: NutwZxgpjiTedd+w5ySG8N0VjXwxTqG1YhCk/d2T8DXL7kdILe7fJdQnWPJUpu6rv66cp0Pydw+PWdueSnQlq/YonC/Oh1/0NWcj2L2oWI0jqtt0/y/DvOXQwdk0mWDunJHYdXeSFggAwEA6aucEvvM6Utzp1AC6Xot5VrkNDdppQflQYS2KhTU4r7cagHdGlEmcriig0OLTFu0UtiW9w3wBm4GKg9lWToon4sZ3Sf28Js1Oo7i3+dN/CYti1HTmX2OKhap/GTrbZUlkvi5cbUvpVDy6qYNDzvSnztbB/c11VuxPmECSZYj5TkYOIMVM8+KYxabtXZOpQq4KKYdkuIY2K8VilXI5crZ4j+rgkwHLtt6LR7vrhkMaDz0EXzYa+wZX4WegbgscnK/ugv0mi4677YeT/z2Oac6F7v52uRM= Content-Type: multipart/alternative; boundary="_000_E42EBA8558694A0FB66F77719B5F4E92kclacuk_" MIME-Version: 1.0 X-OriginatorOrg: kcl.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: d7459352-c94f-4e3f-78a4-08d6a99d21d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 23:22:46.0755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8370cf14-16f3-4c16-b83c-724071654356 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR03MB4617 Archived-At: Subject: [Roll] ***IEEE CSCN 2019*** 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, 15 Mar 2019 23:22:56 -0000 --_000_E42EBA8558694A0FB66F77719B5F4E92kclacuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KW0Fwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBjb3BpZXMgb2YgdGhpcyBt ZXNzYWdlXQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQpUaGUgNXRoIElFRUUgQ29uZmVyZW5jZSBvbiBTdGFuZGFyZHMgZm9yIENvbW11bmlj YXRpb25zICYgTmV0d29ya2luZyAoSUVFRSBDU0NO4oCZMTkpDQoyOC0zMCBPY3RvYmVyIDIwMTkg Ly8gR3JhbmFkYSwgU3BhaW4NCmh0dHBzOi8vY3NjbjIwMTkuaWVlZS1jc2NuLm9yZy8NCioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoNCg0K Q0FMTCBGT1IgUEFQRVJTDQoNCg0KDQpPbiBiZWhhbGYgb2YgdGhlIE9yZ2FuaXppbmcgQ29tbWl0 dGVlLCB3ZSBoYXZlIGdyZWF0IHBsZWFzdXJlIGluIGludml0aW5nIHlvdSB0byBzdWJtaXQgeW91 ciB3b3JrIHRvIHRoZSAyMDE5IElFRUUgQ29uZmVyZW5jZSBvbiBTdGFuZGFyZHMgZm9yIENvbW11 bmljYXRpb25zICYgTmV0d29ya2luZyAoSUVFRSBDU0NO4oCZMTkpLiBUaGUgZmlmdGggZWRpdGlv biBvZiB0aGlzIGhpZ2hseSBzdWNjZXNzZnVsIGNvbmZlcmVuY2Ugd2lsbCBiZSBoZWxkIGluIEdy YW5hZGEsIFNwYWluLCB0aGUgY2l0eSBvZiB0aGUgd29ybGQtZmFtb3VzIEFsaGFtYnJhLCBvbmUg b2YgdGhlIHRlbiBtb3N0IHZpc2l0ZWQgbW9udW1lbnRzIGFyb3VuZCB0aGUgd29ybGQuDQpTdGFu ZGFyZHMgcGxheSBhIGtleSByb2xlIGluIHRoZSBzdWNjZXNzIG9mIHRoZSBjb21tdW5pY2F0aW9u cyBpbmR1c3RyeSwgYXMgZW5hYmxlcnMgb2YgZ2xvYmFsIHN5c3RlbXMgaW50ZXItb3BlcmFiaWxp dHkgYW5kIGVjb25vbWllcyBvZiBzY2FsZS4gVGhlIGZpbmFsaXphdGlvbiBvZiB0aGUgM0dQUCBy ZWxlYXNlIDE1IGluIEp1bmUgMjAxOCB3YXMgYSBtYWpvciBtaWxlc3RvbmUuIFdpdGggdGhlIGZp cnN0IDVHIHNwZWNpZmljYXRpb25zIG5vdyBjb21wbGV0ZSwgdGhlIGluZHVzdHJ5IGhhcyBhY2hp ZXZlZCBjcml0aWNhbCBwcm9ncmVzcyBvbiB0ZWNobm9sb2d5IHJlYWRpbmVzcywgYW5kIG9wZXJh dG9ycyBhcm91bmQgdGhlIHdvcmxkIGFyZSBzdGFydGluZyB0aGUgY29tbWVyY2lhbCByb2xsb3V0 LiBUaGlzIHJlcHJlc2VudHMgdGhlIGN1bG1pbmF0aW9uIG9mIHllYXJzIG9mIGNvbmNlcnRlZCBp bmR1c3RyeSBhbmQgYWNhZGVtaWEgZWZmb3J0cyBpbiBzY29waW5nIG91dCBhbmQgZGVzaWduaW5n IHRoZSBuZXh0IGdlbmVyYXRpb24gb2YgbW9iaWxlIHN5c3RlbXMuIFBhc3QgZWRpdGlvbnMgb2Yg SUVFRSBDU0NOIGhhdmUgcGxheWVkIHRoZWlyIG93biBwYXJ0IGluIHRoZXNlIGVmZm9ydHMuDQpJ biAyMDE5LCBJRUVFIENTQ04gd2lsbCBiZSBkaXZpZGVkIGludG8gNCB0cmFja3MgZGVzaWduZWQg dG8gY292ZXIgdGhlIGRpdmVyc2Ugc3BhY2Ugb2YgdGVjaG5vbG9naWVzIOKAkyBub3QgbGltaXRl ZCB0byBjZWxsdWxhciBzeXN0ZW1z4oCTLiBOZXcsIG9yaWdpbmFsIGFuZCBwcmV2aW91c2x5IHVu cHVibGlzaGVkIHBhcGVycyBhcmUgaW52aXRlZCB0aGF0IGFkZHJlc3MgdGhlIGVtZXJnaW5nIGNv bm5lY3Rpdml0eSBzb2x1dGlvbnMgYW5kIHRoZSBzdGFuZGFyZGl6YXRpb24gYXBwcm9hY2hlcyBh bmQgc3RyYXRlZ2llcyB0aGF0IHRoZXNlIG1heSB0YWtlLCBhcyB3ZWxsIGFzIHRoZSByZWxldmFu dCBidXNpbmVzcyBtb2RlbHMgYW5kIHVzZS1jYXNlcy4NCkFkZGl0aW9uYWxseSwgYWZ0ZXIgdGhl IHJlY2VudCBjb21wbGV0aW9uIG9mIDNHUFAgcmVsZWFzZSAxNSwgb2Ygc3BlY2lhbCBpbnRlcmVz dCBhcmUgcGFwZXJzIHRoYXQgYXNzZXNzIHRoZSB3aXJlbGVzcyBsYW5kc2NhcGUgaW4gbGlnaHQg b2YgdGhlIHJlY2VudGx5IGNvbXBsZXRlZCByZWxlYXNlIG9mIE5SIHN0YW5kYXJkLiBOb3Qgb25s eSB0aGUgTm9uLVN0YW5kYWxvbmUgdmVyc2lvbiwgYnV0IGFsc28gdGhlIFN0YW5kYWxvbmUgdmVy c2lvbiB3aGljaCBkZWxpdmVycyB0aGUgcG90ZW50aWFsIGZvciA1RyBkZXBsb3ltZW50cyBpbmRl cGVuZGVudCBvZiBMVEUuDQoNCldlIGFyZSBwbGVhc2VkIHRvIGludml0ZSB5b3UgdG8gc3VibWl0 IGFuIG9yaWdpbmFsIGFuIHByZXZpb3VzbHkgdW5wdWJsaXNoZWQgcGFwZXIgb24gKGJ1dCBub3Qg bGltaXRlZCB0bykgdGhlIHRvcGljcyBvZiB0aGUgZm9sbG93aW5nIHRyYWNrcy4NCg0KDQoNClRy YWNrIG9uIElvVCwgVVJMTEMgYW5kIFYyWA0KDQogICogICBJb1QgYXJjaGl0ZWN0dXJlIGRlc2ln biBvcHRpb25zIGFuZCBzeXN0ZW0gb3B0aW1pemF0aW9ucy4NCiAgKiAgIElvVCBzZWN1cml0eSBh bmQgcHJpdmFjeSBvZiBJb1QgZGV2aWNlcyBhbmQgc2VydmljZXMuDQogICogICBTeXN0ZW0gb3B0 aW1pemF0aW9uIHRvIHN1cHBvcnQgdWx0cmEtbG93IGNvbXBsZXhpdHkgZGV2aWNlcy4NCiAgKiAg IFJhZGlvIGFjY2VzcyBvcHRpbWl6YXRpb25zIGZvciB1bHRyYS1sb3cgcG93ZXIgZGV2aWNlcy4N CiAgKiAgIFN0YW5kYXJkaXplZCBzZW1hbnRpYyBkYXRhIGRlc2NyaXB0aW9uIGZyYW1ld29yayBh bmQgdGVjaG5vbG9naWVzLg0KICAqICAgSW9UIGNvbW11bmljYXRpb24gcHJvY2VkdXJlIGVuaGFu Y2VtZW50cy4NCiAgKiAgIEV4cGVyaWVuY2UgYW5kIGxlc3NvbnMgbGVhcm50IGZyb20gSW9UIGxh cmdlLXNjYWxlIHBpbG90cy4NCiAgKiAgIElvVCBzdGFuZGFyZHMgcGxhdGZvcm1zIGludGVyd29y a2luZy4NCiAgKiAgIElvVCBpbnRlcm9wZXJhYmlsaXR5IG1ldGhvZG9sb2dpZXMuDQogICogICBJ b1Qgc3RhbmRhcmRzIGdhcCBhbmFseXNpcy4NCiAgKiAgIDVHIG5ldHdvcmtzLCBJb1QgYW5kIFRh Y3RpbGUgSW50ZXJuZXQuDQogICogICBTb2Z0d2FyZSBEZWZpbmVkIE5ldHdvcmsgKFNETikgYW5k IElvVC4NCiAgKiAgIEluZHVzdHJpYWwgSW50ZXJuZXQgb2YgVGhpbmdzLg0KICAqICAgRmFjdG9y eSBvZiB0aGluZ3MuDQogICogICBFZGdlIGNvbXB1dGluZywgZm9nIGNvbXB1dGluZyBhbmQgSW9U Lg0KICAqICAgSVB2Ni1iYXNlZCBJb1QgbmV0d29ya3MuDQogICogICBJb1QgcHJvdG9jb2xzIHN1 Y2ggYXMgSVB2NiwgNkxvV1BBTiwgUlBMLCA2VGlTQ0gsIFdvVC4NCiAgKiAgIElvVCBzZWN1cml0 eSBhc3BlY3RzIGZvciBtYXNzaXZlIElvVCBkZXBsb3ltZW50cywgZS5nLiwgZW1iZWRkZWQgU0lN IG1hbmFnZW1lbnQuDQogICogICBVbHRyYS1SZWxpYWJsZSBMb3ctTGF0ZW5jeSBDb21tdW5pY2F0 aW9ucyAoVVJMTEMpLg0KICAqICAgVVJMTEMgZm9yIG1pc3Npb24tY3JpdGljYWwgSW9ULg0KICAq ICAgVjJYIHN0YW5kYXJkcyBhbmQgYXJjaGl0ZWN0dXJlcy4NCiAgKiAgIFByaXZhdGUgTFRFLyA1 RyBuZXR3b3Jrcy4NCg0KVHJhY2sgb24gNUcgUmFkaW8gYW5kIFdpcmVsZXNzIENvbW11bmljYXRp b25zDQoNCiAgKiAgIFBoeXNpY2FsIGxheWVyIGFuZCBNQUMgbGF5ZXIgZGVzaWduIGZvciA1Ry1l bmFibGluZyB3aXJlbGVzcyBuZXR3b3Jrcy4NCiAgKiAgIER5bmFtaWMgc2NoZWR1bGluZywgcG93 ZXIgY29udHJvbCwgaW50ZXJmZXJlbmNlIG1hbmFnZW1lbnQsIGFuZCBRb1MgbWFuYWdlbWVudCBp biA1Ry4NCiAgKiAgIFRlY2huaXF1ZXMgZm9yIGxhdGVuY3kgcmVkdWN0aW9uIGluIDVHLg0KICAq ICAgUmVzb3VyY2UgbWFuYWdlbWVudCBhbmQgY29udHJvbCBpbiA1RyBSQU4uDQogICogICBTZXJ2 aWNlLW9yaWVudGVkIHVzZXItcGxhbmUgZGVzaWduIGNvbmNlcHRzLg0KICAqICAgVG9wb2xvZ3ks IGRlcGxveW1lbnQsIGFuZCBvcHRpbWl6YXRpb24gb2Ygd2lyZWxlc3MgbmV0d29ya3MuDQogICog ICBXaXJlbGVzcyB0ZWNobm9sb2d5IGZvciBoaWdoIHNwZWVkLg0KICAqICAgbW1XYXZlIGFjY2Vz cywgYmFja2hhdWwgYW5kIHNlbGYtYmFja2hhdWxpbmcuDQogICogICBBcHBsaWNhdGlvbiBvZiBT RE4sIE5GViwgYW5kIGNsb3VkIGNvbXB1dGluZyB0byA1RyAoYW5kIGxlZ2FjeSkgUkFOIGFuZCBj b3JlIG5ldHdvcmsgYXJjaGl0ZWN0dXJlcyBhbmQgaW1wbGVtZW50YXRpb25zLCBzdWNoIGFzIG5l dHdvcmsgc2xpY2luZy4NCiAgKiAgIDNHUFAgcGhhc2VkIHdvcmsgb24gTlIuDQogICogICBHcmVl biBhbmQgZW5lcmd5IGVmZmljaWVudCB3aXJlbGVzcyBuZXR3b3Jrcy4NCiAgKiAgIFNvbHV0aW9u cyBmb3IgYmF0dGVyeS1jb25zZXJ2aW5nLCBpbnRlcmZlcmVuY2UtbWl0aWdhdGluZyB0ZXJtaW5h bCBkZXNpZ24uDQogICogICBNYXNzaXZlIGFuZCBGRC1NSU1PIGNvbW11bmljYXRpb25zLCBoeWJy aWQgYW5kIGNvb3JkaW5hdGVkIGJlYW1mb3JtaW5nIHRlY2hub2xvZ3kuDQogICogICBOZXcgY29u dHJvbCBzaWduYWxpbmcgZm9yIGhldGVyb2dlbmVvdXMgbmV0d29ya3MuDQogICogICBOZXh0LUdl bmVyYXRpb24gV2ktRmkgKElFRUUgODAyLjExYXgvYXkpLg0KICAqICAgNUctTFRFIGludGVyd29y a2luZyBhbmQgNUcvTFRFIOKAlCBXaS1GaS9XaS1HaWcgaW50ZXJ3b3JraW5nIHRlY2hub2xvZ3ku DQogICogICA1RyBvcGVyYXRpb24gYW5kIGNvZXhpc3RlbmNlIGluIHVubGljZW5zZWQgYW5kIHNo YXJlZCBzcGVjdHJ1bSBiYW5kcy4NCiAgKiAgIE5leHQtZ2VuZXJhdGlvbiBub24tUkYgY29tbXVu aWNhdGlvbnMgc3lzdGVtcy4NCiAgKiAgIDVHIFJhZGlvIFJlc3VsdHMgZnJvbSBzaW11bGF0aW9u LCBwcm90b3R5cGluZywgYW5kIGV4cGVyaW1lbnRzLg0KICAqICAgRW1lcmdpbmcgY2FuZGlkYXRl IHRlY2hub2xvZ2llcyBhbmQgYnVzaW5lc3MgdXNlLWNhc2VzIGZvciBCZXlvbmQgNUcuDQoNClRy YWNrIG9uIFNvZnR3YXJpemF0aW9uLCBTbGljaW5nLCBBdXRvbWF0aW9uIGFuZCBOZXR3b3JrIE1h bmFnZW1lbnQNCg0KICAqICAgQXJjaGl0ZWN0dXJlcyBhbmQgcHJvdG9jb2xzIGZvciBuZXR3b3Jr IGF1dG9tYXRpb24gYW5kIHplcm8tdG91Y2ggbWFuYWdlbWVudC4NCiAgKiAgIEludGVsbGlnZW50 LSwgaW50ZW50LWJhc2VkIGFuZCBjb2duaXRpdmUgbmV0d29ya2luZyBhbmQgbmV0d29yayBtYW5h Z2VtZW50Lg0KICAqICAgUHJvZ3JhbW1hYmxlIGFyY2hpdGVjdHVyZXMgYW5kIHN5c3RlbXMgZm9y IDVHIHNlcnZpY2VzIGFuZCB2ZXJ0aWNhbHMuDQogICogICBBbmFseXNpcyBhbmQgY29uc2lkZXJh dGlvbnMgZm9yIGNvbW1vbiBWTkZzIGFjcm9zcyBmaXhlZCBhbmQgbW9iaWxlIG5ldHdvcmtzLg0K ICAqICAgNUcgc2VydmljZS1iYXNlZCBhcmNoaXRlY3R1cmUgZXZvbHV0aW9uLg0KICAqICAgTmV0 d29yayBmdW5jdGlvbnMgcGxhY2VtZW50IGluIGRpc3RyaWJ1dGVkIGNsb3Vkcy4NCiAgKiAgIDVH IGZ1bmN0aW9uYWwgZGVjb21wb3NpdGlvbiBhbmQgZGVwbG95bWVudC4NCiAgKiAgIFNlY3VyZSBv cGVyYXRpb25zIGluIGZ1dHVyZSB2aXJ0dWFsaXplZCBuZXR3b3Jrcy4NCiAgKiAgIFJlc291cmNl IG1hbmFnZW1lbnQgYW5kIHNoYXJpbmcgZm9yIG5ldHdvcmsgc2xpY2luZy4NCiAgKiAgIFNjYWxh YmlsaXR5IGFuZCByZWxpYWJpbGl0eSBpbiA1RyBuZXR3b3JrcyBhbmQgNUcgbmV0d29yayBzbGlj aW5nLg0KICAqICAgRGVkaWNhdGVkIGFuZCBzaGFyZWQgbmV0d29yayBmdW5jdGlvbnMgaW4gbmV0 d29yayBzbGljZXMuDQogICogICBDcm9zcy1zbGljZSBtYW5hZ2VtZW50IGZvciBlbmQtdG8tZW5k IFFvUy4NCiAgKiAgIFByb2dyZXNzIG9uIG5ldHdvcmsgc2xpY2luZyBzdGFuZGFyZGl6YXRpb24g KGUuZy4gM0dQUCwgR1NNQSwgZXRjLikuDQogICogICBFdmFsdWF0aW9uIG9mIG5ldHdvcmsgc29m dHdhcml6YXRpb24gYW5kIGZ1bmRhbWVudGFsIHRyYWRlLW9mZnMuDQogICogICBUZXN0LWJlZCBl eHBlcmllbmNlIGluIHNvZnR3YXJpemF0aW9uIGFuZCBuZXR3b3JrIHNsaWNpbmcuDQogICogICBT RE4gYXJjaGl0ZWN0dXJlcyBhbmQgaW50ZXJmYWNlcy4NCiAgKiAgIFNETiBwcm9ncmFtbWluZyBs YW5ndWFnZXMgYW5kIGRhdGEgbW9kZWxzLg0KICAqICAgUHJvZ3Jlc3MgYW5kIGZ1dHVyZSBjaGFs bGVuZ2VzIGluIHN0YW5kYXJkaXphdGlvbiAoZS5nLiBFVFNJIE5GViwgSUVURi9JUlRGLCBldGMu KS4NCiAgKiAgIE9yY2hlc3RyYXRpb24gYW5kIG1hbmFnZW1lbnQgaW4gU0ROIGFuZCBORlYuDQog ICogICBNdWx0aS1kb21haW4gYW5kIG11bHRpLXRlbmFuY3kgY29uc2lkZXJhdGlvbnMgaW4gU0RO IGFuZCBORlYuDQogICogICBPcGVuIFNvdXJjZSBlZmZvcnRzIGluIHJlbGF0aW9uIHRvIFNETiBh bmQgTkZWIChlLmcuLCBPTkFQLCBPUE5GViwgT3BlblN0YWNrLCBPcGVuIFNvdXJjZSBNQU5PKS4N CiAgKiAgIFFvUy9Rb0UgYXNwZWN0cyByZWxhdGVkIHRvIFNETiBhbmQgTkZWIGJhc2VkIG5ldHdv cmsgc2VydmljZXMuDQoNClRyYWNrIG9uIEFjY2VzcyBOZXR3b3JrLCBFZGdlIENvbXB1dGluZyBh bmQgVHJhbnNwb3J0IGZvciA1Rw0KDQogICogICBNdWx0aS1BY2Nlc3MgRWRnZSBDb21wdXRpbmcs IEVkZ2UtRm9nIENvbXB1dGluZy4NCiAgKiAgIFJvdXRpbmcgcHJvdG9jb2xzLCBzZWdtZW50IHJv dXRpbmcgYW5kIFZQTiBleHRlbnNpb25zIGZvciA1RyBzbGljaW5nLg0KICAqICAgTXVsdGktdGVu YW5jeSwgc2xpY2luZywgYW5kIGNvbnRyb2wgb2YgbXVsdGktZG9tYWluIGhldGVyb2dlbmVvdXMg aW5mcmFzdHJ1Y3R1cmVzLg0KICAqICAgU0ROIGFuZCBORlYgaW4gYWNjZXNzLCBlZGdlLCBhbmQg dHJhbnNwb3J0IGZvciA1Rw0KICAqICAgVHJhbnNwb3J0aW5nIDVHIG1vYmlsZSBzZXJ2aWNlcyBv dmVyIG9wdGljYWwgYWNjZXNzIG5ldHdvcmtzLg0KICAqICAgU0ROIHNvbHV0aW9ucyBmb3IgbW9i aWxlIG5ldHdvcmtzIGFuZCBmaXhlZCBJUCBjcm9zcyBsYXllciB0cmFuc3BvcnQgYW5kIHJvdXRp bmcuDQogICogICA1RyBhcmNoaXRlY3R1cmVzIHN1cHBvcnRpbmcgQ2xvdWQtUkFOIGFuZCBmdW5j dGlvbmFsIHNwbGl0IG9wdGlvbnMuDQogICogICA1RyBhcmNoaXRlY3R1cmVzIHN1cHBvcnRpbmcg ZnJvbnRoYXVsL21pZGRsZWhhdWwvYmFja2hhdWwgaW50ZWdyYXRpb24uDQogICogICBOZXR3b3Jr IHNsaWNpbmcgaXNzdWVzIHdpdGggbXVsdGktUkFUcyBkZXZpY2VzLg0KICAqICAgRW5kLXRvLSBl bmQgcmVzb3VyY2Ugb3B0aW1pemF0aW9uIGZvciA1RyBtb2JpbGUgc2VydmljZXM6IGZyb20gcmFk aW8gaGVhZCB0byBkYXRhIGNlbnRlci4NCiAgKiAgIEludGVncmF0ZWQgYmFja2hhdWwvbWlkZGxl aGF1bC9mcm9udGhhdWwNCiAgKiAgIEJhY2toYXVsL21pZGRsZWhhdWwvZnJvbnRoYXVsIGNvbnNp ZGVyYXRpb25zIGZvciBkeW5hbWljIGNhcGFjaXR5IGFuZCBtb2JpbGl0eSBtYW5hZ2VtZW50Lg0K ICAqICAgRGVsaXZlcmluZyBzZXJ2aWNlcyBvdmVyIElDTiBpbiA1RyB3aXRoaW4gYSBmcmFtZXdv cmsgZW5hYmxpbmcgbmV0d29yayBzbGljaW5nLg0KICAqICAgRW5oYW5jaW5nIDVHIGJhY2toYXVs L21pZGRsZWhhdWwvZnJvbnRoYXVsIHdpdGggSUNOLg0KICAqICAgTWVjaGFuaXNtcyBhbmQgcHJv dG9jb2wgZW5oYW5jZW1lbnRzIGZvciBIeWJyaWQgQWNjZXNzIG5ldHdvcmtzLg0KICAqICAgSW50 cm9kdWN0aW9uIG9mIEVUU0kgTUVDIHRlY2hub2xvZ3kgYW5kIGFwcGxpY2F0aW9ucyBvbiB2ZXJ0 aWNhbCBtYXJrZXQgc2VnbWVudHMuDQogICogICBOZXcgdXNlciBhcHBsaWNhdGlvbnMgYXQgdGhl IGVkZ2Ugb2YgdGhlIGNvbW11bmljYXRpb24gbmV0d29yay4NCiAgKiAgIFZlcnRpY2FsIGluZHVz dHJ5IGltcGxpY2F0aW9ucyB0byB0cmFuc3BvcnQsIGVkZ2UgY29tcHV0aW5nLCBhbmQgNUcgYWNj ZXNzIG5ldHdvcmtzLg0KICAqICAgSW5zaWdodHMgb24gcGlsb3RzLCBwcm9vZi1vZi1jb25jZXB0 LCBhbmQgcHJvdG90eXBlcyBvbiBhY2Nlc3MsIGVkZ2UsIGFuZCB0cmFuc3BvcnQgbmV0d29ya3Mu DQoNCkF1dGhvcnMgb2Ygc2VsZWN0ZWQgcGFwZXJzIGZyb20gSUVFRSBDU0NOIDIwMTkgd2lsbCBi ZSBpbnZpdGVkIHRvIHN1Ym1pdCBhbiBleHRlbmRlZCBhbmQgaW1wcm92ZWQgdmVyc2lvbiB0byBJ RUVFIFN0YW5kYXJkcyBNYWdhemluZSBzcGVjaWFsIGlzc3VlLg0KDQpTVUJNSVNTSU9ODQoNCg0K DQpBbGwgc3VibWlzc2lvbnMgaGF2ZSB0byBjb21wbHkgd2l0aCBJRUVF4oCZcyBndWlkZWxpbmVz LiBJbml0aWFsIHN1Ym1pc3Npb25zIGZvciByZXZpZXcgYXJlIGxpbWl0ZWQgdG8gc2V2ZW4gKDcp IHBhZ2VzLiBDYW1lcmEtcmVhZHkgcGFwZXJzIHNob3VsZCBub3QgZXhjZWVkIHNpeCAoNikgcGFn ZXMgZm9yIGxvbmcgcGFwZXJzLCBhbmQgKDQpIHBhZ2VzIGZvciBzaG9ydCBwYXBlcnMsIGluY2x1 ZGluZyBmaWd1cmVzIHdpdGhvdXQgaW5jdXJyaW5nIGFkZGl0aW9uYWwgcGFnZSBjaGFyZ2VzICht YXhpbXVtIDEgYWRkaXRpb25hbCBwYWdlIHdpdGggb3ZlciBsZW5ndGggcGFnZSBjaGFyZ2UpLg0K DQpUaGUgc3VibWlzc2lvbiBVUkwgaXM6IGh0dHBzOi8vY3NjbjIwMTkuaWVlZS1jc2NuLm9yZy9h dXRob3JzLw0KDQoNCg0KSU1QT1JUQU5UIERBVEVTDQoNCg0KDQpTdWJtaXNzaW9uIERlYWRsaW5l OiAxIEp1bmUgMjAxOQ0KQWNjZXB0YW5jZSBOb3RpZmljYXRpb246IDEgU2VwdGVtYmVyIDIwMTkN CkNhbWVyYS1SZWFkeTogMSBPY3RvYmVyIDIwMTkNCg0KT1JHQU5JU0lORyBDT01NSVRURUUNCg0K DQpHZW5lcmFsIENvLUNoYWlycw0KDQpQcm9mLiBUYXJpayBUYWxlYiAoQWFsdG8gVW5pdmVyc2l0 eSwgRmlubGFuZCkNClByb2YuIEp1YW4gTS4gTG9wZXotU29sZXIgKFVuaXZlcnNpdHkgb2YgR3Jh bmFkYSwgU3BhaW4pDQoNClRQQyBDby1DaGFpcnMNCg0KUHJvZi4gQXJ0dXJvIEF6Y29ycmEgKElN REVBIE5ldHdvcmtzIEluc3RpdHV0ZSwgU3BhaW4pDQpQcm9mLiBOYXJjaXMgQ2FyZG9uYSAoVW5p dmVyc2l0YXQgUG9saXTDqGNuaWNhIGRlIFZhbMOobmNpYSwgU3BhaW4pDQpEci4gSW1lbiBHcmlk YSBCZW55YWhpYSAoT3JhbmdlIExhYnMsIEZyYW5jZSkNCg0K --_000_E42EBA8558694A0FB66F77719B5F4E92kclacuk_ Content-Type: text/html; charset="utf-8" Content-ID: <9648C6A90A2BE84398D32C84EE8A85B6@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250 LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDIyOCwgMTc1LCAxMCk7IiBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0 cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hl bHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQom bmJzcDs8L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KW0Fwb2xvZ2llcyBpZiB5 b3UgcmVjZWl2ZSBtdWx0aXBsZSBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlXTwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2Io NjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZv bnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1 b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0i Ij4NClRoZSA1dGggSUVFRSBDb25mZXJlbmNlIG9uIFN0YW5kYXJkcyBmb3IgQ29tbXVuaWNhdGlv bnMgJmFtcDsgTmV0d29ya2luZyAoSUVFRSBDU0NO4oCZMTkpPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjks IDY5KTsiIGNsYXNzPSIiPg0KMjgtMzAgT2N0b2JlciAyMDE5IC8vIEdyYW5hZGEsIFNwYWluPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Ozsg Y29sb3I6IHJnYigyMjgsIDE3NSwgMTApOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2Nz Y24yMDE5LmllZWUtY3Njbi5vcmcvIiBjbGFzcz0iIj5odHRwczovL2NzY24yMDE5LmllZWUtY3Nj bi5vcmcvPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjogIzQ1NDU0NSIgY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUm cXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvZGl2Pg0KPHAgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2 OSwgNjkpOyIgY2xhc3M9IiI+DQombmJzcDs8L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsg Zm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAm cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNz PSIiPg0KQ0FMTCBGT1IgUEFQRVJTPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQt c3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7 SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4N CiZuYnNwOzwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVl JnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQpPbiBiZWhhbGYgb2Yg dGhlIE9yZ2FuaXppbmcgQ29tbWl0dGVlLCB3ZSBoYXZlIGdyZWF0IHBsZWFzdXJlIGluIGludml0 aW5nIHlvdSB0byBzdWJtaXQgeW91ciB3b3JrIHRvIHRoZSAyMDE5IElFRUUgQ29uZmVyZW5jZSBv biBTdGFuZGFyZHMgZm9yIENvbW11bmljYXRpb25zICZhbXA7IE5ldHdvcmtpbmcgKElFRUUgQ1ND TuKAmTE5KS4gVGhlIGZpZnRoIGVkaXRpb24gb2YgdGhpcyBoaWdobHkgc3VjY2Vzc2Z1bCBjb25m ZXJlbmNlIHdpbGwgYmUgaGVsZCBpbg0KIEdyYW5hZGEsIFNwYWluLCB0aGUgY2l0eSBvZiB0aGUg d29ybGQtZmFtb3VzIEFsaGFtYnJhLCBvbmUgb2YgdGhlIHRlbiBtb3N0IHZpc2l0ZWQgbW9udW1l bnRzIGFyb3VuZCB0aGUgd29ybGQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIi Pg0KU3RhbmRhcmRzIHBsYXkgYSBrZXkgcm9sZSBpbiB0aGUgc3VjY2VzcyBvZiB0aGUgY29tbXVu aWNhdGlvbnMgaW5kdXN0cnksIGFzIGVuYWJsZXJzIG9mIGdsb2JhbCBzeXN0ZW1zIGludGVyLW9w ZXJhYmlsaXR5IGFuZCBlY29ub21pZXMgb2Ygc2NhbGUuIFRoZSBmaW5hbGl6YXRpb24gb2YgdGhl IDNHUFAgcmVsZWFzZSAxNSBpbiBKdW5lIDIwMTggd2FzIGEgbWFqb3IgbWlsZXN0b25lLiBXaXRo IHRoZSBmaXJzdCA1RyBzcGVjaWZpY2F0aW9ucyBub3cNCiBjb21wbGV0ZSwgdGhlIGluZHVzdHJ5 IGhhcyBhY2hpZXZlZCBjcml0aWNhbCBwcm9ncmVzcyBvbiB0ZWNobm9sb2d5IHJlYWRpbmVzcywg YW5kIG9wZXJhdG9ycyBhcm91bmQgdGhlIHdvcmxkIGFyZSBzdGFydGluZyB0aGUgY29tbWVyY2lh bCByb2xsb3V0LiBUaGlzIHJlcHJlc2VudHMgdGhlIGN1bG1pbmF0aW9uIG9mIHllYXJzIG9mIGNv bmNlcnRlZCBpbmR1c3RyeSBhbmQgYWNhZGVtaWEgZWZmb3J0cyBpbiBzY29waW5nIG91dCBhbmQg ZGVzaWduaW5nDQogdGhlIG5leHQgZ2VuZXJhdGlvbiBvZiBtb2JpbGUgc3lzdGVtcy4gUGFzdCBl ZGl0aW9ucyBvZiBJRUVFIENTQ04gaGF2ZSBwbGF5ZWQgdGhlaXIgb3duIHBhcnQgaW4gdGhlc2Ug ZWZmb3J0cy4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0 Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZl dGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQpJbiAy MDE5LCBJRUVFIENTQ04gd2lsbCBiZSBkaXZpZGVkIGludG8gNCB0cmFja3MgZGVzaWduZWQgdG8g Y292ZXIgdGhlIGRpdmVyc2Ugc3BhY2Ugb2YgdGVjaG5vbG9naWVzIOKAkyBub3QgbGltaXRlZCB0 byBjZWxsdWxhciBzeXN0ZW1z4oCTLiBOZXcsIG9yaWdpbmFsIGFuZCBwcmV2aW91c2x5IHVucHVi bGlzaGVkIHBhcGVycyBhcmUgaW52aXRlZCB0aGF0IGFkZHJlc3MgdGhlIGVtZXJnaW5nIGNvbm5l Y3Rpdml0eSBzb2x1dGlvbnMgYW5kIHRoZSBzdGFuZGFyZGl6YXRpb24NCiBhcHByb2FjaGVzIGFu ZCBzdHJhdGVnaWVzIHRoYXQgdGhlc2UgbWF5IHRha2UsIGFzIHdlbGwgYXMgdGhlIHJlbGV2YW50 IGJ1c2luZXNzIG1vZGVscyBhbmQgdXNlLWNhc2VzLjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZh bWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7 IiBjbGFzcz0iIj4NCkFkZGl0aW9uYWxseSwgYWZ0ZXIgdGhlIHJlY2VudCBjb21wbGV0aW9uIG9m IDNHUFAgcmVsZWFzZSAxNSwgb2Ygc3BlY2lhbCBpbnRlcmVzdCBhcmUgcGFwZXJzIHRoYXQgYXNz ZXNzIHRoZSB3aXJlbGVzcyBsYW5kc2NhcGUgaW4gbGlnaHQgb2YgdGhlIHJlY2VudGx5IGNvbXBs ZXRlZCByZWxlYXNlIG9mIE5SIHN0YW5kYXJkLiBOb3Qgb25seSB0aGUgTm9uLVN0YW5kYWxvbmUg dmVyc2lvbiwgYnV0IGFsc28gdGhlIFN0YW5kYWxvbmUgdmVyc2lvbiB3aGljaA0KIGRlbGl2ZXJz IHRoZSBwb3RlbnRpYWwgZm9yIDVHIGRlcGxveW1lbnRzIGluZGVwZW5kZW50IG9mIExURS48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBj b2xvcjogcmdiKDY5LCA2OSwgNjkpOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQpXZSBhcmUg cGxlYXNlZCB0byBpbnZpdGUgeW91IHRvIHN1Ym1pdCBhbiBvcmlnaW5hbCBhbiBwcmV2aW91c2x5 IHVucHVibGlzaGVkIHBhcGVyIG9uIChidXQgbm90IGxpbWl0ZWQgdG8pIHRoZSB0b3BpY3Mgb2Yg dGhlIGZvbGxvd2luZyB0cmFja3MuPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQt c3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7 SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4N CiZuYnNwOzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMnB4OyBmb250LXN0cmV0Y2g6 IG5vcm1hbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWls eTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBj bGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRyYWNrIG9uIElvVCwgVVJMTEMgYW5kIFYyWDwvYj48L3A+ DQo8dWwgY2xhc3M9IiI+DQo8bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPklvVCBhcmNoaXRlY3R1 cmUgZGVzaWduIG9wdGlvbnMgYW5kIHN5c3RlbSBvcHRpbWl6YXRpb25zLjwvbGk+PGxpIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwg NjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBm b250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsi IGNsYXNzPSIiPjwvc3Bhbj5Jb1Qgc2VjdXJpdHkgYW5kIHByaXZhY3kgb2YgSW9UIGRldmljZXMg YW5kIHNlcnZpY2VzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2Eg TmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5TeXN0ZW0gb3B0aW1p emF0aW9uIHRvIHN1cHBvcnQgdWx0cmEtbG93IGNvbXBsZXhpdHkgZGV2aWNlcy48L2xpPjxsaSBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2Io NjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1h bDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVu bG87IiBjbGFzcz0iIj48L3NwYW4+UmFkaW8gYWNjZXNzIG9wdGltaXphdGlvbnMgZm9yIHVsdHJh LWxvdyBwb3dlciBkZXZpY2VzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJl dGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5TdGFuZGFy ZGl6ZWQgc2VtYW50aWMgZGF0YSBkZXNjcmlwdGlvbiBmcmFtZXdvcmsgYW5kIHRlY2hub2xvZ2ll cy48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7 IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0 cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+SW9UIGNvbW11bmljYXRpb24gcHJvY2Vk dXJlIGVuaGFuY2VtZW50cy48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRj aDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0 aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdo dDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+RXhwZXJpZW5j ZSBhbmQgbGVzc29ucyBsZWFybnQgZnJvbSBJb1QgbGFyZ2Utc2NhbGUgcGlsb3RzLjwvbGk+PGxp IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJn Yig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9y bWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBN ZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5Jb1Qgc3RhbmRhcmRzIHBsYXRmb3JtcyBpbnRlcndvcmtp bmcuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7 OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z dHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPklvVCBpbnRlcm9wZXJhYmlsaXR5IG1l dGhvZG9sb2dpZXMuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPklvVCBzdGFuZGFyZHMg Z2FwIGFuYWx5c2lzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2Eg TmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj41RyBuZXR3b3Jrcywg SW9UIGFuZCBUYWN0aWxlIEludGVybmV0LjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5T b2Z0d2FyZSBEZWZpbmVkIE5ldHdvcmsgKFNETikgYW5kIElvVC48L2xpPjxsaSBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2 OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1z aXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IiBjbGFz cz0iIj48L3NwYW4+SW5kdXN0cmlhbCBJbnRlcm5ldCBvZiBUaGluZ3MuPC9saT48bGkgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2 OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZv bnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIg Y2xhc3M9IiI+PC9zcGFuPkZhY3Rvcnkgb2YgdGhpbmdzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFt aWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6 IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIi Pjwvc3Bhbj5FZGdlIGNvbXB1dGluZywgZm9nIGNvbXB1dGluZyBhbmQgSW9ULjwvbGk+PGxpIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2 OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFs OyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5s bzsiIGNsYXNzPSIiPjwvc3Bhbj5JUHY2LWJhc2VkIElvVCBuZXR3b3Jrcy48L2xpPjxsaSBzdHls ZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjks IDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsg Zm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87 IiBjbGFzcz0iIj48L3NwYW4+SW9UIHByb3RvY29scyBzdWNoIGFzIElQdjYsIDZMb1dQQU4sIFJQ TCwgNlRpU0NILCBXb1QuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPklvVCBzZWN1cml0 eSBhc3BlY3RzIGZvciBtYXNzaXZlIElvVCBkZXBsb3ltZW50cywgZS5nLiwgZW1iZWRkZWQgU0lN IG1hbmFnZW1lbnQuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPlVsdHJhLVJlbGlhYmxl IExvdy1MYXRlbmN5IENvbW11bmljYXRpb25zIChVUkxMQykuPC9saT48bGkgc3R5bGU9Im1hcmdp bjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkp OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6 ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9 IiI+PC9zcGFuPlVSTExDIGZvciBtaXNzaW9uLWNyaXRpY2FsIElvVC48L2xpPjxsaSBzdHlsZT0i bWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5 LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9u dC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IiBj bGFzcz0iIj48L3NwYW4+VjJYIHN0YW5kYXJkcyBhbmQgYXJjaGl0ZWN0dXJlcy48L2xpPjxsaSBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2Io NjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1h bDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVu bG87IiBjbGFzcz0iIj48L3NwYW4+UHJpdmF0ZSBMVEUvIDVHIG5ldHdvcmtzLjwvbGk+PC91bD4N CjxwIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMnB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9u dC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVs dmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPlRyYWNrIG9uIDVHIFJhZGlvIGFuZCBXaXJlbGVzcyBDb21tdW5pY2F0aW9uczwv Yj48L3A+DQo8dWwgY2xhc3M9IiI+DQo8bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0 Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZl dGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPlBoeXNpY2Fs IGxheWVyIGFuZCBNQUMgbGF5ZXIgZGVzaWduIGZvciA1Ry1lbmFibGluZyB3aXJlbGVzcyBuZXR3 b3Jrcy48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVv dDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+RHluYW1pYyBzY2hlZHVsaW5nLCBw b3dlciBjb250cm9sLCBpbnRlcmZlcmVuY2UgbWFuYWdlbWVudCwgYW5kIFFvUyBtYW5hZ2VtZW50 IGluIDVHLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5UZWNobmlxdWVzIGZvciBsYXRl bmN5IHJlZHVjdGlvbiBpbiA1Ry48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3Ry ZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVs dmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhl aWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+UmVzb3Vy Y2UgbWFuYWdlbWVudCBhbmQgY29udHJvbCBpbiA1RyBSQU4uPC9saT48bGkgc3R5bGU9Im1hcmdp bjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkp OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6 ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9 IiI+PC9zcGFuPlNlcnZpY2Utb3JpZW50ZWQgdXNlci1wbGFuZSBkZXNpZ24gY29uY2VwdHMuPC9s aT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xv cjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNo OiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPlRvcG9sb2d5LCBkZXBsb3ltZW50LCBhbmQgb3B0 aW1pemF0aW9uIG9mIHdpcmVsZXNzIG5ldHdvcmtzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBw eDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEw cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwv c3Bhbj5XaXJlbGVzcyB0ZWNobm9sb2d5IGZvciBoaWdoIHNwZWVkLjwvbGk+PGxpIHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjks IDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250 LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNs YXNzPSIiPjwvc3Bhbj5tbVdhdmUgYWNjZXNzLCBiYWNraGF1bCBhbmQgc2VsZi1iYWNraGF1bGlu Zy48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7 IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0 cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+QXBwbGljYXRpb24gb2YgU0ROLCBORlYs IGFuZCBjbG91ZCBjb21wdXRpbmcgdG8gNUcgKGFuZCBsZWdhY3kpIFJBTiBhbmQgY29yZSBuZXR3 b3JrIGFyY2hpdGVjdHVyZXMgYW5kIGltcGxlbWVudGF0aW9ucywgc3VjaCBhcyBuZXR3b3JrIHNs aWNpbmcuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1 b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPjNHUFAgcGhhc2VkIHdvcmsgb24g TlIuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7 OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z dHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPkdyZWVuIGFuZCBlbmVyZ3kgZWZmaWNp ZW50IHdpcmVsZXNzIG5ldHdvcmtzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1z dHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtI ZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5Tb2x1 dGlvbnMgZm9yIGJhdHRlcnktY29uc2VydmluZywgaW50ZXJmZXJlbmNlLW1pdGlnYXRpbmcgdGVy bWluYWwgZGVzaWduLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2Eg TmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5NYXNzaXZlIGFuZCBG RC1NSU1PIGNvbW11bmljYXRpb25zLCBoeWJyaWQgYW5kIGNvb3JkaW5hdGVkIGJlYW1mb3JtaW5n IHRlY2hub2xvZ3kuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPk5ldyBjb250cm9sIHNp Z25hbGluZyBmb3IgaGV0ZXJvZ2VuZW91cyBuZXR3b3Jrcy48L2xpPjxsaSBzdHlsZT0ibWFyZ2lu OiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZh bWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXpl OiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IiBjbGFzcz0i Ij48L3NwYW4+TmV4dC1HZW5lcmF0aW9uIFdpLUZpIChJRUVFIDgwMi4xMWF4L2F5KS48L2xpPjxs aSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiBy Z2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5v cm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87IiBjbGFzcz0iIj48L3NwYW4+NUctTFRFIGludGVyd29ya2luZyBhbmQgNUcvTFRFIOKA lCBXaS1GaS9XaS1HaWcgaW50ZXJ3b3JraW5nIHRlY2hub2xvZ3kuPC9saT48bGkgc3R5bGU9Im1h cmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwg NjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQt c2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xh c3M9IiI+PC9zcGFuPjVHIG9wZXJhdGlvbiBhbmQgY29leGlzdGVuY2UgaW4gdW5saWNlbnNlZCBh bmQgc2hhcmVkIHNwZWN0cnVtIGJhbmRzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5O ZXh0LWdlbmVyYXRpb24gbm9uLVJGIGNvbW11bmljYXRpb25zIHN5c3RlbXMuPC9saT48bGkgc3R5 bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5 LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7 IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxv OyIgY2xhc3M9IiI+PC9zcGFuPjVHIFJhZGlvIFJlc3VsdHMgZnJvbSBzaW11bGF0aW9uLCBwcm90 b3R5cGluZywgYW5kIGV4cGVyaW1lbnRzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5F bWVyZ2luZyBjYW5kaWRhdGUgdGVjaG5vbG9naWVzIGFuZCBidXNpbmVzcyB1c2UtY2FzZXMgZm9y IEJleW9uZCA1Ry48L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDJweDsgZm9u dC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2 OSwgNjkpOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5UcmFjayBvbiBTb2Z0d2FyaXphdGlvbiwg U2xpY2luZywgQXV0b21hdGlvbiBhbmQgTmV0d29yayBNYW5hZ2VtZW50PC9iPjwvcD4NCjx1bCBj bGFzcz0iIj4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVv dDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+QXJjaGl0ZWN0dXJlcyBhbmQgcHJv dG9jb2xzIGZvciBuZXR3b3JrIGF1dG9tYXRpb24gYW5kIHplcm8tdG91Y2ggbWFuYWdlbWVudC48 L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhl aWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNv bG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0 Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZh bWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+SW50ZWxsaWdlbnQtLCBpbnRlbnQtYmFzZWQg YW5kIGNvZ25pdGl2ZSBuZXR3b3JraW5nIGFuZCBuZXR3b3JrIG1hbmFnZW1lbnQuPC9saT48bGkg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdi KDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3Jt YWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1l bmxvOyIgY2xhc3M9IiI+PC9zcGFuPlByb2dyYW1tYWJsZSBhcmNoaXRlY3R1cmVzIGFuZCBzeXN0 ZW1zIGZvciA1RyBzZXJ2aWNlcyBhbmQgdmVydGljYWxzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFt aWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6 IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIi Pjwvc3Bhbj5BbmFseXNpcyBhbmQgY29uc2lkZXJhdGlvbnMgZm9yIGNvbW1vbiBWTkZzIGFjcm9z cyBmaXhlZCBhbmQgbW9iaWxlIG5ldHdvcmtzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsg Zm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAm cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bh bj41RyBzZXJ2aWNlLWJhc2VkIGFyY2hpdGVjdHVyZSBldm9sdXRpb24uPC9saT48bGkgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2 OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZv bnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIg Y2xhc3M9IiI+PC9zcGFuPk5ldHdvcmsgZnVuY3Rpb25zIHBsYWNlbWVudCBpbiBkaXN0cmlidXRl ZCBjbG91ZHMuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVl JnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPjVHIGZ1bmN0aW9uYWwgZGVj b21wb3NpdGlvbiBhbmQgZGVwbG95bWVudC48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZv bnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1 b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBs aW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+ U2VjdXJlIG9wZXJhdGlvbnMgaW4gZnV0dXJlIHZpcnR1YWxpemVkIG5ldHdvcmtzLjwvbGk+PGxp IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJn Yig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9y bWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBN ZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5SZXNvdXJjZSBtYW5hZ2VtZW50IGFuZCBzaGFyaW5nIGZv ciBuZXR3b3JrIHNsaWNpbmcuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0 Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZl dGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPlNjYWxhYmls aXR5IGFuZCByZWxpYWJpbGl0eSBpbiA1RyBuZXR3b3JrcyBhbmQgNUcgbmV0d29yayBzbGljaW5n LjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Ozsg Y29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3Ry ZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5EZWRpY2F0ZWQgYW5kIHNoYXJlZCBuZXR3 b3JrIGZ1bmN0aW9ucyBpbiBuZXR3b3JrIHNsaWNlcy48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAw cHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWls eTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAx MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48 L3NwYW4+Q3Jvc3Mtc2xpY2UgbWFuYWdlbWVudCBmb3IgZW5kLXRvLWVuZCBRb1MuPC9saT48bGkg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdi KDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3Jt YWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1l bmxvOyIgY2xhc3M9IiI+PC9zcGFuPlByb2dyZXNzIG9uIG5ldHdvcmsgc2xpY2luZyBzdGFuZGFy ZGl6YXRpb24gKGUuZy4gM0dQUCwgR1NNQSwgZXRjLikuPC9saT48bGkgc3R5bGU9Im1hcmdpbjog MHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTog MTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+ PC9zcGFuPkV2YWx1YXRpb24gb2YgbmV0d29yayBzb2Z0d2FyaXphdGlvbiBhbmQgZnVuZGFtZW50 YWwgdHJhZGUtb2Zmcy48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNh IE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+VGVzdC1iZWQgZXhw ZXJpZW5jZSBpbiBzb2Z0d2FyaXphdGlvbiBhbmQgbmV0d29yayBzbGljaW5nLjwvbGk+PGxpIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2 OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFs OyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5s bzsiIGNsYXNzPSIiPjwvc3Bhbj5TRE4gYXJjaGl0ZWN0dXJlcyBhbmQgaW50ZXJmYWNlcy48L2xp PjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9y OiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6 IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWls eTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+U0ROIHByb2dyYW1taW5nIGxhbmd1YWdlcyBhbmQg ZGF0YSBtb2RlbHMuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPlByb2dyZXNzIGFuZCBm dXR1cmUgY2hhbGxlbmdlcyBpbiBzdGFuZGFyZGl6YXRpb24gKGUuZy4gRVRTSSBORlYsIElFVEYv SVJURiwgZXRjLikuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPk9yY2hlc3RyYXRpb24g YW5kIG1hbmFnZW1lbnQgaW4gU0ROIGFuZCBORlYuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4 OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9z cGFuPk11bHRpLWRvbWFpbiBhbmQgbXVsdGktdGVuYW5jeSBjb25zaWRlcmF0aW9ucyBpbiBTRE4g YW5kIE5GVi48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUm cXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+T3BlbiBTb3VyY2UgZWZmb3J0 cyBpbiByZWxhdGlvbiB0byBTRE4gYW5kIE5GViAoZS5nLiwgT05BUCwgT1BORlYsIE9wZW5TdGFj aywgT3BlbiBTb3VyY2UgTUFOTykuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0 cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hl bHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPlFvUy9R b0UgYXNwZWN0cyByZWxhdGVkIHRvIFNETiBhbmQgTkZWIGJhc2VkIG5ldHdvcmsgc2VydmljZXMu PC9saT48L3VsPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAycHg7IGZvbnQtc3RyZXRjaDog bm9ybWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNs YXNzPSIiPg0KPGIgY2xhc3M9IiI+VHJhY2sgb24gQWNjZXNzIE5ldHdvcmssIEVkZ2UgQ29tcHV0 aW5nIGFuZCBUcmFuc3BvcnQgZm9yIDVHPC9iPjwvcD4NCjx1bCBjbGFzcz0iIj4NCjxsaSBzdHls ZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjks IDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsg Zm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87 IiBjbGFzcz0iIj48L3NwYW4+TXVsdGktQWNjZXNzIEVkZ2UgQ29tcHV0aW5nLCBFZGdlLUZvZyBD b21wdXRpbmcuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVl JnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPlJvdXRpbmcgcHJvdG9jb2xz LCBzZWdtZW50IHJvdXRpbmcgYW5kIFZQTiBleHRlbnNpb25zIGZvciA1RyBzbGljaW5nLjwvbGk+ PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6 IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDog bm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5NdWx0aS10ZW5hbmN5LCBzbGljaW5nLCBhbmQgY29u dHJvbCBvZiBtdWx0aS1kb21haW4gaGV0ZXJvZ2VuZW91cyBpbmZyYXN0cnVjdHVyZXMuPC9saT48 bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjog cmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBu b3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPlNETiBhbmQgTkZWIGluIGFjY2VzcywgZWRnZSwgYW5k IHRyYW5zcG9ydCBmb3IgNUc8L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRj aDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0 aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdo dDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+VHJhbnNwb3J0 aW5nIDVHIG1vYmlsZSBzZXJ2aWNlcyBvdmVyIG9wdGljYWwgYWNjZXNzIG5ldHdvcmtzLjwvbGk+ PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6 IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDog bm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5TRE4gc29sdXRpb25zIGZvciBtb2JpbGUgbmV0d29y a3MgYW5kIGZpeGVkIElQIGNyb3NzIGxheWVyIHRyYW5zcG9ydCBhbmQgcm91dGluZy48L2xpPjxs aSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiBy Z2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5v cm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87IiBjbGFzcz0iIj48L3NwYW4+NUcgYXJjaGl0ZWN0dXJlcyBzdXBwb3J0aW5nIENsb3Vk LVJBTiBhbmQgZnVuY3Rpb25hbCBzcGxpdCBvcHRpb25zLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFt aWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6 IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIi Pjwvc3Bhbj41RyBhcmNoaXRlY3R1cmVzIHN1cHBvcnRpbmcgZnJvbnRoYXVsL21pZGRsZWhhdWwv YmFja2hhdWwgaW50ZWdyYXRpb24uPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0 cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hl bHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPk5ldHdv cmsgc2xpY2luZyBpc3N1ZXMgd2l0aCBtdWx0aS1SQVRzIGRldmljZXMuPC9saT48bGkgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2 OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZv bnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIg Y2xhc3M9IiI+PC9zcGFuPkVuZC10by0gZW5kIHJlc291cmNlIG9wdGltaXphdGlvbiBmb3IgNUcg bW9iaWxlIHNlcnZpY2VzOiBmcm9tIHJhZGlvIGhlYWQgdG8gZGF0YSBjZW50ZXIuPC9saT48bGkg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdi KDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBub3Jt YWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1l bmxvOyIgY2xhc3M9IiI+PC9zcGFuPkludGVncmF0ZWQgYmFja2hhdWwvbWlkZGxlaGF1bC9mcm9u dGhhdWw8L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVv dDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+QmFja2hhdWwvbWlkZGxlaGF1bC9m cm9udGhhdWwgY29uc2lkZXJhdGlvbnMgZm9yIGR5bmFtaWMgY2FwYWNpdHkgYW5kIG1vYmlsaXR5 IG1hbmFnZW1lbnQuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPkRlbGl2ZXJpbmcgc2Vy dmljZXMgb3ZlciBJQ04gaW4gNUcgd2l0aGluIGEgZnJhbWV3b3JrIGVuYWJsaW5nIG5ldHdvcmsg c2xpY2luZy48L2xpPjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUm cXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogTWVubG87IiBjbGFzcz0iIj48L3NwYW4+RW5oYW5jaW5nIDVHIGJhY2to YXVsL21pZGRsZWhhdWwvZnJvbnRoYXVsIHdpdGggSUNOLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFt aWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6 IDEwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIi Pjwvc3Bhbj5NZWNoYW5pc21zIGFuZCBwcm90b2NvbCBlbmhhbmNlbWVudHMgZm9yIEh5YnJpZCBB Y2Nlc3MgbmV0d29ya3MuPC9saT48bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zdHJldGNoOiBub3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPkludHJvZHVjdGlv biBvZiBFVFNJIE1FQyB0ZWNobm9sb2d5IGFuZCBhcHBsaWNhdGlvbnMgb24gdmVydGljYWwgbWFy a2V0IHNlZ21lbnRzLjwvbGk+PGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2Eg TmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDEwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsiIGNsYXNzPSIiPjwvc3Bhbj5OZXcgdXNlciBhcHBs aWNhdGlvbnMgYXQgdGhlIGVkZ2Ugb2YgdGhlIGNvbW11bmljYXRpb24gbmV0d29yay48L2xpPjxs aSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiBy Z2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXN0cmV0Y2g6IG5v cm1hbDsgZm9udC1zaXplOiAxMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87IiBjbGFzcz0iIj48L3NwYW4+VmVydGljYWwgaW5kdXN0cnkgaW1wbGljYXRpb25zIHRv IHRyYW5zcG9ydCwgZWRnZSBjb21wdXRpbmcsIGFuZCA1RyBhY2Nlc3MgbmV0d29ya3MuPC9saT48 bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjog cmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zdHJldGNoOiBu b3JtYWw7IGZvbnQtc2l6ZTogMTBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6 IE1lbmxvOyIgY2xhc3M9IiI+PC9zcGFuPkluc2lnaHRzIG9uIHBpbG90cywgcHJvb2Ytb2YtY29u Y2VwdCwgYW5kIHByb3RvdHlwZXMgb24gYWNjZXNzLCBlZGdlLCBhbmQgdHJhbnNwb3J0IG5ldHdv cmtzLjwvbGk+PC91bD4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBm b250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZx dW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9 IiI+DQpBdXRob3JzIG9mIHNlbGVjdGVkIHBhcGVycyBmcm9tIElFRUUgQ1NDTiAyMDE5IHdpbGwg YmUgaW52aXRlZCB0byBzdWJtaXQgYW4gZXh0ZW5kZWQgYW5kIGltcHJvdmVkIHZlcnNpb24gdG8g SUVFRSBTdGFuZGFyZHMgTWFnYXppbmUgc3BlY2lhbCBpc3N1ZS48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg Zm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2 OSwgNjkpOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBj b2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmUiIGNsYXNzPSIiPlNVQk1JU1NJT048L3NwYW4+PC9kaXY+DQo8cCBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2Io NjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOzwvcD4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwg NjkpOyIgY2xhc3M9IiI+DQpBbGwgc3VibWlzc2lvbnMgaGF2ZSB0byBjb21wbHkgd2l0aCBJRUVF 4oCZcyBndWlkZWxpbmVzLiBJbml0aWFsIHN1Ym1pc3Npb25zIGZvciByZXZpZXcgYXJlIGxpbWl0 ZWQgdG8gc2V2ZW4gKDcpIHBhZ2VzLiBDYW1lcmEtcmVhZHkgcGFwZXJzIHNob3VsZCBub3QgZXhj ZWVkIHNpeCAoNikgcGFnZXMgZm9yIGxvbmcgcGFwZXJzLCBhbmQgKDQpIHBhZ2VzIGZvciBzaG9y dCBwYXBlcnMsIGluY2x1ZGluZyBmaWd1cmVzIHdpdGhvdXQgaW5jdXJyaW5nIGFkZGl0aW9uYWwN CiBwYWdlIGNoYXJnZXMgKG1heGltdW0gMSBhZGRpdGlvbmFsIHBhZ2Ugd2l0aCBvdmVyIGxlbmd0 aCBwYWdlIGNoYXJnZSkuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsgbWluLWhlaWdo dDogMTRweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYigyMjgsIDE3 NSwgMTApOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6ICM0NTQ1NDUiIGNsYXNzPSIi PlRoZSBzdWJtaXNzaW9uIFVSTCBpczogPGEgaHJlZj0iaHR0cHM6Ly9jc2NuMjAxOS5pZWVlLWNz Y24ub3JnL2F1dGhvcnMvIiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogI2U0YWYwYSIg Y2xhc3M9IiI+aHR0cHM6Ly9jc2NuMjAxOS5pZWVlLWNzY24ub3JnL2F1dGhvcnMvPC9zcGFuPjwv YT4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRj aDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0 aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IiBjbGFzcz0iIj4NCiZuYnNw OzwvcD4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7 OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOiB1bmRlcmxpbmUiIGNsYXNzPSIiPklNUE9SVEFOVCBEQVRFUzwvc3Bhbj48L2Rp dj4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29s b3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KJm5ic3A7PC9wPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwcHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjksIDY5 LCA2OSk7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1Ym1pc3Npb24gRGVhZGxpbmU6PC9iPiZu YnNwOzEgSnVuZSAyMDE5PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+QWNjZXB0YW5jZSBOb3Rp ZmljYXRpb246PC9iPiZuYnNwOzEgU2VwdGVtYmVyIDIwMTk8YnIgY2xhc3M9IiI+DQo8YiBjbGFz cz0iIj5DYW1lcmEtUmVhZHk6PC9iPiZuYnNwOzEgT2N0b2JlciAyMDE5PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2 OSwgNjksIDY5KTsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNoOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90 OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9InRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lIiBjbGFzcz0iIj5PUkdBTklTSU5HIENPTU1JVFRFRTwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1 b3Q7OyBjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMnB4OyBm b250LXN0cmV0Y2g6IG5vcm1hbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7IGNvbG9yOiByZ2IoNjks IDY5LCA2OSk7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkdlbmVyYWwgQ28tQ2hhaXJzPC9iPjwv cD4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7OyBj b2xvcjogcmdiKDY5LCA2OSwgNjkpOyIgY2xhc3M9IiI+DQpQcm9mLiBUYXJpayBUYWxlYiAoQWFs dG8gVW5pdmVyc2l0eSwgRmlubGFuZCk8YnIgY2xhc3M9IiI+DQpQcm9mLiBKdWFuIE0uIExvcGV6 LVNvbGVyIChVbml2ZXJzaXR5IG9mIEdyYW5hZGEsIFNwYWluKTwvZGl2Pg0KPHAgc3R5bGU9Im1h cmdpbjogMHB4IDBweCAycHg7IGZvbnQtc3RyZXRjaDogbm9ybWFsOyBmb250LXNpemU6IDE0cHg7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VFBD IENvLUNoYWlyczwvYj48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zdHJldGNo OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiAmcXVvdDtIZWx2ZXRp Y2EgTmV1ZSZxdW90OzsgY29sb3I6IHJnYig2OSwgNjksIDY5KTsiIGNsYXNzPSIiPg0KUHJvZi4g QXJ0dXJvIEF6Y29ycmEgKElNREVBIE5ldHdvcmtzIEluc3RpdHV0ZSwgU3BhaW4pPGJyIGNsYXNz PSIiPg0KUHJvZi4gTmFyY2lzIENhcmRvbmEgKFVuaXZlcnNpdGF0IFBvbGl0w6hjbmljYSBkZSBW YWzDqG5jaWEsIFNwYWluKTxiciBjbGFzcz0iIj4NCkRyLiBJbWVuIEdyaWRhIEJlbnlhaGlhIChP cmFuZ2UgTGFicywgRnJhbmNlKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E42EBA8558694A0FB66F77719B5F4E92kclacuk_-- From nobody Sat Mar 16 04:47:59 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 907AA127988 for ; Sat, 16 Mar 2019 04:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6g6BsTHtypvt for ; Sat, 16 Mar 2019 04:47:54 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415D112762F for ; Sat, 16 Mar 2019 04:47:53 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 8E233180286C3; Sat, 16 Mar 2019 11:47:52 +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=OVCcQvLnF2biXXYWai ADNItjM9UDqtzadjSdjfA+kPw=; b=q574S5qx/a8896fBJWyJMSHjGNzfZ4q8hO 7Rp2MISfBPOUYrW96VZYTc4LD0DtEVpgQrfK3GwG39SIkkp3n4g4/ytX6zVOTOIr KsVbo2R75Nuu5FUZbbhu5bHcSaWvlB1ftjMgdQijlb+mvldqCtW2VREJGFCD/rOP 5q6G28hBg= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::, RULES_HIT:72:152:327:355:379:582:599:962:967:973:982:983:988:989:1042:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1617:1730:1776:1792:2068:2069:2194:2196:2198:2199:2200:2201:2525:2527:2528:2557:2568:2610:2628:2682:2685:2693:2859:2891:2894:2900:2901:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4362:4384:4425:4860:5007:6261:6650:6657:6659:6678:7782:7875:7901:7903:7974:8568:8583:8603:8660:8957:9010:9025:9080:9149:9177:10004:10848:11232:11914:12043:12291:12379:12438:12485:12555:12663:12683:12700:12737:12740:12895:12986:13129:13137:13139:13148:13149:13150:13153:13157:13158:13228:13230:13231:13846:14096:21060:21063:21080:21427:21433:21451:21524:21611:21627:21740:21774:21795:21881:30003:30011:30028:30051:30054:30056:30 X-HE-Tag: band49_7ee4474b5e521 X-Filterd-Recvd-Size: 46145 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf03.hostedemail.com (Postfix) with ESMTPA; Sat, 16 Mar 2019 11:47:51 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_d28906833144a76a576aef3a53bf92ff" Date: Sat, 16 Mar 2019 04:47:51 -0700 From: Peter van der Stok To: Routing Over Low power and Lossy networks Cc: INES ROBLES 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] ***IEEE CSCN 2019*** 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, 16 Mar 2019 11:47:59 -0000 --=_d28906833144a76a576aef3a53bf92ff Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 HI Mona, It is good practice to ask permission to mis-use this mailing list for CFPs. We would certainly not have approved the sending of this CFP. Please try to remember that IETF WG mailing lists are only used for WG matters !!!!! Do inform your colleagues. Thanks, peter Ghassemian, Mona schreef op 2019-03-15 16:22: > [Apologies if you receive multiple copies of this message] > ****************************************************** > The 5th IEEE Conference on Standards for Communications & Networking (IEEE CSCN'19) > 28-30 October 2019 // Granada, Spain > https://cscn2019.ieee-cscn.org/ > ****************************************************** > > CALL FOR PAPERS > > On behalf of the Organizing Committee, we have great pleasure in inviting you to submit your work to the 2019 IEEE Conference on Standards for Communications & Networking (IEEE CSCN'19). The fifth edition of this highly successful conference will be held in Granada, Spain, the city of the world-famous Alhambra, one of the ten most visited monuments around the world. > Standards play a key role in the success of the communications industry, as enablers of global systems inter-operability and economies of scale. The finalization of the 3GPP release 15 in June 2018 was a major milestone. With the first 5G specifications now complete, the industry has achieved critical progress on technology readiness, and operators around the world are starting the commercial rollout. This represents the culmination of years of concerted industry and academia efforts in scoping out and designing the next generation of mobile systems. Past editions of IEEE CSCN have played their own part in these efforts. > In 2019, IEEE CSCN will be divided into 4 tracks designed to cover the diverse space of technologies - not limited to cellular systems-. New, original and previously unpublished papers are invited that address the emerging connectivity solutions and the standardization approaches and strategies that these may take, as well as the relevant business models and use-cases. > Additionally, after the recent completion of 3GPP release 15, of special interest are papers that assess the wireless landscape in light of the recently completed release of NR standard. Not only the Non-Standalone version, but also the Standalone version which delivers the potential for 5G deployments independent of LTE. > > We are pleased to invite you to submit an original an previously unpublished paper on (but not limited to) the topics of the following tracks. > > TRACK ON IOT, URLLC AND V2X > > * IoT architecture design options and system optimizations. > * IoT security and privacy of IoT devices and services. > * System optimization to support ultra-low complexity devices. > * Radio access optimizations for ultra-low power devices. > * Standardized semantic data description framework and technologies. > * IoT communication procedure enhancements. > * Experience and lessons learnt from IoT large-scale pilots. > * IoT standards platforms interworking. > * IoT interoperability methodologies. > * IoT standards gap analysis. > * 5G networks, IoT and Tactile Internet. > * Software Defined Network (SDN) and IoT. > * Industrial Internet of Things. > * Factory of things. > * Edge computing, fog computing and IoT. > * IPv6-based IoT networks. > * IoT protocols such as IPv6, 6LoWPAN, RPL, 6TiSCH, WoT. > * IoT security aspects for massive IoT deployments, e.g., embedded SIM management. > * Ultra-Reliable Low-Latency Communications (URLLC). > * URLLC for mission-critical IoT. > * V2X standards and architectures. > * Private LTE/ 5G networks. > > TRACK ON 5G RADIO AND WIRELESS COMMUNICATIONS > > * Physical layer and MAC layer design for 5G-enabling wireless networks. > * Dynamic scheduling, power control, interference management, and QoS management in 5G. > * Techniques for latency reduction in 5G. > * Resource management and control in 5G RAN. > * Service-oriented user-plane design concepts. > * Topology, deployment, and optimization of wireless networks. > * Wireless technology for high speed. > * mmWave access, backhaul and self-backhauling. > * Application of SDN, NFV, and cloud computing to 5G (and legacy) RAN and core network architectures and implementations, such as network slicing. > * 3GPP phased work on NR. > * Green and energy efficient wireless networks. > * Solutions for battery-conserving, interference-mitigating terminal design. > * Massive and FD-MIMO communications, hybrid and coordinated beamforming technology. > * New control signaling for heterogeneous networks. > * Next-Generation Wi-Fi (IEEE 802.11ax/ay). > * 5G-LTE interworking and 5G/LTE -- Wi-Fi/Wi-Gig interworking technology. > * 5G operation and coexistence in unlicensed and shared spectrum bands. > * Next-generation non-RF communications systems. > * 5G Radio Results from simulation, prototyping, and experiments. > * Emerging candidate technologies and business use-cases for Beyond 5G. > > TRACK ON SOFTWARIZATION, SLICING, AUTOMATION AND NETWORK MANAGEMENT > > * Architectures and protocols for network automation and zero-touch management. > * Intelligent-, intent-based and cognitive networking and network management. > * Programmable architectures and systems for 5G services and verticals. > * Analysis and considerations for common VNFs across fixed and mobile networks. > * 5G service-based architecture evolution. > * Network functions placement in distributed clouds. > * 5G functional decomposition and deployment. > * Secure operations in future virtualized networks. > * Resource management and sharing for network slicing. > * Scalability and reliability in 5G networks and 5G network slicing. > * Dedicated and shared network functions in network slices. > * Cross-slice management for end-to-end QoS. > * Progress on network slicing standardization (e.g. 3GPP, GSMA, etc.). > * Evaluation of network softwarization and fundamental trade-offs. > * Test-bed experience in softwarization and network slicing. > * SDN architectures and interfaces. > * SDN programming languages and data models. > * Progress and future challenges in standardization (e.g. ETSI NFV, IETF/IRTF, etc.). > * Orchestration and management in SDN and NFV. > * Multi-domain and multi-tenancy considerations in SDN and NFV. > * Open Source efforts in relation to SDN and NFV (e.g., ONAP, OPNFV, OpenStack, Open Source MANO). > * QoS/QoE aspects related to SDN and NFV based network services. > > TRACK ON ACCESS NETWORK, EDGE COMPUTING AND TRANSPORT FOR 5G > > * Multi-Access Edge Computing, Edge-Fog Computing. > * Routing protocols, segment routing and VPN extensions for 5G slicing. > * Multi-tenancy, slicing, and control of multi-domain heterogeneous infrastructures. > * SDN and NFV in access, edge, and transport for 5G > * Transporting 5G mobile services over optical access networks. > * SDN solutions for mobile networks and fixed IP cross layer transport and routing. > * 5G architectures supporting Cloud-RAN and functional split options. > * 5G architectures supporting fronthaul/middlehaul/backhaul integration. > * Network slicing issues with multi-RATs devices. > * End-to- end resource optimization for 5G mobile services: from radio head to data center. > * Integrated backhaul/middlehaul/fronthaul > * Backhaul/middlehaul/fronthaul considerations for dynamic capacity and mobility management. > * Delivering services over ICN in 5G within a framework enabling network slicing. > * Enhancing 5G backhaul/middlehaul/fronthaul with ICN. > * Mechanisms and protocol enhancements for Hybrid Access networks. > * Introduction of ETSI MEC technology and applications on vertical market segments. > * New user applications at the edge of the communication network. > * Vertical industry implications to transport, edge computing, and 5G access networks. > * Insights on pilots, proof-of-concept, and prototypes on access, edge, and transport networks. > > Authors of selected papers from IEEE CSCN 2019 will be invited to submit an extended and improved version to IEEE Standards Magazine special issue. > > SUBMISSION > > All submissions have to comply with IEEE's guidelines. Initial submissions for review are limited to seven (7) pages. Camera-ready papers should not exceed six (6) pages for long papers, and (4) pages for short papers, including figures without incurring additional page charges (maximum 1 additional page with over length page charge). > > The submission URL is: https://cscn2019.ieee-cscn.org/authors/ [1] > > IMPORTANT DATES > > SUBMISSION DEADLINE: 1 June 2019 > ACCEPTANCE NOTIFICATION: 1 September 2019 > CAMERA-READY: 1 October 2019 > > ORGANISING COMMITTEE > > GENERAL CO-CHAIRS > > Prof. Tarik Taleb (Aalto University, Finland) > Prof. Juan M. Lopez-Soler (University of Granada, Spain) > > TPC CO-CHAIRS > > Prof. Arturo Azcorra (IMDEA Networks Institute, Spain) > Prof. Narcis Cardona (Universitat Politècnica de València, Spain) > Dr. Imen Grida Benyahia (Orange Labs, France) > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Links: ------ [1] https://cscn2019.ieee-cscn.org/authors/ --=_d28906833144a76a576aef3a53bf92ff Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Mona,

It is good practice to ask permission to mis-use this m= ailing list for CFPs.
We would certainly not have approved the sending= of this CFP.

Please try to remember that IETF WG mailing lists = are only used for WG matters !!!!!
Do inform your colleagues.
Thanks,

peter

Ghassemian, Mona schreef op 2019-03-15 16:22:

 

 

[Apologies if you receive multip= le copies of this message]
********************************= **********************
The 5th IEEE Conference on Stand= ards for Communications & Networking (IEEE CSCN'19)
28-30 October 2019 // Granada, S= pain
********************************= **********************

 

CALL FOR PAPERS

 

On behalf of the Organizing Comm= ittee, we have great pleasure in inviting you to submit your work to the 20= 19 IEEE Conference on Standards for Communications & Networking (IEEE C= SCN'19). The fifth edition of this highly successful conference will be hel= d in Granada, Spain, the city of the world-famous Alhambra, one of the ten = most visited monuments around the world.
Standards play a key role in the= success of the communications industry, as enablers of global systems inte= r-operability and economies of scale. The finalization of the 3GPP release = 15 in June 2018 was a major milestone. With the first 5G specifications now= complete, the industry has achieved critical progress on technology readin= ess, and operators around the world are starting the commercial rollout. Th= is represents the culmination of years of concerted industry and academia e= fforts in scoping out and designing the next generation of mobile systems= =2E Past editions of IEEE CSCN have played their own part in these efforts= =2E 
In 2019, IEEE CSCN will be divid= ed into 4 tracks designed to cover the diverse space of technologies &ndash= ; not limited to cellular systems–. New, original and previously unpu= blished papers are invited that address the emerging connectivity solutions= and the standardization approaches and strategies that these may take, as = well as the relevant business models and use-cases.
Additionally, after the recent c= ompletion of 3GPP release 15, of special interest are papers that assess th= e wireless landscape in light of the recently completed release of NR stand= ard. Not only the Non-Standalone version, but also the Standalone version w= hich delivers the potential for 5G deployments independent of LTE.
 
We are pleased to invite you to = submit an original an previously unpublished paper on (but not limited to) = the topics of the following tracks.

 

T= rack on IoT, URLLC and V2X

  • IoT a= rchitecture design options and system optimizations.
  • IoT s= ecurity and privacy of IoT devices and services.
  • Syste= m optimization to support ultra-low complexity devices.
  • Radio= access optimizations for ultra-low power devices.
  • Stand= ardized semantic data description framework and technologies.
  • IoT c= ommunication procedure enhancements.
  • Exper= ience and lessons learnt from IoT large-scale pilots.
  • IoT s= tandards platforms interworking.
  • IoT i= nteroperability methodologies.
  • IoT s= tandards gap analysis.
  • 5G ne= tworks, IoT and Tactile Internet.
  • Softw= are Defined Network (SDN) and IoT.
  • Indus= trial Internet of Things.
  • Facto= ry of things.
  • Edge = computing, fog computing and IoT.
  • IPv6-= based IoT networks.
  • IoT p= rotocols such as IPv6, 6LoWPAN, RPL, 6TiSCH, WoT.
  • IoT s= ecurity aspects for massive IoT deployments, e.g., embedded SIM management= =2E
  • Ultra= -Reliable Low-Latency Communications (URLLC).
  • URLLC= for mission-critical IoT.
  • V2X s= tandards and architectures.
  • Priva= te LTE/ 5G networks.

T= rack on 5G Radio and Wireless Communications

  • Physi= cal layer and MAC layer design for 5G-enabling wireless networks.
  • Dynam= ic scheduling, power control, interference management, and QoS management i= n 5G.
  • Techn= iques for latency reduction in 5G.
  • Resou= rce management and control in 5G RAN.
  • Servi= ce-oriented user-plane design concepts.
  • Topol= ogy, deployment, and optimization of wireless networks.
  • Wirel= ess technology for high speed.
  • mmWav= e access, backhaul and self-backhauling.
  • Appli= cation of SDN, NFV, and cloud computing to 5G (and legacy) RAN and core net= work architectures and implementations, such as network slicing.
  • 3GPP = phased work on NR.
  • Green= and energy efficient wireless networks.
  • Solut= ions for battery-conserving, interference-mitigating terminal design.
  • Massi= ve and FD-MIMO communications, hybrid and coordinated beamforming technolog= y.
  • New c= ontrol signaling for heterogeneous networks.
  • Next-= Generation Wi-Fi (IEEE 802.11ax/ay).
  • 5G-LT= E interworking and 5G/LTE — Wi-Fi/Wi-Gig interworking technology.
  • 5G op= eration and coexistence in unlicensed and shared spectrum bands.
  • Next-= generation non-RF communications systems.
  • 5G Ra= dio Results from simulation, prototyping, and experiments.
  • Emerg= ing candidate technologies and business use-cases for Beyond 5G.

T= rack on Softwarization, Slicing, Automation and Network Management=

  • Archi= tectures and protocols for network automation and zero-touch management.
  • Intel= ligent-, intent-based and cognitive networking and network management.
  • Progr= ammable architectures and systems for 5G services and verticals.
  • Analy= sis and considerations for common VNFs across fixed and mobile networks.
  • 5G se= rvice-based architecture evolution.
  • Netwo= rk functions placement in distributed clouds.
  • 5G fu= nctional decomposition and deployment.
  • Secur= e operations in future virtualized networks.
  • Resou= rce management and sharing for network slicing.
  • Scala= bility and reliability in 5G networks and 5G network slicing.
  • Dedic= ated and shared network functions in network slices.
  • Cross= -slice management for end-to-end QoS.
  • Progr= ess on network slicing standardization (e.g. 3GPP, GSMA, etc.).
  • Evalu= ation of network softwarization and fundamental trade-offs.
  • Test-= bed experience in softwarization and network slicing.
  • SDN a= rchitectures and interfaces.
  • SDN p= rogramming languages and data models.
  • Progr= ess and future challenges in standardization (e.g. ETSI NFV, IETF/IRTF, etc= =2E).
  • Orche= stration and management in SDN and NFV.
  • Multi= -domain and multi-tenancy considerations in SDN and NFV.
  • Open = Source efforts in relation to SDN and NFV (e.g., ONAP, OPNFV, OpenStack, Op= en Source MANO).
  • QoS/Q= oE aspects related to SDN and NFV based network services.

T= rack on Access Network, Edge Computing and Transport for 5G

  • Multi= -Access Edge Computing, Edge-Fog Computing.
  • Routi= ng protocols, segment routing and VPN extensions for 5G slicing.
  • Multi= -tenancy, slicing, and control of multi-domain heterogeneous infrastructure= s.
  • SDN a= nd NFV in access, edge, and transport for 5G
  • Trans= porting 5G mobile services over optical access networks.
  • SDN s= olutions for mobile networks and fixed IP cross layer transport and routing= =2E
  • 5G ar= chitectures supporting Cloud-RAN and functional split options.
  • 5G ar= chitectures supporting fronthaul/middlehaul/backhaul integration.
  • Netwo= rk slicing issues with multi-RATs devices.
  • End-t= o- end resource optimization for 5G mobile services: from radio head to dat= a center.
  • Integ= rated backhaul/middlehaul/fronthaul
  • Backh= aul/middlehaul/fronthaul considerations for dynamic capacity and mobility m= anagement.
  • Deliv= ering services over ICN in 5G within a framework enabling network slicing= =2E
  • Enhan= cing 5G backhaul/middlehaul/fronthaul with ICN.
  • Mecha= nisms and protocol enhancements for Hybrid Access networks.
  • Intro= duction of ETSI MEC technology and applications on vertical market segments= =2E
  • New u= ser applications at the edge of the communication network.
  • Verti= cal industry implications to transport, edge computing, and 5G access netwo= rks.
  • Insig= hts on pilots, proof-of-concept, and prototypes on access, edge, and transp= ort networks.
 
Authors of selected papers from = IEEE CSCN 2019 will be invited to submit an extended and improved version t= o IEEE Standards Magazine special issue.
 
SUBMISSION

  

All submissions have to comply w= ith IEEE's guidelines. Initial submissions for review are limited to seven = (7) pages. Camera-ready papers should not exceed six (6) pages for long pap= ers, and (4) pages for short papers, including figures without incurring ad= ditional page charges (maximum 1 additional page with over length page char= ge). 
 

 

IMPORTANT DATES

 

Submission Deadline: 1 June 2019
Acceptance Notification: = ;1 September 2019
Camera-Ready: 1 October 2019<= /div>
 
ORGANISING COMMITTEE
 

G= eneral Co-Chairs

Prof. Tarik Taleb (Aalto Univers= ity, Finland)
Prof. Juan M. Lopez-Soler (University of Granada, Spain= )

T= PC Co-Chairs

Prof. Arturo Azcorra (IMDEA Netw= orks Institute, Spain)
Prof. Narcis Cardona (Universitat Politè= ;cnica de València, Spain)
Dr. Imen Grida Benyahia (Orange Lab= s, France)
 

= _______________________________________________
Roll mailing list
Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
--=_d28906833144a76a576aef3a53bf92ff-- From nobody Sat Mar 16 07:35:45 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 9939012D4EF for ; Sat, 16 Mar 2019 07:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kcl.ac.uk 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 l4rrtkGoobog for ; Sat, 16 Mar 2019 07:35:37 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20123.outbound.protection.outlook.com [40.107.2.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC35128CF2 for ; Sat, 16 Mar 2019 07:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kcl.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f4lREYHtRL6VJ+zIlug/8ExMlhmSlx5UTeqcTvKMxhA=; b=kRU0IutRJoktuT4WLwryT8YvUzcSG6CoVNp6d871T8xNJYBiANJUcIX1VZ2bQvMg6kC3/utYGKxgWCHjkdL8kOQU0l1ktYnI/KtEIuiCCjo61wG06dKUywF89aVYknOQBeq9XAYoVoYn0jpHgNm0az0ND1lxUEEGm41pwfdzIJQ= Received: from DB7PR03MB4523.eurprd03.prod.outlook.com (20.176.234.147) by DB7PR03MB4059.eurprd03.prod.outlook.com (52.135.137.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Sat, 16 Mar 2019 14:35:29 +0000 Received: from DB7PR03MB4523.eurprd03.prod.outlook.com ([fe80::5577:768:8c8a:91be]) by DB7PR03MB4523.eurprd03.prod.outlook.com ([fe80::5577:768:8c8a:91be%2]) with mapi id 15.20.1709.011; Sat, 16 Mar 2019 14:35:29 +0000 From: "Ghassemian, Mona" To: "roll@ietf.org" , "roll@ietf.org" Thread-Topic: Roll Digest, Vol 134, Issue 9 Thread-Index: AQHU2+4mCDG8B3mOTUio/qlB9HDHCKYOUqNM Date: Sat, 16 Mar 2019 14:35:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mona.ghassemian@kcl.ac.uk; x-originating-ip: [52.142.119.224] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7acd48ed-f729-4037-f298-08d6aa1ca364 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DB7PR03MB4059; x-ms-traffictypediagnostic: DB7PR03MB4059: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09781D4C35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(396003)(136003)(189003)(27574002)(199004)(18543002)(10533003)(81166006)(486006)(33656002)(446003)(81156014)(8676002)(6246003)(229853002)(476003)(316002)(110136005)(66574012)(14444005)(5024004)(786003)(55016002)(6306002)(3846002)(54896002)(53936002)(256004)(11346002)(99286004)(74482002)(186003)(9686003)(66066001)(6116002)(606006)(52536014)(236005)(2906002)(26005)(5660300002)(74316002)(76176011)(102836004)(53546011)(478600001)(45080400002)(6506007)(7736002)(30864003)(97736004)(71190400001)(2501003)(71200400001)(105586002)(68736007)(106356001)(8936002)(6436002)(14454004)(966005)(25786009)(7696005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR03MB4059; H:DB7PR03MB4523.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: kcl.ac.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: E3EwLZTwJ9XosTVrGAFGvyDLfZh/bXL/mnGvEAAupVbFjjhRv1/mLNABGab+FMJC9G+yfCSPvzZXbQhFrJjZAKpXcoyk69E4XKTnjS4G/xYaG6CCxfTW9e57druGNb97FCDyADToyjLFCnr0t0jFs/gy3XAHGcG4pmekYXvmWt3Kes5c1xc2tluk2wpSiYItz1hGc/7KEG7sywtRGjDFutcK86GK5n6PpzTElTji/W3IfNV9AFh31puu5ctaEmfNq28+mesVdUGNh4ZIvOGgeBHzDjHZi8VBe5EJJbIBgdkTFGWvjnuRYwar0TsGC8YFsCn/biiUHijw4I5AdLFGy5JK8HqPcWXKwcc3YyaZbskwq2HPn6czCALiz3GhFPBuDRqmrjazHFH3aemJTuFKXcaOZA2asyFn0EXEu1Nbgtc= Content-Type: multipart/alternative; boundary="_000_DB7PR03MB452372F2A5E9E984E21A3BDDA1450DB7PR03MB4523eurp_" MIME-Version: 1.0 X-OriginatorOrg: kcl.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 7acd48ed-f729-4037-f298-08d6aa1ca364 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2019 14:35:29.4770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8370cf14-16f3-4c16-b83c-724071654356 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR03MB4059 Archived-At: Subject: Re: [Roll] Roll Digest, Vol 134, Issue 9 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, 16 Mar 2019 14:35:44 -0000 --_000_DB7PR03MB452372F2A5E9E984E21A3BDDA1450DB7PR03MB4523eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, Apologies for my lack of knowledge. I have been a member for a long time an= d often receive call for papers even recently, hence assumed it is possible= to use it for publicity of the event. If I can know how the approval works, I will request it for future events t= hat I will be helping as the publicity chair. Regards, Mona Get Outlook for iOS ________________________________ From: Roll on behalf of roll-request@ietf.org Sent: Saturday, March 16, 2019 11:48 am To: roll@ietf.org Subject: Roll Digest, Vol 134, Issue 9 Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Froll&data=3D01%7C01%7Cmona.ghassemian%40kc= l.ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c7240716543= 56%7C0&sdata=3D%2BCYy79ucBnzKEMpZ0E73tQi9HbWAUU6LRi2GegGZ9vY%3D&res= erved=3D0 or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Re: ***IEEE CSCN 2019*** (Peter van der Stok) ---------------------------------------------------------------------- Message: 1 Date: Sat, 16 Mar 2019 04:47:51 -0700 From: Peter van der Stok To: Routing Over Low power and Lossy networks Cc: INES ROBLES Subject: Re: [Roll] ***IEEE CSCN 2019*** Message-ID: Content-Type: text/plain; charset=3D"utf-8" HI Mona, It is good practice to ask permission to mis-use this mailing list for CFPs. We would certainly not have approved the sending of this CFP. Please try to remember that IETF WG mailing lists are only used for WG matters !!!!! Do inform your colleagues. Thanks, peter Ghassemian, Mona schreef op 2019-03-15 16:22: > [Apologies if you receive multiple copies of this message] > ****************************************************** > The 5th IEEE Conference on Standards for Communications & Networking (IEE= E CSCN'19) > 28-30 October 2019 // Granada, Spain > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fcscn2= 019.ieee-cscn.org%2F&data=3D01%7C01%7Cmona.ghassemian%40kcl.ac.uk%7C7ff= 89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c724071654356%7C0&sd= ata=3DyasZLF2zJHhB27Prvc%2BOvkb3vefBDGIZNFuFo2KETcs%3D&reserved=3D0 > ****************************************************** > > CALL FOR PAPERS > > On behalf of the Organizing Committee, we have great pleasure in inviting= you to submit your work to the 2019 IEEE Conference on Standards for Commu= nications & Networking (IEEE CSCN'19). The fifth edition of this highly suc= cessful conference will be held in Granada, Spain, the city of the world-fa= mous Alhambra, one of the ten most visited monuments around the world. > Standards play a key role in the success of the communications industry, = as enablers of global systems inter-operability and economies of scale. The= finalization of the 3GPP release 15 in June 2018 was a major milestone. Wi= th the first 5G specifications now complete, the industry has achieved crit= ical progress on technology readiness, and operators around the world are s= tarting the commercial rollout. This represents the culmination of years of= concerted industry and academia efforts in scoping out and designing the n= ext generation of mobile systems. Past editions of IEEE CSCN have played th= eir own part in these efforts. > In 2019, IEEE CSCN will be divided into 4 tracks designed to cover the di= verse space of technologies - not limited to cellular systems-. New, origin= al and previously unpublished papers are invited that address the emerging = connectivity solutions and the standardization approaches and strategies th= at these may take, as well as the relevant business models and use-cases. > Additionally, after the recent completion of 3GPP release 15, of special = interest are papers that assess the wireless landscape in light of the rece= ntly completed release of NR standard. Not only the Non-Standalone version,= but also the Standalone version which delivers the potential for 5G deploy= ments independent of LTE. > > We are pleased to invite you to submit an original an previously unpublis= hed paper on (but not limited to) the topics of the following tracks. > > TRACK ON IOT, URLLC AND V2X > > * IoT architecture design options and system optimizations. > * IoT security and privacy of IoT devices and services. > * System optimization to support ultra-low complexity devices. > * Radio access optimizations for ultra-low power devices. > * Standardized semantic data description framework and technologies. > * IoT communication procedure enhancements. > * Experience and lessons learnt from IoT large-scale pilots. > * IoT standards platforms interworking. > * IoT interoperability methodologies. > * IoT standards gap analysis. > * 5G networks, IoT and Tactile Internet. > * Software Defined Network (SDN) and IoT. > * Industrial Internet of Things. > * Factory of things. > * Edge computing, fog computing and IoT. > * IPv6-based IoT networks. > * IoT protocols such as IPv6, 6LoWPAN, RPL, 6TiSCH, WoT. > * IoT security aspects for massive IoT deployments, e.g., embedded SIM ma= nagement. > * Ultra-Reliable Low-Latency Communications (URLLC). > * URLLC for mission-critical IoT. > * V2X standards and architectures. > * Private LTE/ 5G networks. > > TRACK ON 5G RADIO AND WIRELESS COMMUNICATIONS > > * Physical layer and MAC layer design for 5G-enabling wireless networks. > * Dynamic scheduling, power control, interference management, and QoS man= agement in 5G. > * Techniques for latency reduction in 5G. > * Resource management and control in 5G RAN. > * Service-oriented user-plane design concepts. > * Topology, deployment, and optimization of wireless networks. > * Wireless technology for high speed. > * mmWave access, backhaul and self-backhauling. > * Application of SDN, NFV, and cloud computing to 5G (and legacy) RAN and= core network architectures and implementations, such as network slicing. > * 3GPP phased work on NR. > * Green and energy efficient wireless networks. > * Solutions for battery-conserving, interference-mitigating terminal desi= gn. > * Massive and FD-MIMO communications, hybrid and coordinated beamforming = technology. > * New control signaling for heterogeneous networks. > * Next-Generation Wi-Fi (IEEE 802.11ax/ay). > * 5G-LTE interworking and 5G/LTE -- Wi-Fi/Wi-Gig interworking technology. > * 5G operation and coexistence in unlicensed and shared spectrum bands. > * Next-generation non-RF communications systems. > * 5G Radio Results from simulation, prototyping, and experiments. > * Emerging candidate technologies and business use-cases for Beyond 5G. > > TRACK ON SOFTWARIZATION, SLICING, AUTOMATION AND NETWORK MANAGEMENT > > * Architectures and protocols for network automation and zero-touch manag= ement. > * Intelligent-, intent-based and cognitive networking and network managem= ent. > * Programmable architectures and systems for 5G services and verticals. > * Analysis and considerations for common VNFs across fixed and mobile net= works. > * 5G service-based architecture evolution. > * Network functions placement in distributed clouds. > * 5G functional decomposition and deployment. > * Secure operations in future virtualized networks. > * Resource management and sharing for network slicing. > * Scalability and reliability in 5G networks and 5G network slicing. > * Dedicated and shared network functions in network slices. > * Cross-slice management for end-to-end QoS. > * Progress on network slicing standardization (e.g. 3GPP, GSMA, etc.). > * Evaluation of network softwarization and fundamental trade-offs. > * Test-bed experience in softwarization and network slicing. > * SDN architectures and interfaces. > * SDN programming languages and data models. > * Progress and future challenges in standardization (e.g. ETSI NFV, IETF/= IRTF, etc.). > * Orchestration and management in SDN and NFV. > * Multi-domain and multi-tenancy considerations in SDN and NFV. > * Open Source efforts in relation to SDN and NFV (e.g., ONAP, OPNFV, Open= Stack, Open Source MANO). > * QoS/QoE aspects related to SDN and NFV based network services. > > TRACK ON ACCESS NETWORK, EDGE COMPUTING AND TRANSPORT FOR 5G > > * Multi-Access Edge Computing, Edge-Fog Computing. > * Routing protocols, segment routing and VPN extensions for 5G slicing. > * Multi-tenancy, slicing, and control of multi-domain heterogeneous infra= structures. > * SDN and NFV in access, edge, and transport for 5G > * Transporting 5G mobile services over optical access networks. > * SDN solutions for mobile networks and fixed IP cross layer transport an= d routing. > * 5G architectures supporting Cloud-RAN and functional split options. > * 5G architectures supporting fronthaul/middlehaul/backhaul integration. > * Network slicing issues with multi-RATs devices. > * End-to- end resource optimization for 5G mobile services: from radio he= ad to data center. > * Integrated backhaul/middlehaul/fronthaul > * Backhaul/middlehaul/fronthaul considerations for dynamic capacity and m= obility management. > * Delivering services over ICN in 5G within a framework enabling network = slicing. > * Enhancing 5G backhaul/middlehaul/fronthaul with ICN. > * Mechanisms and protocol enhancements for Hybrid Access networks. > * Introduction of ETSI MEC technology and applications on vertical market= segments. > * New user applications at the edge of the communication network. > * Vertical industry implications to transport, edge computing, and 5G acc= ess networks. > * Insights on pilots, proof-of-concept, and prototypes on access, edge, a= nd transport networks. > > Authors of selected papers from IEEE CSCN 2019 will be invited to submit = an extended and improved version to IEEE Standards Magazine special issue. > > SUBMISSION > > All submissions have to comply with IEEE's guidelines. Initial submission= s for review are limited to seven (7) pages. Camera-ready papers should not= exceed six (6) pages for long papers, and (4) pages for short papers, incl= uding figures without incurring additional page charges (maximum 1 addition= al page with over length page charge). > > The submission URL is: https://eur03.safelinks.protection.outlook.com/?ur= l=3Dhttps%3A%2F%2Fcscn2019.ieee-cscn.org%2Fauthors%2F&data=3D01%7C01%7C= mona.ghassemian%40kcl.ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416= f34c16b83c724071654356%7C0&sdata=3DnQefHYe4AijF4nq6LyrrmQHyFoHtSifxCVxb= 4ZkAhiU%3D&reserved=3D0 [1] > > IMPORTANT DATES > > SUBMISSION DEADLINE: 1 June 2019 > ACCEPTANCE NOTIFICATION: 1 September 2019 > CAMERA-READY: 1 October 2019 > > ORGANISING COMMITTEE > > GENERAL CO-CHAIRS > > Prof. Tarik Taleb (Aalto University, Finland) > Prof. Juan M. Lopez-Soler (University of Granada, Spain) > > TPC CO-CHAIRS > > Prof. Arturo Azcorra (IMDEA Networks Institute, Spain) > Prof. Narcis Cardona (Universitat Polit?cnica de Val?ncia, Spain) > Dr. Imen Grida Benyahia (Orange Labs, France) > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Froll&data=3D01%7C01%7Cmona.ghassemian%40= kcl.ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c72407165= 4356%7C0&sdata=3D%2BCYy79ucBnzKEMpZ0E73tQi9HbWAUU6LRi2GegGZ9vY%3D&r= eserved=3D0 Links: ------ [1] https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fcsc= n2019.ieee-cscn.org%2Fauthors%2F&data=3D01%7C01%7Cmona.ghassemian%40kcl= .ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c72407165435= 6%7C0&sdata=3DnQefHYe4AijF4nq6LyrrmQHyFoHtSifxCVxb4ZkAhiU%3D&reserv= ed=3D0 -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ Roll mailing list Roll@ietf.org https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Froll&data=3D01%7C01%7Cmona.ghassemian%40kc= l.ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c7240716543= 56%7C0&sdata=3D%2BCYy79ucBnzKEMpZ0E73tQi9HbWAUU6LRi2GegGZ9vY%3D&res= erved=3D0 ------------------------------ End of Roll Digest, Vol 134, Issue 9 ************************************ --_000_DB7PR03MB452372F2A5E9E984E21A3BDDA1450DB7PR03MB4523eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Peter,

Apologies for my lack of knowledge. I have b= een a member for a long time and often receive call for papers even recentl= y, hence assumed it is possible to use it for publicity of the event.

If I can know how the approval works, I will= request it for future events that I will be helping as the publicity chair= .

Regards,
Mona

Get Outlook for iOS
 
From: Rol= l <roll-bounces@ietf.org> on behalf of roll-request@ietf.org
Sent: Saturday, March 16, 2019 11:48 am
To: roll@ietf.org
Subject: Roll Digest, Vol 134, Issue 9
 
Send Roll mailing list submissions to
roll@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Froll&amp;data=3D01%7C01%7Cmona.ghassemian%= 40kcl.ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c724071= 654356%7C0&amp;sdata=3D%2BCYy79ucBnzKEMpZ0E73tQi9HbWAUU6LRi2GegGZ9vY%3D= &amp;reserved=3D0
or, via email, send a message with subject or body 'help' to
roll-request@ietf.org

You can reach the person managing the list at
roll-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Roll digest..."


Today's Topics:

1. Re: ***IEEE CSCN 2019*** (Peter van der Stok)


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

Message: 1
Date: Sat, 16 Mar 2019 04:47:51 -0700
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Cc: INES ROBLES <mariainesrobles@googlemail.com>
Subject: Re: [Roll] ***IEEE CSCN 2019***
Message-ID: <f6ebf3c5b1b06030a9d002e6bbad720d@bbhmail.nl>
Content-Type: text/plain; charset=3D"utf-8"

HI Mona,

It is good practice to ask permission to mis-use this mailing list for
CFPs.
We would certainly not have approved the sending of this CFP.

Please try to remember that IETF WG mailing lists are only used for WG
matters !!!!!
Do inform your colleagues.

Thanks,

peter
Ghassemian, Mona schreef op 2019-03-15 16:22:

> [Apologies if you receive multiple copies of this message]
> ******************************************************
> The 5th IEEE Conference on Standards for Communications & Networki= ng (IEEE CSCN'19)
> 28-30 October 2019 // Granada, Spain
> https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fcs= cn2019.ieee-cscn.org%2F&amp;data=3D01%7C01%7Cmona.ghassemian%40kcl.ac.u= k%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c724071654356%7C0= &amp;sdata=3DyasZLF2zJHhB27Prvc%2BOvkb3vefBDGIZNFuFo2KETcs%3D&amp;r= eserved=3D0
> ******************************************************
>
> CALL FOR PAPERS
>
> On behalf of the Organizing Committee, we have great pleasure in invit= ing you to submit your work to the 2019 IEEE Conference on Standards for Co= mmunications & Networking (IEEE CSCN'19). The fifth edition of this hig= hly successful conference will be held in Granada, Spain, the city of the world-famous Alhambra, one of the ten m= ost visited monuments around the world.
> Standards play a key role in the success of the communications industr= y, as enablers of global systems inter-operability and economies of scale. = The finalization of the 3GPP release 15 in June 2018 was a major milestone.= With the first 5G specifications now complete, the industry has achieved critical progress on technology readin= ess, and operators around the world are starting the commercial rollout. Th= is represents the culmination of years of concerted industry and academia e= fforts in scoping out and designing the next generation of mobile systems. Past editions of IEEE CSCN have pla= yed their own part in these efforts.
> In 2019, IEEE CSCN will be divided into 4 tracks designed to cover the= diverse space of technologies - not limited to cellular systems-. New, ori= ginal and previously unpublished papers are invited that address the emergi= ng connectivity solutions and the standardization approaches and strategies that these may take, as well as the relevant bus= iness models and use-cases.
> Additionally, after the recent completion of 3GPP release 15, of speci= al interest are papers that assess the wireless landscape in light of the r= ecently completed release of NR standard. Not only the Non-Standalone versi= on, but also the Standalone version which delivers the potential for 5G deployments independent of LTE.
>
> We are pleased to invite you to submit an original an previously unpub= lished paper on (but not limited to) the topics of the following tracks.
>
> TRACK ON IOT, URLLC AND V2X
>
> * IoT architecture design options and system optimizations.
> * IoT security and privacy of IoT devices and services.
> * System optimization to support ultra-low complexity devices.
> * Radio access optimizations for ultra-low power devices.
> * Standardized semantic data description framework and technologies. <= br> > * IoT communication procedure enhancements.
> * Experience and lessons learnt from IoT large-scale pilots.
> * IoT standards platforms interworking.
> * IoT interoperability methodologies.
> * IoT standards gap analysis.
> * 5G networks, IoT and Tactile Internet.
> * Software Defined Network (SDN) and IoT.
> * Industrial Internet of Things.
> * Factory of things.
> * Edge computing, fog computing and IoT.
> * IPv6-based IoT networks.
> * IoT protocols such as IPv6, 6LoWPAN, RPL, 6TiSCH, WoT.
> * IoT security aspects for massive IoT deployments, e.g., embedded SIM= management.
> * Ultra-Reliable Low-Latency Communications (URLLC).
> * URLLC for mission-critical IoT.
> * V2X standards and architectures.
> * Private LTE/ 5G networks.
>
> TRACK ON 5G RADIO AND WIRELESS COMMUNICATIONS
>
> * Physical layer and MAC layer design for 5G-enabling wireless network= s.
> * Dynamic scheduling, power control, interference management, and QoS = management in 5G.
> * Techniques for latency reduction in 5G.
> * Resource management and control in 5G RAN.
> * Service-oriented user-plane design concepts.
> * Topology, deployment, and optimization of wireless networks.
> * Wireless technology for high speed.
> * mmWave access, backhaul and self-backhauling.
> * Application of SDN, NFV, and cloud computing to 5G (and legacy) RAN = and core network architectures and implementations, such as network slicing= .
> * 3GPP phased work on NR.
> * Green and energy efficient wireless networks.
> * Solutions for battery-conserving, interference-mitigating terminal d= esign.
> * Massive and FD-MIMO communications, hybrid and coordinated beamformi= ng technology.
> * New control signaling for heterogeneous networks.
> * Next-Generation Wi-Fi (IEEE 802.11ax/ay).
> * 5G-LTE interworking and 5G/LTE -- Wi-Fi/Wi-Gig interworking technolo= gy.
> * 5G operation and coexistence in unlicensed and shared spectrum bands= .
> * Next-generation non-RF communications systems.
> * 5G Radio Results from simulation, prototyping, and experiments.
> * Emerging candidate technologies and business use-cases for Beyond 5G= .
>
> TRACK ON SOFTWARIZATION, SLICING, AUTOMATION AND NETWORK MANAGEMENT >
> * Architectures and protocols for network automation and zero-touch ma= nagement.
> * Intelligent-, intent-based and cognitive networking and network mana= gement.
> * Programmable architectures and systems for 5G services and verticals= .
> * Analysis and considerations for common VNFs across fixed and mobile = networks.
> * 5G service-based architecture evolution.
> * Network functions placement in distributed clouds.
> * 5G functional decomposition and deployment.
> * Secure operations in future virtualized networks.
> * Resource management and sharing for network slicing.
> * Scalability and reliability in 5G networks and 5G network slicing. <= br> > * Dedicated and shared network functions in network slices.
> * Cross-slice management for end-to-end QoS.
> * Progress on network slicing standardization (e.g. 3GPP, GSMA, etc.).=
> * Evaluation of network softwarization and fundamental trade-offs. > * Test-bed experience in softwarization and network slicing.
> * SDN architectures and interfaces.
> * SDN programming languages and data models.
> * Progress and future challenges in standardization (e.g. ETSI NFV, IE= TF/IRTF, etc.).
> * Orchestration and management in SDN and NFV.
> * Multi-domain and multi-tenancy considerations in SDN and NFV.
> * Open Source efforts in relation to SDN and NFV (e.g., ONAP, OPNFV, O= penStack, Open Source MANO).
> * QoS/QoE aspects related to SDN and NFV based network services.
>
> TRACK ON ACCESS NETWORK, EDGE COMPUTING AND TRANSPORT FOR 5G
>
> * Multi-Access Edge Computing, Edge-Fog Computing.
> * Routing protocols, segment routing and VPN extensions for 5G slicing= .
> * Multi-tenancy, slicing, and control of multi-domain heterogeneous in= frastructures.
> * SDN and NFV in access, edge, and transport for 5G
> * Transporting 5G mobile services over optical access networks.
> * SDN solutions for mobile networks and fixed IP cross layer transport= and routing.
> * 5G architectures supporting Cloud-RAN and functional split options. =
> * 5G architectures supporting fronthaul/middlehaul/backhaul integratio= n.
> * Network slicing issues with multi-RATs devices.
> * End-to- end resource optimization for 5G mobile services: from radio= head to data center.
> * Integrated backhaul/middlehaul/fronthaul
> * Backhaul/middlehaul/fronthaul considerations for dynamic capacity an= d mobility management.
> * Delivering services over ICN in 5G within a framework enabling netwo= rk slicing.
> * Enhancing 5G backhaul/middlehaul/fronthaul with ICN.
> * Mechanisms and protocol enhancements for Hybrid Access networks. > * Introduction of ETSI MEC technology and applications on vertical mar= ket segments.
> * New user applications at the edge of the communication network.
> * Vertical industry implications to transport, edge computing, and 5G = access networks.
> * Insights on pilots, proof-of-concept, and prototypes on access, edge= , and transport networks.
>
> Authors of selected papers from IEEE CSCN 2019 will be invited to subm= it an extended and improved version to IEEE Standards Magazine special issu= e.
>
> SUBMISSION
>
> All submissions have to comply with IEEE's guidelines. Initial submiss= ions for review are limited to seven (7) pages. Camera-ready papers should = not exceed six (6) pages for long papers, and (4) pages for short papers, i= ncluding figures without incurring additional page charges (maximum 1 additional page with over length page c= harge).
>
> The submission URL is: https://eur03.safelinks.protection.outlook.com/= ?url=3Dhttps%3A%2F%2Fcscn2019.ieee-cscn.org%2Fauthors%2F&amp;data=3D01%= 7C01%7Cmona.ghassemian%40kcl.ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C837= 0cf1416f34c16b83c724071654356%7C0&amp;sdata=3DnQefHYe4AijF4nq6LyrrmQHyF= oHtSifxCVxb4ZkAhiU%3D&amp;reserved=3D0 [1]
>
> IMPORTANT DATES
>
> SUBMISSION DEADLINE: 1 June 2019
> ACCEPTANCE NOTIFICATION: 1 September 2019
> CAMERA-READY: 1 October 2019
>
> ORGANISING COMMITTEE
>
> GENERAL CO-CHAIRS
>
> Prof. Tarik Taleb (Aalto University, Finland)
> Prof. Juan M. Lopez-Soler (University of Granada, Spain)
>
> TPC CO-CHAIRS
>
> Prof. Arturo Azcorra (IMDEA Networks Institute, Spain)
> Prof. Narcis Cardona (Universitat Polit?cnica de Val?ncia, Spain)
> Dr. Imen Grida Benyahia (Orange Labs, France)
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.org%2Fmailman%2Flistinfo%2Froll&amp;data=3D01%7C01%7Cmona.ghasse= mian%40kcl.ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c7= 24071654356%7C0&amp;sdata=3D%2BCYy79ucBnzKEMpZ0E73tQi9HbWAUU6LRi2GegGZ9= vY%3D&amp;reserved=3D0


Links:
------
[1] https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fcsc= n2019.ieee-cscn.org%2Fauthors%2F&amp;data=3D01%7C01%7Cmona.ghassemian%4= 0kcl.ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c7240716= 54356%7C0&amp;sdata=3DnQefHYe4AijF4nq6LyrrmQHyFoHtSifxCVxb4ZkAhiU%3D&am= p;amp;reserved=3D0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Froll%2Fattachments%2F20190316%2Fbf= b83d41%2Fattachment.html&amp;data=3D01%7C01%7Cmona.ghassemian%40kcl.ac.= uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c724071654356%7C= 0&amp;sdata=3Dmd%2FtQyUDhnMWKO1U6Q5ovI5X4VdVshtqrRTz%2Fb6V2bw%3D&am= p;reserved=3D0>

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

Subject: Digest Footer

_______________________________________________
Roll mailing list
Roll@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Froll&amp;data=3D01%7C01%7Cmona.ghassemian%= 40kcl.ac.uk%7C7ff89bfee13f4e89e1f908d6aa054851%7C8370cf1416f34c16b83c724071= 654356%7C0&amp;sdata=3D%2BCYy79ucBnzKEMpZ0E73tQi9HbWAUU6LRi2GegGZ9vY%3D= &amp;reserved=3D0


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

End of Roll Digest, Vol 134, Issue 9
************************************
--_000_DB7PR03MB452372F2A5E9E984E21A3BDDA1450DB7PR03MB4523eurp_-- From nobody Thu Mar 21 07:12: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 A6B34126F72; Thu, 21 Mar 2019 07:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pCBoaIM17930; Thu, 21 Mar 2019 07:12:17 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 6AC6312798E; Thu, 21 Mar 2019 07:12:17 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id e5so4510873otk.12; Thu, 21 Mar 2019 07:12:17 -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=VOJVNZZWpvUbWT8dmGg7IuvWFMNGfWmJVwY0YJ8E/7s=; b=CUSMGkqrKc9WDN+m7uAhdA1Xn8tKU4lwXLhnc3cNnKnhNyc9wmLnIsDaASW1C6KIDN iKYnoPdKdG+EHSnhv7gbGQAmLM0hGWhThgWETQ50SO9n9nOUzM1+1Wj8SReSkLImrSW2 Z2J4QUq4xG5v2c5LgNe8FPrzbBlY+fU8Uf+8UmsblipDIQ/J5vQFbfmCK35AlqI1iI2Y MB89zUsgjgNdpzswxU+N3HDgL8F+1INfbI5/3ExfoEP4oJQc8iI+RAdXalPCC3WwZ/zD Fg1IP8d3E6CsIvkLzX6lHudWWQOluqF/7x5y7zdoRoW4MWeQR7irdCGBSYWvAfaGUX9l 9xyg== 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=VOJVNZZWpvUbWT8dmGg7IuvWFMNGfWmJVwY0YJ8E/7s=; b=OXyP6fgiH/KulfFWVxhctV31xQ05ThTg9EJh+AHhUylUrDIqMzp87CZoC9ioiIYAOx RLrxljdE0gKBeKgspRXKvSQAhRS6thMiKLimqvfCPJhzumR1F1MoscRNlS9LI7m/NDJk Ednhs5NzNWAD8oXIGwxVy7AfPWwvJbsbEVvwT/Sr9Y/H/2hbQxs2OadRCzeAcaBhX01p J1R5XevCnK3Ccm/H+WbeZOg8/IFwGJ1FSWT+6MsWgcA/SqbYFnVUEEJbBp93fT0N4ohW FhC2LLNI1q0iUFZQb2ouYtRs4EbW4wTxiveZHERA0B721R6UQ2IiSl0SmsbJt87/hut6 SCKA== X-Gm-Message-State: APjAAAWOcS9aQ8Ihf/mJufl2grU9BP/AIlvZitDzbo7yXZm8PF0xqBv2 CELrELlEOrPm7cZvS/yvZMC0aQVXkFSHrfHQA3U= X-Google-Smtp-Source: APXvYqyjFt2Dxq44vNuRdyxzmRJMVD/9j43QBS3ZtwCkfbC36PJeU3ioevq1IUoCcWLg7tKr1OW+GWOUN+sBjdhXQDM= X-Received: by 2002:a05:6830:13cd:: with SMTP id e13mr2763162otq.139.1553177536694; Thu, 21 Mar 2019 07:12:16 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Mar 2019 10:12:15 -0400 From: Alvaro Retana In-Reply-To: References: <153427390944.27108.4373520532151309638.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Thu, 21 Mar 2019 10:12:14 -0400 Message-ID: To: Ines Robles Cc: roll , roll-chairs , draft-ietf-roll-useofrplinfo@ietf.org, Peter van der Stok Content-Type: multipart/alternative; boundary="00000000000059141305849b5372" Archived-At: Subject: Re: [Roll] Datatracker State Update Notice: 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, 21 Mar 2019 14:12:19 -0000 --00000000000059141305849b5372 Content-Type: text/plain; charset="UTF-8" On March 15, 2019 at 4:48:35 PM, Ines Robles (mariainesrobles@googlemail.com) wrote: Hi! Thanks again for your review. We believe that the new version address all your comments. It does! I have requested the start of the IETF LC. Thanks! Alvaro. --00000000000059141305849b5372 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On March 15, 2019 at 4:48:35 PM, Ines Robles (mariainesrobles@googlemail.= com) wrote:

Hi!=

=
=C2=A0Thanks again for your review. We believe that the = new version address all your comments.

It doe= s!=C2=A0 I have requested the start of the IETF LC.

Thanks!

Alvaro. --00000000000059141305849b5372-- From nobody Thu Mar 21 07:18:48 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 30008131064; Thu, 21 Mar 2019 07:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOVm29KuNUV2; Thu, 21 Mar 2019 07:18:35 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 484001310D7; Thu, 21 Mar 2019 07:18:35 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id a16so5145463edn.1; Thu, 21 Mar 2019 07:18:35 -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=ikRhI5w4VgI89OtV88O/WPscZSCFcm6wWPzXsztHvKU=; b=bfXRQHzB5siM8cjXwu++bTK8gB8Oa3WLtph58Pqip5glboTswr2YnOMkpt38pybbbq +b8QoxPxtZD71vMHzUY24QPcNKtsigkyusS5acmbkMwCqpQlG5H1bRmIlNWoOc3koITA u19ZqkfT4X4LgvpiXI96w4kKkyJzEoOVRUMlrkhEO07gbFaq7bRnrMULDuxHpRpwwEpV ueC9+7wDdcOT77nY6rCa0Ti4p4q9iyx8o/tv0FAEAPW7dwft2plh4l7tCRb/yQE7ODDR h3svmifeyWWVhLIHqQl5EMW9+OJcDhSLKuhi08SKDMZuJ6aOxv8eaSp97J6OGBoAyDRu +y4g== 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=ikRhI5w4VgI89OtV88O/WPscZSCFcm6wWPzXsztHvKU=; b=bAZldGrEWj1jrGkjUP9XhwKb6zrfdObb5GD87r6Irg2AI9NtB/fI8FF55scV0S2NQv aQHu35BuwpaMRTtXr7gMCTTuMkBTCh+6NeRck8Kk2kA5SuZ33JgMktlUwSkNA2v0yffy ByOc9zo9xAt/By0q1wEqxH9/toCttq553jcHOUbVcD9tzv9vHFLHtaXsVJnYbgMl09cP Ru6Fbv4c8joRieAjq0suX6MErnRc1CN8vQowoMP0ngNYR2SKkvenbpJBgUYSP72Fla5r bjtTDElUQiQOTnqmvGDiu/jDLVxDpYonlbrc2hICN3Iv/XDAlEdZ9Ab+etDHYhyylVNt lIxA== X-Gm-Message-State: APjAAAU2KaotXTfUYu0nUmCExTiHDv+zkgONsLwg3E2myJi8T1+Qrr29 GQa6DokPO5iJPCcfCCMa5b44MykBPWcZwBsTXN4= X-Google-Smtp-Source: APXvYqxLvyWD5/wt4sczcoYhNFIDEfPJ3VhDxizAAYAy7R4f6iUEu3RumKTxSpi5ImVlVR4WO/gj4Jo7EY6xZTyDluE= X-Received: by 2002:a17:906:2306:: with SMTP id l6mr2427580eja.27.1553177913694; Thu, 21 Mar 2019 07:18:33 -0700 (PDT) MIME-Version: 1.0 References: <153427390944.27108.4373520532151309638.idtracker@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Thu, 21 Mar 2019 16:18:21 +0200 Message-ID: To: Alvaro Retana Cc: roll , roll-chairs , draft-ietf-roll-useofrplinfo@ietf.org, Peter van der Stok Content-Type: multipart/alternative; boundary="000000000000d1a2c605849b69c9" Archived-At: Subject: Re: [Roll] Datatracker State Update Notice: 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, 21 Mar 2019 14:18:46 -0000 --000000000000d1a2c605849b69c9 Content-Type: text/plain; charset="UTF-8" Thank you very much Alvaro!! We are happy to know that the document addresses all the comments. :) On Thu, Mar 21, 2019 at 4:12 PM Alvaro Retana wrote: > On March 15, 2019 at 4:48:35 PM, Ines Robles ( > mariainesrobles@googlemail.com) wrote: > > Hi! > > Thanks again for your review. We believe that the new version address all > your comments. > > > It does! I have requested the start of the IETF LC. > > Thanks! > > Alvaro. > --000000000000d1a2c605849b69c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much Alvaro!!

We are hap= py to know that the document addresses all the comments. :)

=
On Thu, Ma= r 21, 2019 at 4:12 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:
On March 15, 2019 at = 4:48:35 PM, Ines Robles (mariainesrobles@googlemail.com) wrote:

Hi!

=C2=A0Thanks again for your review. We believe that the new versio= n address all your comments.

It does!=C2=A0 I have requested the= start of the IETF LC.

Thanks!

Alv= aro.
--000000000000d1a2c605849b69c9-- From nobody Thu Mar 21 08:14:14 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 48CDC1312B7; Thu, 21 Mar 2019 08:14:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: consultancy@vanderstok.org, roll-chairs@ietf.org, roll@ietf.org, Peter Van der Stok , aretana.ietf@gmail.com, draft-ietf-roll-useofrplinfo@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155318124522.9933.6581390888537389950.idtracker@ietfa.amsl.com> Date: Thu, 21 Mar 2019 08:14:05 -0700 Archived-At: Subject: [Roll] Last Call: (Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane) to Proposed Standard 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: Thu, 21 Mar 2019 15:14:13 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Using RPL Option Type, Routing Header for Source Routes and IPv6-in- IPv6 encapsulation in the RPL Data Plane' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC 6553 adding a change to the RPL Option Type. Additionally, this document updates RFC 6550 to indicate about this change and updates RFC8138 as well to consider the new Option Type when RPL Option is decompressed. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 22 03:46:58 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 6F61A130EC0 for ; Fri, 22 Mar 2019 03:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 gYw1bw0Jedct for ; Fri, 22 Mar 2019 03:46:43 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 2ACAB130F3C for ; Fri, 22 Mar 2019 03:46:43 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id m16so1253763edd.12 for ; Fri, 22 Mar 2019 03:46:43 -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=45QoTklcqM33H88HqcMkwJ49HHPUCY+BYVW9odIRWns=; b=ToV4Ed3V6JxHCGrqM/qzvjW9ZP+rh0o2dPcXd39ZeftN+FwKOvTRV3gWKlfb5ndWMo xpN9o9HEsSFLmqy4AXYtysdMqbYmefIq9UcGmeX+i6f5ggDIG4AWtMwYj68/XgL4U0S7 sgmiGzg8A8Z5EJkpt3j+wbDAgKxpFYnCMbeRYdFwVOODRonlx2pmGhlfecVv+mgX8oeP JCK5eJs/Ec5wnz39AwjvsGt2rDYDG7z61nlklJsLqRwVTD9sfTzXjMOa5soBzw01F4Lw B/YGIzOBPkdY2xUj37xEayBFwpW/QuAGZeK+kAws2N8C89+hj/bSbaPA1+HNpi/E51v6 rbyQ== 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=45QoTklcqM33H88HqcMkwJ49HHPUCY+BYVW9odIRWns=; b=hbZ3jHCfBekkFlJvdVhvMZB8pliqnL6YNaKO/ItNu/EEyz8YXLMz2rXszZZfe14qu4 uLshbu5Uzh2P00oWK9r+h2C1QgEWJcygBHVhjHLZPDRb2+sySsFUIG3DAXQWnQXP0XHc CWgtds+fzJv9MSBK6vtA/2YfC84f8s5QN+lO9RevOR9iKEK8MkdVHH0lA59/7gdtjj9e 8qwUPRIHl1xQCXGpz+tDwwwkNDUYmts7xyF3Jw3dDNmL6jxcksK3SRVfaHV2Tl93Ojxt TZf2rxB+d7TJQviyQs0FYd/holeSKvotvm1t5gScfIDPVnCmUGfb+nqJ7CYkGfIyEYFH xP5Q== X-Gm-Message-State: APjAAAXKxM6buo89Xtc2k39bOEJY4NkvNW3a4z9SKANOgV9Z3/TYaoy5 DZHPzG8KL+VG0unD6ZEUUeIiac/Of0fy3Ic3c5Lk/A== X-Google-Smtp-Source: APXvYqyP/pWxiVtZirzGbVJEsXlPG8KguGx4nWtC16N3wDbwkNnFUyV/8Di1lLwo65FU0IiPbglrAwdXgEnCZvLF+yI= X-Received: by 2002:a50:8ed1:: with SMTP id x17mr5777063edx.168.1553251601476; Fri, 22 Mar 2019 03:46:41 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Fri, 22 Mar 2019 12:46:30 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000f3eeec0584ac91ed" Archived-At: Subject: [Roll] Request for Slides -- IETF 104 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, 22 Mar 2019 10:46:57 -0000 --000000000000f3eeec0584ac91ed Content-Type: text/plain; charset="UTF-8" Dear Presenters, This is a kindly reminder :-), please send to us the slides in PDF format. Thank you to the ones that have already sent them!! :-) Have a nice flight/Time in Prague. Ines and Peter --000000000000f3eeec0584ac91ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Presenters,

This is a kindly r= eminder :-), please send to us the slides in PDF format.=C2=A0
Thank you to the ones that have already sent them!! :-)
<= div>
Have a nice flight/Time in Prague.

<= div>Ines and Peter


--000000000000f3eeec0584ac91ed-- From nobody Sat Mar 23 10:03:05 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 A9173130F12 for ; Sat, 23 Mar 2019 10:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 XfQZmsgBSNFs for ; Sat, 23 Mar 2019 10:02:57 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 208A9130F01 for ; Sat, 23 Mar 2019 10:02:57 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id h22so4198412edw.7 for ; Sat, 23 Mar 2019 10:02:57 -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=ALA8/LB2IfYn4I04U7BxPX2qRTLYBSV4C0qimoCubO4=; b=dxtIJ06Ohx08NpyWFzq1SSf6Sqb0xMaukSrx7xW4sgakWbaHzBiZCbluxC2PDftpMy suUUbULRzaiZIPM2/CvYz6OtqUmRIxblvpul4rpyQBauJirz2LL1Z/U6sQ73UffLjyRY aRUAaku6EmEKPsX1bbMPb16lM3TVsvymyF6EqKPZf0JI1FlwhBAWyyyW38J/L/hxCpSc u5tQSXlqwismVsH4lnHBsi6ievKArbCkele+j8U66tdhXzk7B9KPg0xHpHjZkgr7hzdQ dTsd2NbozdPIZca/DNSSdW38MxS0NEx59dtzcYXADBncRogtXNVCQv2+kPfe7cs6q3zB IJLA== 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=ALA8/LB2IfYn4I04U7BxPX2qRTLYBSV4C0qimoCubO4=; b=W/GERhWNYdEntpNDrkQp2JhApmZ/90fPLeXi8is5nwZ4i4G8kqMW76N8OBAJbrNSb7 iulrLOjroVG32uOkqd9AcyyqthBNyYckxWOkGx120QOKFE4sl6YYp7kyRml1oFmUGx3k +Y47H0X0lG0idAxrRP++PceJptnYQ3ySfjd0lPdscS/wTtxmEncE8JMJ6EH+2HWkcRg2 xP9FZfzhUST0TJ8BmC3cTdEKYnFs3QmiFJVdsZjnjrZt/eNMW6WGrh47kdu5ODJ114dI ws0CtIqYkRsSyGWai0K3xTr4LbgAq5ihtVmmpC6nB81cQw3unfE8VjlC3qjouqxTX0l0 bT8A== X-Gm-Message-State: APjAAAXyWrRucf6kiSsAcMTDVm8I0gU1RsM9B68FXTGmb0PF6RNHVgE1 sdLduY7OoHcm6sqX9zh5qOVoY4rIQpmtU1Kd6h8rAyfE X-Google-Smtp-Source: APXvYqw8tGpvth+EBaSmLq0ft/p9+fdiopQwJTneCF4jvlG/cUJqO6h/tvJtO9ja7fMIikbj/WedautqcGfc3j/KbWc= X-Received: by 2002:a50:aed5:: with SMTP id f21mr10420746edd.114.1553360575161; Sat, 23 Mar 2019 10:02:55 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Sat, 23 Mar 2019 19:02:44 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="0000000000004a6c3a0584c5f1fd" Archived-At: Subject: [Roll] Slides - IETF 104 - 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, 23 Mar 2019 17:03:04 -0000 --0000000000004a6c3a0584c5f1fd Content-Type: text/plain; charset="UTF-8" Dear all, Please find the link to the slides for the Monday meeting https://datatracker.ietf.org/meeting/104/materials/slides-104-roll-roll-ietf104-slides-00 Comments welcome, Thanks! Ines and Peter. --0000000000004a6c3a0584c5f1fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find = the link to the slides for the Monday meeting


Comm= ents welcome,

Thanks!=C2=A0

Ines and Peter.
--0000000000004a6c3a0584c5f1fd-- From nobody Sun Mar 24 06:18:08 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 941D41279A9 for ; Sun, 24 Mar 2019 06:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW1jdjsO9XUm for ; Sun, 24 Mar 2019 06:18:05 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 1F10F12799B for ; Sun, 24 Mar 2019 06:18:05 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id d1so5265887edd.13 for ; Sun, 24 Mar 2019 06:18:05 -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=eb1CNQMaCUpxXmoiBmILXJxiJXQsHk0r8oAQZc2o7Co=; b=Bv8DteOARpicwk7fdUpG+kgLugnZF339SZ6F34zcBhCo2NE+uE+SVEq/eSWCduwo3m jrTpkgM1DT4DKV38O4x8MxzAgZq+ygI4DRFMuhaijbzN/rLyYXZJlOuLZsOXAg7yJgj9 sOeLhGuaBg+Nxr1VNzGZs4Ev1xrEYwOu2DtepBxKOM8iPEKPmiqtm3tza+3RzyCQC2pJ 4orridem3jdz18sqye+qTU6Tqh0effHs/Ra7Rwr8NOD7bOcY5Y0pjMXG4fh44Ps0b1vI cUxqontxeO7/7sPRc9UZIT/yk8vK2tDvqd4b7QAUa3ZaWIeukCFUAxayD7mtAfKcLE8p 6rBA== 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=eb1CNQMaCUpxXmoiBmILXJxiJXQsHk0r8oAQZc2o7Co=; b=A5klXSEpnWG00udh3cdCxh6kzp8ZEH6XlNZsv4SQs9dJIc/Gn75TvJf995LXyey6Ma GtGvevGnybnHaytbjGQNfcx19DO1IqLe+iV2WRGMrE7JB4oJRbWJyKCyNwCcEsNh9btM o6aG8DL9CgILfQ86ODFsK7fIZxBB9eu/7ynIV3ZF6hnfPfL8unObkfCx0jVQtzOlHy+0 97gI7md3F8lYflaH6Mh2ZkEjZtbMR5IzeKHPqOuwSK+nEuYitvYXj+t9Vw1Cgb3+Yqd5 jCctcA6+jgf1o4CaMLViA/KBL3nNbPSe7146jGuXZoKPOnZDljODjGG5v52hQ2Gd3G+f XWZg== X-Gm-Message-State: APjAAAXNS7K6t0HDouXxYLjYibvj1sa2Pn6vDo4k2PBDK/NtqZBuDY27 VukUEjyRK0OFoGo2T0E2Rr0P0VdsUeJXgVAwmYIKWRlO13w= X-Google-Smtp-Source: APXvYqxf74mPqRwk5k9pExiYZcd6qzDnfugYP58i+FpzYuMN47QDExRlWbg699d2Z3i4cjuDhEa+shd6/CMMVdufWfc= X-Received: by 2002:a50:b152:: with SMTP id l18mr13389718edd.289.1553433483176; Sun, 24 Mar 2019 06:18:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Sun, 24 Mar 2019 15:17:52 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000f26efa0584d6ea3b" Archived-At: Subject: Re: [Roll] Slides - IETF 104 - 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, 24 Mar 2019 13:18:08 -0000 --000000000000f26efa0584d6ea3b Content-Type: text/plain; charset="UTF-8" Dear all, Please find below the link to an updated set of slides. https://datatracker.ietf.org/meeting/104/materials/slides-104-roll-roll-ietf104-slides-01 Thanks, Ines and Peter On Sat, Mar 23, 2019 at 7:02 PM Ines Robles wrote: > Dear all, > > Please find the link to the slides for the Monday meeting > > > https://datatracker.ietf.org/meeting/104/materials/slides-104-roll-roll-ietf104-slides-00 > > Comments welcome, > > Thanks! > > Ines and Peter. > --000000000000f26efa0584d6ea3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find = below the link to an updated set of=C2=A0slides.

<= a href=3D"https://datatracker.ietf.org/meeting/104/materials/slides-104-rol= l-roll-ietf104-slides-01">https://datatracker.ietf.org/meeting/104/material= s/slides-104-roll-roll-ietf104-slides-01

T= hanks,

Ines and Peter

On Sat, Mar 23, 2= 019 at 7:02 PM Ines Robles <mariainesrobles@googlemail.com> wrote:
Dear= all,

Please find the link to the slides for the Monday = meeting


Comments welcome,
<= div>
Thanks!=C2=A0

Ines and Peter.
--000000000000f26efa0584d6ea3b-- From nobody Mon Mar 25 07:25: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 5FAAE1203EE for ; Mon, 25 Mar 2019 07:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zvgh55HsY4-3 for ; Mon, 25 Mar 2019 07:24:59 -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 5FF591203D0 for ; Mon, 25 Mar 2019 07:24:59 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id a25so7694625edc.8 for ; Mon, 25 Mar 2019 07:24:59 -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=XEjsxy4xyCzoLqHqH8NR2GPCRumM97KfJxXIbk3buso=; b=sgYruGQa8zZRMR0p/UBkZasst5RUyb0nQebmujxwk0/WGb1uvB4F3L0pgh02iChvh9 8PiXfd/oF83xvJizFur1xcaLC7n4X53bsmR0gL2IX8v1ALZdNJ5NiCm5GRDny+/i3okb CD7RWKhWCF0LuVNKpGqXFNP+6jA4c+vt9cvu2WPMujR5YcIyGnOdJxF4klckbGwCN/dY /ZRDZgkzjWTwLMSA7VkNzskLcfPEPh8DukrlOffT5sQ/vETMveEIb/zKDAvtAPNTu2Wt LW/PFf0HqbgkhZDST5l9eI1ouZ7MDN1/Gk7cGlrWiCNEIL3HTp2iID87nfWs64WJ1HMz VCLg== 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=XEjsxy4xyCzoLqHqH8NR2GPCRumM97KfJxXIbk3buso=; b=P7348mtOzYYkJOATpxkwI6ITRzj9SYU5AGIbCELn1Ddpyu+zdFleR9TjTKEc+TRWoc ULWI91CUDVrh7QfQwonNCYvjIR2F3LnBwoQ4Jjv6LpAKjd4RlAGDDJvVQrkenabM8u62 yFm6WEpBJgHuqsKpZxtiI5PyAJDrVM6V6m/Td8f+W6cma/t/Qsn/zb1ZGkUCk1fua6l7 5I6ls2pAHMQ/r/FwBsdx/pDCn5srbDl8GvRQqaiO7YQeuv3p+4VtF1ultYk2S5Ye7YJq /HHDwyyiVDkfLjcu7cBxH6KYVLZmlb9EOLJkOB4Xph9SMm7shsnC/I55QWtjx18s5Yma ssJw== X-Gm-Message-State: APjAAAUS3F57qeLpk1s4dBMNc8YciDHjq62K7gThyA/KEzDxgqwESFtY OkL+ZP4z1gXIF5/dwFUupAZugmpIdC7iiGFlsvwLE2CS X-Google-Smtp-Source: APXvYqwDWrQ1bb/DRuyqY3CYJ1AqUj0+oQOMTBoQHVdxhSDmhqqHqKtJ3bTQkdcIU9PnLtY371CsYDA0SS70TkRaQRY= X-Received: by 2002:a50:8ed1:: with SMTP id x17mr16191893edx.168.1553523897508; Mon, 25 Mar 2019 07:24:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Mon, 25 Mar 2019 16:24:46 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="0000000000000fa8dc0584ebf8c2" Archived-At: Subject: Re: [Roll] Slides - IETF 104 - 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, 25 Mar 2019 14:25:01 -0000 --0000000000000fa8dc0584ebf8c2 Content-Type: text/plain; charset="UTF-8" Dear all, Please find below the link to a new version of the slides https://datatracker.ietf.org/meeting/104/materials/slides-104-roll-roll-ietf104-slides-02 Cheers, Ines and Peter On Sun, Mar 24, 2019 at 3:17 PM Ines Robles wrote: > Dear all, > > Please find below the link to an updated set of slides. > > > https://datatracker.ietf.org/meeting/104/materials/slides-104-roll-roll-ietf104-slides-01 > > Thanks, > > Ines and Peter > > On Sat, Mar 23, 2019 at 7:02 PM Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear all, >> >> Please find the link to the slides for the Monday meeting >> >> >> https://datatracker.ietf.org/meeting/104/materials/slides-104-roll-roll-ietf104-slides-00 >> >> Comments welcome, >> >> Thanks! >> >> Ines and Peter. >> > --0000000000000fa8dc0584ebf8c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please f= ind below the link to a new version of the slides=C2=A0

=
On Sun, Ma= r 24, 2019 at 3:17 PM Ines Robles <mariainesrobles@googlemail.com> wrote:
Dear all,

Please find below the link to an updated se= t of=C2=A0slides.


Thanks,
<= div>
Ines and Peter

On Sat, Mar 23, 2019 at 7:02 P= M Ines Robles <mariainesrobles@googlemail.com> wrote:
Dear all,

Please find the link to the slides for the Mo= nday meeting


Comments welcome,

Thanks!=C2=A0

Ines and Pet= er.
--0000000000000fa8dc0584ebf8c2-- From nobody Mon Mar 25 07:50:20 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 67E751203D0; Mon, 25 Mar 2019 07:50:18 -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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <155352541833.29020.511986097985081507@ietfa.amsl.com> Date: Mon, 25 Mar 2019 07:50:18 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-rpl-observations-01.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: Mon, 25 Mar 2019 14:50:19 -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 : RPL Observations Authors : Rahul Arvind Jadhav Rabi Narayan Sahoo Yuefeng Wu Dacheng Zhang Filename : draft-ietf-roll-rpl-observations-01.txt Pages : 16 Date : 2019-03-25 Abstract: This document describes RPL protocol design issues, various observations and possible consequences of the design and implementation choices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-observations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-01 https://datatracker.ietf.org/doc/html/draft-ietf-roll-rpl-observations-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-rpl-observations-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 26 00:05:47 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 DC0FD12028B for ; Tue, 26 Mar 2019 00:05:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cDetOVrectCw for ; Tue, 26 Mar 2019 00:05:43 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33CCD120284 for ; Tue, 26 Mar 2019 00:05:43 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id A5DFE45CD for ; Tue, 26 Mar 2019 07:05:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:subject:reply-to :message-id; s=key; bh=BB5HKHHN79SIR51T83XURjucJhcXPw1Uow+N6JBgl 9M=; b=oVk9ETt0mDFqRmlafgqkyFNvuvbZ84l1lMDWXfGU65fy8buUj/R0p2yh0 V2FkOHWNuQO3lC3BP/0MtwkWng0cCbrzGQWDKOONcXgY7MS/JvSU+ZQt9MqdTBjg jbULTIkgivrMDFIASiX5Y4tAyHvzUjb9wg+Etxr/wGEgH3cKEA= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :, RULES_HIT:41:72:152:355:379:582:800:962:967:973:983:988:989:1152:1189:1208:1221:1260:1263:1313:1314:1345:1381:1431:1436:1437:1516:1517:1518:1534:1541:1575:1588:1589:1592:1594:1711:1714:1730:1776:1792:2198:2199:2525:2553:2561:2564:2682:2685:2829:2859:2894:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3350:3586:3865:3866:3867:3868:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4362:4425:4659:5007:6261:6298:6659:8603:8660:9010:9015:9025:9177:9388:9390:10004:10215:10400:10848:11232:11658:11914:12043:12109:12114:12555:12679:12895:12986:13071:13095:13139:13148:13199:13229:13230:13439:13846:14096:14180:14181:14721:21060:21080:21212:21433:21451:21625:21691:30048:30054:30060:30090, 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 X-HE-Tag: jail85_88ff8a139940c X-Filterd-Recvd-Size: 3102 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf04.hostedemail.com (Postfix) with ESMTPA for ; Tue, 26 Mar 2019 07:05:41 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8a580534748e249f5080b5a17bf79021" Date: Tue, 26 Mar 2019 00:05:40 -0700 From: Peter van der Stok To: Roll Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [31.133.149.21] Archived-At: Subject: [Roll] WG last call draft-ietf-roll-aodv-rpl-06 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, 26 Mar 2019 07:05:46 -0000 --=_8a580534748e249f5080b5a17bf79021 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII HI Roll As discussed during the meeting the draft-ietf-roll-aodv-rpl-06 is considered to be done. This draft has known several revisions, the latest being the security discussion. This message annouces the start of the WG last Call ending april 8, 2019. Please do review the security section and the motivation text. Let it be known on the mailing List that you agree that this draft is ready for IESG review; and communicate any improvements that you consider worthwhile. Thanks, Ines and Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_8a580534748e249f5080b5a17bf79021 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Roll

As discussed during the meeting the draft-ietf-roll-aodv= -rpl-06 is considered to be done.
This draft has known several revisio= ns, the latest being the security discussion.

This message annou= ces the start of the WG last Call ending april 8, 2019.
Please do revi= ew the security section and the motivation text.

Let it be known= on the mailing List that you agree that this draft is ready for IESG revie= w; and
communicate any improvements that you consider worthwhile.

Thanks,

Ines and Peter
--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl
www: www.vanders= tok.org
tel NL: +31(0)492474673     F: +33(0)= 966015248
--=_8a580534748e249f5080b5a17bf79021-- From nobody Tue Mar 26 01:58: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 7CCFA1202A3 for ; Tue, 26 Mar 2019 01:58:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FOUnQMEEse7N for ; Tue, 26 Mar 2019 01:58:15 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8F212029A for ; Tue, 26 Mar 2019 01:58:14 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 725D3180A8140 for ; Tue, 26 Mar 2019 08:58:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:subject:reply-to :message-id; s=key; bh=nK3WGJjzxgJfenf2fwyHvHR2qxqNNQoeA7bOXuiJb jA=; b=JtZ6xWZXf4uC8/mJQlNgTHqwzIrYZBxyDVNgKjasFfxrKhE71TvzjfRSS fw5V21AYMOZ/KAHxe3ORSLTP/hU56roCvppore4MncvJTmNu72dRoCvmWZcAshJO QNwuJYgErxSxmoc0ske9mnKzSI+iril0M9CBe0+EMEhkeHs4lE= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :, RULES_HIT:41:72:152:327:355:379:582:800:871:962:967:973:983:988:989:1000:1152:1189:1208:1212:1260:1263:1313:1314:1345:1381:1431:1436:1437:1516:1517:1518:1541:1568:1575:1588:1589:1592:1594:1711:1714:1730:1764:1776:1792:2068:2069:2525:2527:2557:2561:2566:2682:2685:2829:2859:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3586:3622:3769:3865:3866:3867:3868:3871:3873:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4659:5007:6261:6298:6506:6659:6747:6748:7281:7398:7464:8507:8603:9015:9025:9177:9388:10004:10215:10394:10400:10848:11232:11604:11658:11914:12043:12555:12679:12740:12895:12986:13071:13139:13161:13166:13199:13229:13439:13846:14096:14180:14181:14721:21060:21080:21324:21433:21451:21625:21691:21703:21789:30048:30054:30083, 0, RBL:error, 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:27, LUA_SUMMARY:none X-HE-Tag: gun05_64b175721465c X-Filterd-Recvd-Size: 21746 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA for ; Tue, 26 Mar 2019 08:58:11 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_4e58e05f24077a79a43085ead886c66b" Date: Tue, 26 Mar 2019 01:58:11 -0700 From: Peter van der Stok To: Roll Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: <993a01cc2923fd5b0fbfbb2c8fb835a9@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [31.133.149.21] Archived-At: Subject: [Roll] Roll meeting in Prague 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, 26 Mar 2019 08:58:18 -0000 --=_4e58e05f24077a79a43085ead886c66b Content-Type: multipart/alternative; boundary="=_868b2c2dc78fce393a7ad739ca60a19a" --=_868b2c2dc78fce393a7ad739ca60a19a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII HI ROLL, The roll meeting is behind us and we want to thank Dominique and Rahul for being the minute taker and the Jabber Schriber The link for the minutes is: https://datatracker.ietf.org/meeting/104/materials/minutes-104-roll-00 Please, send comments before the deadline 2019-04-19 Attached you wil find a high level summary of the meeting. Hope this is useful. Greetings and thanks for your collaboration, Ines and Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl www: www.vanderstok.org [1] tel NL: +31(0)492474673 F: +33(0)966015248 Links: ------ [1] http://www.vanderstok.org --=_868b2c2dc78fce393a7ad739ca60a19a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
HI ROLL,

The roll meeting is behind us and we want to thank= Dominique and Rahul for being the minute taker and the Jabber Schriber
The link for the minutes is:
 
 
Please, send comments before the deadline 2019-04-19
A= ttached you wil find a high level summary of the meeting. Hope this is usef= ul.

Greetings and thanks for your collaboration,

Ines= and Peter
--
= Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org, stokcons@bbhmail.nl
www: www.vanders= tok.org
tel NL: +31(0)492474673     F: +33(0)= 966015248
--=_868b2c2dc78fce393a7ad739ca60a19a-- --=_4e58e05f24077a79a43085ead886c66b Content-Transfer-Encoding: base64 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="ROLL meeting discussion.docx" Content-Disposition: attachment; filename="ROLL meeting discussion.docx"; size=13264 UEsDBBQABgAIAAAAIQDfpNJsWgEAACAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lMtuwjAQRfeV+g+Rt1Vi6KKqKgKLPpYtUukHGHsCVv2Sx7z+vhMCUVUBkQpsIiUz994zVsaD0dqa bAkRtXcl6xc9loGTXmk3K9nX5C1/ZBkm4ZQw3kHJNoBsNLy9GUw2ATAjtcOSzVMKT5yjnIMVWPgA jiqVj1Ykeo0zHoT8FjPg973eA5feJXApT7UHGw5eoBILk7LXNX1uSCIYZNlz01hnlUyEYLQUiep8 6dSflHyXUJBy24NzHfCOGhg/mFBXjgfsdB90NFEryMYipndhqYuvfFRcebmwpCxO2xzg9FWlJbT6 2i1ELwGRztyaoq1Yod2e/ygHpo0BvDxF49sdDymR4BoAO+dOhBVMP69G8cu8E6Si3ImYGrg8Rmvd CZFoA6F59s/m2NqciqTOcfQBaaPjP8ber2ytzmngADHp039dm0jWZ88H9W2gQB3I5tv7bfgDAAD/ /wMAUEsDBBQABgAIAAAAIQAekRq37wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLBasMw DEDvg/2D0b1R2sEYo04vY9DbGNkHCFtJTBPb2GrX/v082NgCXelhR8vS05PQenOcRnXglF3wGpZV DYq9Cdb5XsNb+7x4AJWFvKUxeNZw4gyb5vZm/cojSSnKg4tZFYrPGgaR+IiYzcAT5SpE9uWnC2ki Kc/UYySzo55xVdf3mH4zoJkx1dZqSFt7B6o9Rb6GHbrOGX4KZj+xlzMtkI/C3rJdxFTqk7gyjWop 9SwabDAvJZyRYqwKGvC80ep6o7+nxYmFLAmhCYkv+3xmXBJa/ueK5hk/Nu8hWbRf4W8bnF1B8wEA AP//AwBQSwMEFAAGAAgAAAAhAFTcDK5jBwAAMykAABEAAAB3b3JkL2RvY3VtZW50LnhtbOxabVPq OBT+vjP7HzJ82p2hFBDfmCs7Cuo6g8qgd+/HndCGNte26SYp1f31e07SAopyAVHv3L0dpaRJnpz3 nJPy6Y/7OCITJhUXyVGlUatXCEs84fMkOKp8vj1zDipEaZr4NBIJO6o8MFX5o/PrL5/yti+8LGaJ JgCRqHaeekeVUOu07brKC1lMVS3mnhRKjHXNE7ErxmPuMTcX0neb9UbdfEul8JhSsF6XJhOqKgWc d78ami9pDpMRsOV6IZWa3c8wGmuD7LqH7sEiUHMDIOCw2ViE2lkbas9FqhaAWhsBAVULSLubIT3D 3N5mSM1FpP3NkHYWkQ42Q1owp3jRwEXKEugcCxlTDU0ZuDGVd1nqAHBKNR/xiOsHwKzvlTCUJ3cb UASzpgjxjr82wr4bC59FO36JIo4qmUzaxXxnOh9Jb9v5xa2cIVfh307pFcHBcO5KFoEsRKJCnk49 PN4UDTrDEmSyjIlJHJXj8rSxoru8FJ56VpQzwFXIL+QfR5by5YiN+goaQYjpjFVIeLxmSUkMVjhb eCPRzAm3sWIAKQGaCwB7Hl/RpEsMK03gB2bO4Si2HsxuCaMe4pmr52nwOms5lyJLZ2j8dWgXM9/P cRdeA6uwunlPUK8j5iakKYSE2GtfBImQdBQBRWBDBMyAGA3gJ2iFoNNVOpAqjIT/gPcUelrtlEp6 Adqu26tRMU8h0Gp8ul9c8LQNaYk/xIHdbrPRak4f9diYZpHGnmZ99+SsZ1ZJBxJvXz0YNqHRUcWD kMFkxcWn0naOoOEWLXc6xX4sjsjbJrtpq5R6wGQqmWJywiqd4XW/T2LGNMiD+JnEG87Sdq6hRgox PpUSiNEPKcxWKYuiGw1bSkHRy4t2/JpfWwnvNPG/ifY8C6S56+6gfg/JxentGWnUW4QnZCBpkLFH a6OcXtQeKmVN7Q3knOK2o9K87YlIoGzMKEsaYmswcNbFvqMK0tjAqWsZQKfHPI7pMYHpknr6iV5w 0UW2tkLfi7pznhrb2xLRuSws/U8ehBH8a7W6gey8yr2LnjlbWOLIS+lobSvMLPVbSWG75kyPHSmi yKHCnzgyjZz63lONLVFv9bF6l7K1u1W2dOcY9sGYack9cnzd+8sZNAfOcNDH0NAXuTMQOZME6kFo KfVArpiG3eFOkd/6/Sv1e5t8Oe93CVdYNELu7BMtoKD0CbjPcSp5RA6qBGNOlYCgACkPuRcSlY1i royTwfjjnlng4vTm/HEQXCqIvffTr6RhFlkFxyJ1YEWnXn8j/SIDW2FrJMQd1iZmB4KhmG8Z709o DNT9HXz1g3uFDyBKnHGpEKBo9qltmSBSAsHWM4WZbUEvbZhgQpdQfxAxJtcpk6YcaJMeV15mFQ9/ iiHz2IPDLq8Hxg7E6CvzNJ8wRaBbV8kQxb8QAa2Cch5FJM20GYpGCws7YoRUWGCjQbQyKiVgmm/E E4kXZSUZDQJBsmlHqjUs8OAjIoxPhQOpgRGRSJz67hvZ4eGW48xQCNQP15ximIB02ewwEDY0K/QG 5sGgnvFZ4j2gXjyaUlNPczAFZRlGQykdsUr8R+YUihzVi5U4sKwgX1OKBkzVyJD9kzFlzMBfQ15M eZKPGAF5Q9Ibq2fsSxUGttG1ujaO38/UdJiNmNTW2rKE5lQyJ2IU/HG9XY1UV+fvZH3+1s8qC0Zf mTl+K/PaauJHhoWfQIWPpkf6RhHLA6lEV8NIutc/GT6OZ+9Of8/WSmXFUSUc9iKqCA0ks9lCzGQA YTlkU7o/lmKkxAgOHPQsk9CURKQQudDZgV6IB4HQmiVk9GAGX/Zx6McSvem1uod2fxwPfV1t9HRD ThTFjJAl6IxOvfGhhrDODo86mdNoo3twst/axfLt/xJzTZbaOz4nl7YA6opEU56Aw19h6npjchMM pMca+kcZtGxySvBEBs8HrNbbZJphYJyOhXx8oFJ+vIXnP1nouawfD9zKrP9cnFDv7qXE3qz5hvKW bMJZbsIohyRNfKivYDEA4dv4M0bwzeLi6c+4aHVr4+Id5CuK05gmXNn4qOH5mHuOTSTF+JnS+bsN kWc/jnK3KsPbeZ2S67Jgh3wpMVUaBERyC0mTB5mprZs0g8kmkwXf/3JeJV0KhTtGS+qL1GSuNrcq zpHeMaXqDIuolEBGyp6cwy8zjwbC//T9qe8/0de3X4i8LVE085nI/HAlsmbvVd6WqO9NSDKNvif5 vPD6g04PqZ2IJ3fq46ut1YPE1l53vi+Tt5Aa0UyHQkKxLrHmfead5/uShKd39tiD5FyH5IbHsG30 aoSOIOswydyIhXTCRSbxHATTeX7Hq4TVghoxv0mxRw7vtbF8TrhHoSjoXVx/uMGuej1r2Hj4OpjS PGexxuqDm3+hK4fyoXFYx9cy7RC+7x3sHNiQkQaX1IQTkcLzVstwIvG14qw5ElqLeNaO2HiuN2TU Z8Dyvjlzb4+F0HPNINOmWbyWSIOrLL7FAg0Ix0A6rWtAqAofWvnsN80Et2TPfLW/XHBnv3bs/AcA AP//AwBQSwMEFAAGAAgAAAAhANZks1H0AAAAMQMAABwACAF3b3JkL19yZWxzL2RvY3VtZW50Lnht bC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLLasMwEEX3hf6DmH0t O31QQuRsSiHb1v0ARR4/qCwJzfThv69ISevQYLrwcq6Yc8+ANtvPwYp3jNR7p6DIchDojK971yp4 qR6v7kEQa1dr6x0qGJFgW15ebJ7Qak5L1PWBRKI4UtAxh7WUZDocNGU+oEsvjY+D5jTGVgZtXnWL cpXndzJOGVCeMMWuVhB39TWIagz4H7Zvmt7ggzdvAzo+UyE/cP+MzOk4SlgdW2QFkzBLRJDnRVZL itAfi2Myp1AsqsCjxanAYZ6rv12yntMu/rYfxu+wmHO4WdKh8Y4rvbcTj5/oKCFPPnr5BQAA//8D AFBLAwQUAAYACAAAACEAIVqihGIGAADbHQAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZS28T Rxy/V+p3GO0d/IgdkggHxY4NbQhEiaHiON4d7w6Z3VnNjJP4VsGxUqWqtOqhSL31ULVFAqkX+mnS UrVU4iv0PzPr9a49JgaCilp8sOfx+78fM7u+fOUkZuiICEl50vJqF6seIonPA5qELe9Wv3dhzUNS 4STAjCek5Y2J9K5sfvjBZbyhIhITBPSJ3MAtL1Iq3ahUpA/LWF7kKUlgb8hFjBVMRVgJBD4GvjGr 1KvV1UqMaeKhBMfA9uZwSH2C+pqltzlh3mXwlSipF3wmDjRrUqIw2OCwpn/kWHaYQEeYtTyQE/Dj PjlRHmJYKthoeVXz8Sqblys5EVMLaAt0PfPJ6DKC4LBu6EQ4yAlrvcb6pe2cvwEwNY/rdrudbi3n ZwDY98FSq0sR2+it1doTngWQHc7z7lSb1UYZX+C/Modfb7fbzfUS3oDssDGHX6uuNrbqJbwB2WFz Xv/2VqezWsIbkB2uzuF7l9ZXG2W8AUWMJodzaB3PPDI5ZMjZNSd8DeBrkwSYoiqF7LL0iVqUazG+ y0UPACa4WNEEqXFKhtgHXAczOhBUC8AbBBd27JIv55a0LCR9QVPV8j5OMVTEFPLi6Y8vnj5Gp/ee nN775fT+/dN7PzuoruEkLFI9//6Lvx9+iv56/N3zB1+58bKI//2nz3779Us3UBWBz75+9MeTR8++ +fzPHx444FsCD4rwPo2JRDfIMdrnMRjmEEAG4tUo+hGmRYqtJJQ4wZrGge6qqIS+McYMO3BtUvbg bQEtwAW8OrpbUvggEiOVxbsE3IniEnCXc9bmwmnTjpZV9MIoCd3CxaiI28f4yCW7MxPf7iiFXKYu lp2IlNTcYxByHJKEKKT3+CEhDrI7lJb8ukt9wSUfKnSHojamTpf06aCUTVOiazSGuIxdCkK8S77Z vY3anLnYb5OjMhKqAjMXS8JKbryKRwrHTo1xzIrI61hFLiUPxsIvOVwqiHRIGEfdgEjporkpxiV1 d6B1uMO+y8ZxGSkUPXQhr2POi8htftiJcJw6daZJVMR+JA8hRTHa48qpBC9XiJ5DHHCyMNy3KSmF ++zavkXDkkrTBNE7I+EqCcLL9ThmQ0wM88pMr45p8rLGHUPfzgw/v8YNrfLZtw/dnfWdbNlb4ARX zcw26kW42fbc4SKg73533sajZI9AQTig75vz++b8n2/Oi+r5/FvytAubK/jkom3YxAtv3UPK2IEa M3Jdmv4twbygB4tmYojyS34awTATV8KFApsxElx9QlV0EOEUxNSMhFBmrEOJUi7h0cIsO3nrDTg/ lF1rTh4qAY3VLg/s8krxYTNnY2aheaCdCFrRDJYVtnLpzYTVLHBJaTWj2ry03GSnNPOTeRPqBmH9 KqG2WreiIVEwI4H2u2UwCctbDFFmtTUkwgFxLBfsqxl3nrs3i4lythLn4+QJg6mTddnNVBNLyjN0 3PLWm/Wmh3yctrwh3JZgGKfAT+pOg1mYtDxfWQPPrsUZi9fdWVWrTtbnDC6JSIVU21hGlspsZUQs mepfbza0H87HAEczWU6LlbXav6iF+SmGlgyHxFcLVqbTbI+PFBEHUXCMBmwk9jHo3bDZFVAJnd7k mp4IyG2zA7Ny4Wa1MfvKJqsZzNIIZ9muX81MLLRwM851MLOCevlsRvfXNEVX/HmZUkzj/5kpOnPh froS6KEPp7jASOdoy+NCRRy6UBpRvyfg3DeyQC8EZaFVQky/gNa6kqNp37I8TEHBhUPt0xAJCp1O RYKQPZXZeQazWtYVs8rIGGV9JldXpvZ3QI4I6+vqXdX2eyiadJPMEQY3G7TyPHPGINSF+q5eXGza vOrBMxVk6ZcVVmj6haNg/c1UWOYALoizHWtOXL258OSZPWpTeMpA+gsaNxU+m15P+3wfoo/ycx5B Il7QXU1nYb44AJ3topWmWVkJb/8WlMudcXaxOM7R2fklasbZLxf3+s7ORiVfF/PI4erKfIlWCs8h Zjb3RxQf3AXZ2/B4M2J2RaYws4M9YQwe8GCcDZm0LcE6YtLSWbJPhogGJ5Owzng0+6cnP8z3rQBt e064cjZhhtc4251y4vrZxDmFkQwtOyc2T3EuBmwq2eJtlPMWmXuKJW/isiWUd7vMmb3LumyJQL2G y9TJy12WeariSjxyogTuTP66gvy1jEzKbv4DAAD//wMAUEsDBBQABgAIAAAAIQBGK3qy7QMAAOAK AAARAAAAd29yZC9zZXR0aW5ncy54bWy0Vttu4zYQfS/QfzD0XEeXyI4jrLNI7LjJIu4WlRd9piTK JsIbSMqOt+i/d0iJlr1ZLJwu8mJTc2bODEdnSH34+MLoYIuVJoJPg/giCgaYl6IifD0NvqwWw0kw 0AbxClHB8TTYYx18vPn1lw+7TGNjwE0PgILrjJXTYGOMzMJQlxvMkL4QEnMAa6EYMvCo1iFD6rmR w1IwiQwpCCVmHyZRNA46GjENGsWzjmLISKmEFrWxIZmoa1Li7s9HqHPytiFzUTYMc+MyhgpTqEFw vSFSezb2f9kA3HiS7Y82sWXU++3i6Izt7oSqDhHnlGcDpBIl1hpeEKO+QML7xOkrokPuC8jdbdFR QXgcudVx5aO3ESSvCMYlqd7GMe44Qog84tH4bTQjT6P3DL94Ik3PaW0LPZFCIdUKt+srK7PHNRcK FRTKgf4OoEUDV539tRXfwNB8FYINdpnEqgTlwMRFURBaAN6XqHODDLhnWmJK3QiWFCNg32VrhRgM j7e4mArXqKFmhYrcCAlOWwSbuEo6ynKDFCoNVrlEJbDNBDdKUO9XiT+EmcEgKtBJF+HGsl/l7YhD BEcMtnUytktRYVtZo8j5/bcBLns8Ok75bSIBR5IiFV7ZduZmT/ECis/JV3zLq0+NNgQY3fD+RAU/ KgBzm/kzCGC1l3iBkWmgTe+UzL2JBSVySZQS6pFXoI13S0bqGitIQEBrS5APUWLn+vyAUQU3wTvl bTT+G5xh/i5XIMvnO2GMYA97uYFe/9ybdHoPj+UL91ml/eIvIczBNZrNkjhN2kot2iNJNLpbzL+H XN6mo6tOsKdIzxYesrLM3gV/Kr+y0h2wNmKGWKEIGiztbRFaj0I93xHu8QLDaYOPkbwpPDgctoBm iNIFNNEDrgEsq4iWc1y7NV0ite55Ow/1XSucI58OXPZcwup3JRrZojuFZCtJ7xKnaRdJuHkizNt1 U+Q+isP5eAQ1vPq8Va5PfXt2mYFX7Eb7CTmpOF/Mh1/yTkpU5VYGeImkbNVUrONpQMl6Y2IrAANP FXxUuIdinXRY4rCkxdwDKu3OwLtb9LbE2478Lr3tsrel3pb2tpG3jXrb2NvG1raB80PBYf4MwvZL a68FpWKHq4cef2Vqm6A3SOJ5e9aDvERr6A5/Pdhm+AVuElwRA99qklQMvdiLJRnb8M6bor1ozImv xayzPGWokEHdKIcnwU7i39Ri76CSgBzzPSv6q+WiLZwSDceAhFvICOWx3xwWp1klykeYJFi111Y0 T6/vZ+3dFY8O8KiF/5ncXqWT2WQyvJ8kk2F6Nbof3i6uL2GVRvP4enydTKJ/u0H0n6Y3/wEAAP// AwBQSwMEFAAGAAgAAAAhABBFv1ysDAAAEH0AAA8AAAB3b3JkL3N0eWxlcy54bWzUnUtz2zgSx+9b td+BpdPuIbHlh5xJjTPlOMnEtXbiiZzNGSIhC2uS0JKUH/vpFwBBiXQTJBvsuCpzmFiU+gewu/8A ms/f/3hM4uCeZ7mQ6elk+np/EvA0lJFIb08n328+vXozCfKCpRGLZcpPJ088n/zx7u9/+/3hbV48 xTwPFCDN3ybh6WRVFOu3e3t5uOIJy1/LNU/Vl0uZJaxQH7PbvYRld5v1q1Ama1aIhYhF8bR3sL8/ m1hMNoQil0sR8g8y3CQ8LYz9XsZjRZRpvhLrvKI9DKE9yCxaZzLkea52OolLXsJEusVMjwAoEWEm c7ksXqudsT0yKGU+3Td/JfEOcIwDHADALBQRjjGzjD1lWePkHIc5rjD5U8IfJ0ESvr24TWXGFrEi KdcEau8CA9b/1429U8kRyfADX7JNXOT6Y3ad2Y/2k/nnk0yLPHh4y/JQiNPJOYvFIhMTtYWzvDjL BWtsXJ2lefNnYb77uKeR+f/U1nsWn04ODqot57qJxraYpbfVNp6++vN9s0m16ftcb1qISLXHslfz M224Z3te/lvbn/XzT6bhNQuFaYctC64Sezrb19BYaB0dHP9Wffi20Z5km0LaRgyg/HeL3QMuVfmu sn9eilB9y5eXMrzj0bxQX5xOTFtq4/eL60zITAntdPKbaVNtnPNEfBZRxNPaD9OViPiPFU+/5zza bf/rkxGL3RDKTar+Pjw5NmGO8+jjY8jXWnrq25Qlqukv2iDWv96IXePG/L8VbGoj0Wa/4kyPP8H0 OcJ0H4U40BZ5bW/bmZtn+25+hWro8KUaOnqpho5fqqHZSzV08lINvXmphgzmZzYk0og/lkKEzQBq H8ehRjTHITY0x6ElNMchFTTHoQQ0x5HoaI4jj9EcR5oiOIUMXVlYS/ZDR7Z3c/vnCD9u/5Tgx+2f Afy4/QO+H7d/fPfj9g/nftz+0duP2z9Y47nlUiu4UDJLi9EqW0pZpLLgQcEfx9NYqlimKKPh6UmP ZyQ7SYApRzY7EY+mhcx87s8QI1L/+bzQZVsgl8FS3G4yVcuP7ThP73msquqARZHiEQIzXmwyh0d8 cjrjS57xNOSUiU0H1ZVgkG6SBUFurtktGYunEbH7KiLJoLBNaFU/r7RIBEFSJyzM5PiuSUY2PlyK fLyvNCR4v4ljTsT6QpNihjW+NjCY8aWBwYyvDAxmfGFQixmViyyNyFOWRuQwSyPyW5mfVH6zNCK/ WRqR3yxtvN9uRBGbIb6+6pgOP3Z3Hkt9GH10P+biNmVqATB+urHHTINrlrHbjK1XgT7s3I6t7zO2 nfcyegpuKOa0LYlqXW9S5FzttUg34x3aoFGJa8sjkteWRySwLW+8xK7UMlkv0D7T1DPzzaJoFa0h DRLtnMWbckE7Xm2sGJ9hOwF8EllOJoN2LEEGf9HLWR1OipFv18vxHduxxsvq+ahE2j2LJOhlLMM7 mmH489OaZ6osuxtN+iTjWD7wiI44LzJZ5lpd8gcmJIMk/zFZr1guTK3UQAyf6qsT8MEVW4/eoeuY iZQmbh9fJUzEAd0K4vPN1WVwI9e6zNSOoQG+l0UhEzKmPRL4jx988U+aDp6pIjh9ItrbM6LDQwZ2 LggmmZIkIyKSWmaKVJDMoYb3L/60kCyLaGjXGS+veSk4EXHOknW56CDQlhoXH9T4Q7AaMrx/s0zo 40JUorohgdUOG+abxX94OH6o+yIDkiNDXzeFOf5olrrGmg43fpnQwI1fIphoqulB5y/BzjZw43e2 gaPa2fOY5blwnkL15lHtbsWj3t/xxZ/lyVhmy01M58AKSObBCkjmQhlvkjSn3GPDI9xhw6PeX8KU MTyCQ3KG92cmIrJgGBhVJAyMKgwGRhUDAyMNwPgrdGqw8Zfp1GDjr9UpYURLgBqMKs9Ip3+iszw1 GFWeGRhVnhkYVZ4ZGFWeHX4I+HKpFsF0U0wNSZVzNSTdRJMWPFnLjGVPRMiPMb9lBAdIS9p1Jpf6 ZgiZlhdxEyD1MeqYcLFd4qiC/IMvyLqmWZT9IjgiyuJYSqJja7sJx1g2r13rM7tZ8WR8GX0ds5Cv ZBzxzLFPbltVL8/L2zKed990Y9Bhz0txuyqC+Wp7tL+Ome33WlYFe8Osv8E2n8+q+1nazK54JDZJ 1VF4M8XscLixyeiG8VG/8W4l0bA8HmgJ25z1W+5WyQ3Lk4GWsM03Ay2NThuWXXr4wLK71kQ46cqf bY3nSL6TrizaGrc225VIW8u2FDzpyqKGVIKzMNRnC2B0hmnGbT9MPG57jIrcFIyc3JTBunIjugT2 jd8LPbNjBk3T3vbqCTDum0X0oJHzr40sj9s3TjgNv6nrQi2c0pwHrZzD4SeuGqOM24+Dhxs3YvC4 40YMHoDciEEjkdMcNSS5KYPHJjdi8CDlRqBHKzgj4EYraI8braC9z2gFKT6j1YhVgBsxeDngRqCF ChFooY5YKbgRKKECcy+hQgpaqBCBFipEoIUKF2A4oUJ7nFChvY9QIcVHqJCCFipEoIUKEWihQgRa qBCBFqrn2t5p7iVUSEELFSLQQoUItFDNenGEUKE9TqjQ3keokOIjVEhBCxUi0EKFCLRQIQItVIhA CxUiUEIF5l5ChRS0UCECLVSIQAu1vNXQX6jQHidUaO8jVEjxESqkoIUKEWihQgRaqBCBFipEoIUK ESihAnMvoUIKWqgQgRYqRKCFak4WjhAqtMcJFdr7CBVSfIQKKWihQgRaqBCBFipEoIUKEWihQgRK qMDcS6iQghYqRKCFChFd+WlPUbous5/ij3o6r9gffurKdupb/VbuOupwOKrqlZs1/F6E91LeBa03 Hh6aemMYRCxiIc0hasdp9TrXXBKBOvH59bz7Dp86feRDl+y9EOacKYAfDbUEx1SOulK+bgmKvKOu TK9bglXnUdfoW7cE0+BR16BrdFldlKKmI2DcNczUjKcO867RumYOXdw1RtcMoYe7RuaaIXRw13hc MzwO9OD83Pp4oJ9m2+tLAaErHWuEEzehKy1hrKrhGApjaNDchKHRcxOGhtFNQMXTicEH1o1CR9iN 8gs1lBk21P5CdROwoYYEr1ADjH+oIco71BDlF2o4MGJDDQnYUPsPzm6CV6gBxj/UEOUdaojyCzWc yrChhgRsqCEBG+qRE7IT4x9qiPIONUT5hRou7rChhgRsqCEBG2pI8Ao1wPiHGqK8Qw1RfqEGVTI6 1JCADTUkYEMNCV6hBhj/UEOUd6ghqivU5ihKI9SoCNfMcYuwmiFuQq4Z4gbnmqFHtVSz9qyWagTP agnGqoo5rlqqB81NGBo9N2FoGN0EVDydGHxg3Sh0hN0ov1DjqqW2UPsL1U3AhhpXLTlDjauWOkON q5Y6Q42rltyhxlVLbaHGVUttofYfnN0Er1DjqqXOUOOqpc5Q46old6hx1VJbqHHVUluocdVSW6hH TshOjH+ocdVSZ6hx1ZI71LhqqS3UuGqpLdS4aqkt1LhqyRlqXLXUGWpctdQZaly15A41rlpqCzWu WmoLNa5aags1rlpyhhpXLXWGGlctdYYaVy1dKRNB8AioecKyIqB7Xtxnlq8KNv7hhN/TjOcyvudR gN7VvYfGO6t0G+YVcur3hdpR/djy2j1GUfnYVgs0P7yItu+W0sa6R4F9i5fdbDpuz7GWLRrDnqa2 cHuCdwrwuzdSmRYWTO3VV+0V0Hiqn2bYsn2XQdW3ViO73m7fHHbH+fqL4pht+sOlSHluPu1eKrbQ D/TiWq3mxqfqHWMHVjOyfGbS5X1ctWe+qN4utn0H26LEbl+bVom//tq0clvt7Wc+Tj1wOtXqidKp u4Qsf9dIRxK3H5Yvc7Nuf+P0epX53V4/tMN+3evltpFeP3R63Z7S/7W8ftBIdrfXTUr1ev2gJdfL bSO9fuT0ur0c4hfz+lHd69W1FdDrJqX6vW590PC62TbS6+UbCdu8bi8l+cW8Xj6Ktdfrleug10f6 c+b0px2tfjF/7g/zp0mW/iy29o0srqbYHq+HK+X20D7t0rHOsU+t3952bZ5Z/zwejkfbOzxtFy99 nnb3u9BL5I4+myV05wKtXGU7U2FwLhSLuAyL+uMijRTgwb5gtOxp9MhKlPr+nMfxFSt/Ldfun8Z8 qVNWfTvdNw85evb9onxer9M+M4WdE7DX7Ez5sTtPyjf42CsOnethXb20uNtc/jrW09iRo7yI83ln yq10Q8bUau+nLJ17lV9dOVxXfrnNd7zdPsH/ueO2XxD6zo4CP2P9C1z3/AXPf3KZ3QqmDXdvW65t tC94rm3RL3iuPpqeCPP/UBfp1S7NzH9VUKqtmEKm+it/938AAAD//wMAUEsDBBQABgAIAAAAIQBK XMEeCAEAAFwCAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWyU0EFuwyAQBdB9pd4BsY+xo8aqrDjZ VJW6bnsAjMcJCsNYDKnj25e4Tlspm2SDQPAffNbbEzrxBYEt+VoWWS4FeEOt9btafn68Lp6l4Kh9 qx15qOUILLebx4f1UA3QvEOM6SSLpHiu0NRyH2NfKcVmD6g5ox582uwooI5pGXYKdTgc+4Uh7HW0 jXU2jmqZ56WcmXCLQl1nDbyQOSL4OOVVAJdE8ry3PV+04RZtoND2gQwwpz7ofjzU1v8yxdMVhNYE YupilsrML5qoFC/yaYbuD1jdByyvgNLY9j6jnA2Vkv8chvuY1YXhEeEkBZrqbecp6MYlKX2NSO3E BJ/H82Vq8w0AAP//AwBQSwMEFAAGAAgAAAAhABWMpCr4AQAAGQYAABIAAAB3b3JkL2ZvbnRUYWJs ZS54bWy8k99umzAUxu8n7R2Q7xsMCWmLSqqta6bd7KLqHsAxJljzH+RjQvP2OwaSVMualV0MJMt8 5/jn4++Yu/sXraKdcCCtKUgyoyQShttSmm1Bfjyvr25IBJ6ZkilrREH2Asj96uOHuy6vrPEQ4XoD ueYFqb1v8jgGXgvNYGYbYTBYWaeZx0+3jTVzP9vmilvdMC83Ukm/j1NKl2TEuPdQbFVJLr5Y3mph fL8+dkIh0RqoZQMHWvceWmdd2TjLBQCeWauBp5k0R0yyOANpyZ0FW/kZHmasqEfh8oT2M61OgGwa ID0DLLkspzGWIyPGla84IKZhsgMG9lq8kEjz/NvWWMc2CkloTYSni3pwGMNmq/FuRF1umMasB6bk xsk+0DBjQSQY2zFVEJrSNc1wDO+CzsNI4pDIa+ZABMiQSAe5Ylqq/UGFTgIMgUZ6Xh/0HXMyVDiE QG4x0MKGFuSRUpp+Wq/JoCRYXVAW159HJQ179c/tqMyPCg0K7zn9ZzJweM855uCe8eDAmRPPUguI vosuerKamTccSekSncjQj+DMfJIjrudOduTxd0eub7L/4shXgT+hZG84MThwcmI+wQnWevsHI0pR sVb5SzU9MI3X9VJNQ3dCl6bd13/rDl2+7s4iDff1qITupKdeXO7O7d+6M05g9QsAAP//AwBQSwME FAAGAAgAAAAhAKkQCkhKAQAAkQIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySXWvCMBSG7wf7DyX3bdKWiStthW14NWEwx8buQnLUYPNB kln990urVsu82FUJ73OenHPScraXTbQD64RWFUoTgiJQTHOh1hX6WM7jKYqcp4rTRiuo0AEcmtX3 dyUzBdMW3qw2YL0AFwWTcgUzFdp4bwqMHduApC4JhArhSltJfTjaNTaUbekacEbIBEvwlFNPcSeM zWBEJyVng9L82KYXcIahAQnKO5wmKb6wHqx0Nwv65IqUwh8M3ETP4UDvnRjAtm2TNu/R0H+Kvxav 7/2osVDdrhiguuSsYBao17Y2EG6OdlRFPHyd19sSX8XdKhvq/CJsfSWAPx1uVvylukILO9G9XZ33 xHAsT4s43gI8CgMUx3HPyWf+/LKcozoj6WNM8jibLMm0eEgLQr67Bkf1F6E8NfB/YzY2ngV13/H4 J6p/AQAA//8DAFBLAwQUAAYACAAAACEADdau29sBAADfAwAAEAAIAWRvY1Byb3BzL2FwcC54bWwg ogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcU8Fu2zAMvQ/YPxi6N3KSrSgCWcWQ YuhhWwPEbc+aTDvCZEmQ2KDZ14+yF8/ZeppPj4/00xNJidvX3hZHiMl4V7HlomQFOO0b47qKPdaf r25YkVC5RlnvoGInSOxWvn8ndtEHiGggFSThUsUOiGHDedIH6FVaUNpRpvWxV0hh7LhvW6PhzuuX HhzyVVlec3hFcA00V2ESZKPi5oj/K9p4nf2lp/oUSE+KGvpgFYL8lv+0i8ZjL/jEitqjsrXpQa6I ngKxUx0kuRR8BOLZxybJ1epG8BGK7UFFpZE6KJfrci34jBCfQrBGK6Tmyq9GR598i8XD4LjIAoLP SwTdYg/6JRo8yVLweSi+GJetED0i8hZVF1U4JLnOBqdI7LWysKUGyFbZBIL/IcQ9qDzcnTLZ4BE3 R9DoY5HMTxrvihXfVYLctoodVTTKIRvLxmDANiSMsjZoSXuKBzgvm2PzIXdxBJeFQzB4IHzpbjgh PbR0N3zD7HJudvAwWp3ZmTs7n/GX6tb3QTlqMJ8QNfhHegy1v8vL8buHl+Rs7s8GD/ugdJ7Ox7wZ b6bEnlhoaKTTUCZC3NMVos0H0L+ug+Zc828i79TT+F7l8npR0jcs0ZmjTZgekvwFAAD//wMAUEsB Ai0AFAAGAAgAAAAhAN+k0mxaAQAAIAUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz XS54bWxQSwECLQAUAAYACAAAACEAHpEat+8AAABOAgAACwAAAAAAAAAAAAAAAACTAwAAX3JlbHMv LnJlbHNQSwECLQAUAAYACAAAACEAVNwMrmMHAAAzKQAAEQAAAAAAAAAAAAAAAACzBgAAd29yZC9k b2N1bWVudC54bWxQSwECLQAUAAYACAAAACEA1mSzUfQAAAAxAwAAHAAAAAAAAAAAAAAAAABFDgAA d29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQAhWqKEYgYAANsdAAAV AAAAAAAAAAAAAAAAAHsQAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEARit6 su0DAADgCgAAEQAAAAAAAAAAAAAAAAAQFwAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAA ACEAEEW/XKwMAAAQfQAADwAAAAAAAAAAAAAAAAAsGwAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAG AAgAAAAhAEpcwR4IAQAAXAIAABQAAAAAAAAAAAAAAAAABSgAAHdvcmQvd2ViU2V0dGluZ3MueG1s UEsBAi0AFAAGAAgAAAAhABWMpCr4AQAAGQYAABIAAAAAAAAAAAAAAAAAPykAAHdvcmQvZm9udFRh YmxlLnhtbFBLAQItABQABgAIAAAAIQCpEApISgEAAJECAAARAAAAAAAAAAAAAAAAAGcrAABkb2NQ cm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQAN1q7b2wEAAN8DAAAQAAAAAAAAAAAAAAAAAOgt AABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAALAAsAwQIAAPkwAAAAAA== --=_4e58e05f24077a79a43085ead886c66b-- From nobody Tue Mar 26 03:36: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 6C830120296 for ; Tue, 26 Mar 2019 03:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 NNKGM0LemSnq for ; Tue, 26 Mar 2019 03:36:21 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCFB12014F for ; Tue, 26 Mar 2019 03:36:20 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 44T6xG5kJKz8tRh; Tue, 26 Mar 2019 11:36:18 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 44T6xG4qw9z1xqm; Tue, 26 Mar 2019 11:36:18 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2%21]) with mapi id 14.03.0439.000; Tue, 26 Mar 2019 11:36:18 +0100 From: To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] Roll meeting in Prague Thread-Index: AQHU47IWkoZye4IRA0yqcIkvP8xO/qYduBcA Date: Tue, 26 Mar 2019 10:36:17 +0000 Message-ID: <11450_1553596578_5C9A00A2_11450_278_3_D8BFBEBC.5F5A2%dominique.barthel@orange.com> References: <993a01cc2923fd5b0fbfbb2c8fb835a9@bbhmail.nl> In-Reply-To: <993a01cc2923fd5b0fbfbb2c8fb835a9@bbhmail.nl> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_D8BFBEBC5F5A2dominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Roll meeting in Prague 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, 26 Mar 2019 10:36:24 -0000 --_000_D8BFBEBC5F5A2dominiquebarthelorangecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGFyZSBleHRlbmRlZCB0byBGYWJyaWNlIFRoZW9sZXlyZSBmb3IgYmVpbmcgc3VjaCBh biBlZmZpY2llbnQgYXNzaXN0YW50IG5vdGUgdGFrZXIhDQpCZXN0IHJlZ2FyZHMNCg0KRG9taW5p cXVlDQoNCkRlIDogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpyb2xsLWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgUGV0ZXIgdmFuIGRlciBTdG9rIDxzdG9rY29uc0Bi YmhtYWlsLm5sPG1haWx0bzpzdG9rY29uc0BiYmhtYWlsLm5sPj4NClNvY2nDqXTDqSA6IHZhbmRl cnN0b2sgY29uc3VsdGFuY3kNClLDqXBvbmRyZSDDoCA6ICJjb25zdWx0YW5jeUB2YW5kZXJzdG9r Lm9yZzxtYWlsdG86Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc+IiA8Y29uc3VsdGFuY3lAdmFu ZGVyc3Rvay5vcmc8bWFpbHRvOmNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPj4sICJyb2xsQGll dGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPiIgPHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxA aWV0Zi5vcmc+Pg0KRGF0ZSA6IFR1ZXNkYXkgMjYgTWFyY2ggMjAxOSAwOTo1OA0Kw4AgOiAicm9s bEBpZXRmLm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4iIDxyb2xsQGlldGYub3JnPG1haWx0bzpy b2xsQGlldGYub3JnPj4NCk9iamV0IDogW1JvbGxdIFJvbGwgbWVldGluZyBpbiBQcmFndWUNCg0K SEkgUk9MTCwNCg0KVGhlIHJvbGwgbWVldGluZyBpcyBiZWhpbmQgdXMgYW5kIHdlIHdhbnQgdG8g dGhhbmsgRG9taW5pcXVlIGFuZCBSYWh1bCBmb3IgYmVpbmcgdGhlIG1pbnV0ZSB0YWtlciBhbmQg dGhlIEphYmJlciBTY2hyaWJlcg0KVGhlIGxpbmsgZm9yIHRoZSBtaW51dGVzIGlzOg0KDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9taW51dGVzLTEw NC1yb2xsLTAwDQoNClBsZWFzZSwgc2VuZCBjb21tZW50cyBiZWZvcmUgdGhlIGRlYWRsaW5lIDIw MTktMDQtMTkNCkF0dGFjaGVkIHlvdSB3aWwgZmluZCBhIGhpZ2ggbGV2ZWwgc3VtbWFyeSBvZiB0 aGUgbWVldGluZy4gSG9wZSB0aGlzIGlzIHVzZWZ1bC4NCg0KR3JlZXRpbmdzIGFuZCB0aGFua3Mg Zm9yIHlvdXIgY29sbGFib3JhdGlvbiwNCg0KSW5lcyBhbmQgUGV0ZXINCi0tDQpQZXRlciB2YW4g ZGVyIFN0b2sNCnZhbmRlcnN0b2sgY29uc3VsdGFuY3kNCm1haWx0bzogY29uc3VsdGFuY3lAdmFu ZGVyc3Rvay5vcmc8bWFpbHRvOmNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPiwgc3Rva2NvbnNA YmJobWFpbC5ubDxtYWlsdG86c3Rva2NvbnNAYmJobWFpbC5ubD4NCnd3dzogd3d3LnZhbmRlcnN0 b2sub3JnPGh0dHA6Ly93d3cudmFuZGVyc3Rvay5vcmc+DQp0ZWwgTkw6ICszMSgwKTQ5MjQ3NDY3 MyAgICAgRjogKzMzKDApOTY2MDE1MjQ4DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_D8BFBEBC5F5A2dominiquebarthelorangecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5UaGFua3MgYXJl IGV4dGVuZGVkIHRvIEZhYnJpY2UgVGhlb2xleXJlIGZvciBiZWluZyBzdWNoIGFuIGVmZmljaWVu dCBhc3Npc3RhbnQgbm90ZSB0YWtlciE8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Eb21pbmlxdWU8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7 IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBB RERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47 IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25l OyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EZSZu YnNwOzogPC9zcGFuPlJvbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5v cmciPnJvbGwtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBQZXRlciB2YW4g ZGVyIFN0b2sgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG9rY29uc0BiYmhtYWlsLm5sIj5zdG9rY29u c0BiYmhtYWlsLm5sPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ U29jacOpdMOpJm5ic3A7OiA8L3NwYW4+dmFuZGVyc3RvayBjb25zdWx0YW5jeTxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Sw6lwb25kcmUgw6AmbmJzcDs6IDwvc3Bhbj4mcXVv dDs8YSBocmVmPSJtYWlsdG86Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmciPmNvbnN1bHRhbmN5 QHZhbmRlcnN0b2sub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvbnN1bHRhbmN5 QHZhbmRlcnN0b2sub3JnIj5jb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mcXVvdDsN CiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlJm5ic3A7OiA8L3NwYW4+ VHVlc2RheSAyNiBNYXJjaCAyMDE5IDA5OjU4PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPsOAJm5ic3A7OiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5v cmciPnJvbGxAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRm Lm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPk9iamV0Jm5ic3A7OiA8L3NwYW4+W1JvbGxdIFJvbGwgbWVldGluZyBpbiBQcmFndWU8 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogVmVyZGFuYSxHZW5ldmEsc2Fucy1zZXJpZiI+DQo8ZGl2 PkhJIFJPTEwsPGJyPg0KPGJyPg0KVGhlIHJvbGwgbWVldGluZyBpcyBiZWhpbmQgdXMgYW5kIHdl IHdhbnQgdG8gdGhhbmsgRG9taW5pcXVlIGFuZCBSYWh1bCBmb3IgYmVpbmcgdGhlIG1pbnV0ZSB0 YWtlciBhbmQgdGhlIEphYmJlciBTY2hyaWJlcjwvZGl2Pg0KPGRpdj5UaGUgbGluayBmb3IgdGhl IG1pbnV0ZXMgaXM6PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9taW51dGVzLTEw NC1yb2xsLTAwIiB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA0L21hdGVyaWFscy9taW51dGVzLTEwNC1yb2xsLTAw PC9hPiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UGxlYXNlLCBzZW5kIGNv bW1lbnRzIGJlZm9yZSB0aGUgZGVhZGxpbmUmbmJzcDs8c3Bhbj4yMDE5LTA0LTE5PGJyPg0KQXR0 YWNoZWQgeW91IHdpbCBmaW5kIGEgaGlnaCBsZXZlbCBzdW1tYXJ5IG9mIHRoZSBtZWV0aW5nLiBI b3BlIHRoaXMgaXMgdXNlZnVsLjxicj4NCjxicj4NCkdyZWV0aW5ncyBhbmQgdGhhbmtzIGZvciB5 b3VyIGNvbGxhYm9yYXRpb24sPGJyPg0KPGJyPg0KSW5lcyBhbmQgUGV0ZXI8L3NwYW4+PC9kaXY+ DQo8ZGl2Pi0tIDxicj4NCjxkaXYgY2xhc3M9InByZSIgc3R5bGU9Im1hcmdpbjogMDsgcGFkZGlu ZzogMDsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZSI+UGV0ZXIgdmFuIGRlciBTdG9rPGJyPg0KdmFu ZGVyc3RvayBjb25zdWx0YW5jeTxicj4NCm1haWx0bzogPGEgaHJlZj0ibWFpbHRvOmNvbnN1bHRh bmN5QHZhbmRlcnN0b2sub3JnIj5jb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzwvYT4sDQo8YSBo cmVmPSJtYWlsdG86c3Rva2NvbnNAYmJobWFpbC5ubCI+c3Rva2NvbnNAYmJobWFpbC5ubDwvYT48 YnI+DQp3d3c6IDxhIGhyZWY9Imh0dHA6Ly93d3cudmFuZGVyc3Rvay5vcmciIHRhcmdldD0iX2Js YW5rIiByZWw9Im5vcmVmZXJyZXIiPnd3dy52YW5kZXJzdG9rLm9yZzwvYT48YnI+DQp0ZWwgTkw6 ICYjNDM7MzEoMCk0OTI0NzQ2NzMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RjogJiM0MzszMygw KTk2NjAxNTI0ODwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPFBSRT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_D8BFBEBC5F5A2dominiquebarthelorangecom_--