From nobody Thu Jun 1 00:28:26 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98BF12AF6E for ; Thu, 1 Jun 2017 00:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jpKD-rxk9feQ for ; Thu, 1 Jun 2017 00:28:23 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 3FA44129B52 for ; Thu, 1 Jun 2017 00:28:23 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v517SJ4W039458; Thu, 1 Jun 2017 09:28:19 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 635ED1D53C1; Thu, 1 Jun 2017 09:28:18 +0200 (CEST) Received: from 83.47.118.233 by webmail.entel.upc.edu with HTTP; Thu, 1 Jun 2017 09:27:59 +0200 Message-ID: In-Reply-To: <3c5e78783f5ab589b74f3a5556df434e.squirrel@webmail.entel.upc.edu> References: <3c5e78783f5ab589b74f3a5556df434e.squirrel@webmail.entel.upc.edu> Date: Thu, 1 Jun 2017 09:27:59 +0200 From: "Carles Gomez Montenegro" To: "lp-wan" Cc: "Juan Carlos Zuniga" , "Alexander Pelov" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: Delayed for 57:51:47 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Thu, 01 Jun 2017 09:28:19 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] Window mode as default fragmentation in SCHC + Minutes from Interim on 24/05 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 07:28:26 -0000 ... and here are the slides I promised: https://www.dropbox.com/s/40opp6d2bx6nt9p/Overhead%20analysis.pdf?dl=0 Note that as suggested in recent discussions, for Window mode, it is possible to define use of a CFN size (i.e. N) one bit greater than the maximum one we are currently considering. The latter is given by floor[log_2(L2_MTU+1)], with L2_MTU expressed in bits. The "trick" is to support a bitmap size lower than 2^N bits. For example, for fragmented IPv6 packet transmission in Sigfox uplink, N=6 can be used. However, the maximum bitmap size would be 56 bits, assuming an 8-bit ACK header, since the downlink L2 MTU is 64 bits. This technique, which should be explicitly described in the draft, allows to further reduce the ACK overhead in Window mode (e.g. one ACK every 56 fragments, in the above example, for a large enough IPv6 packet). Cheers, Carles > Hi, > > I also agree. > > After looking carefully at evaluation results [1], an overall conclusion > is that it is possible to configure the window size to have low ACK > overhead at a reasonably low cost in terms of fragmentation header size > (and number of fragments for a given IPv6 packet size). > > Supporting more than one window size (e.g. advertised by means of a > corresponding Rule ID), when possible, is a further interesting feature > for performance improvement. > > On the other hand, I think we need more time to better analyze the > different proposals for Packet mode, so working on it in a different > document will allow for a longer term effort. > > Cheers, > > Carles > > [1] I will soon share some slides on this... > > > > > > >> Hi Alex, >> >> I agree that the window mode provides enough support and flexibility for >> the basic use cases. The more advanced fragmentation mechanisms to be >> defined later on can be easily supported and communicated with Rule IDs, >> as you mention. >> >> +1 for Window as default fragmentation mode. >> >> Best, >> >> Juan Carlos >> >>> -----Original Message----- >>> From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Alexander >>> Pelov >>> Sent: May 29, 2017 12:34 PM >>> To: lp-wan >>> Subject: [lp-wan] Window mode as default fragmentation in SCHC + >>> Minutes >>> from Interim on 24/05 >>> >>> Dear all, >>> >>> The minutes from the last interim meeting have been uploaded and can be >>> found at the following address: >>> https://www.ietf.org/proceedings/interim- >>> 2017-lpwan-03/minutes/minutes-interim-2017-lpwan-03-201705241600-00 >>> >>> One of the main topics that were discussed was the advancement of the >>> fragmentation part of the IP/UDP SCHC document ( >>> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 >>> ). >>> >>> During the call we have reached a rough consensus that the Window mode >>> covers all use-cases, is simple (from implementation and protocol point >>> of >>> view), is well understood, and can be included as a default mode for >>> fragmentation in the RFC. >>> >>> We have also indicated that there are other ways of doing the >>> fragmentation >>> (most notably the Packet mode), but some corner cases still need to be >>> covered >>> (e.g. bitmap sizes bigger than available payload limiting the MTU to >>> less than >>> 1280), and some advanced ways of actually solving this (Bloom filters >>> were >>> mentioned I think). These are all interesting ideas and they merit a >>> longer >>> discussion to find the right balance. These are to be kept in a >>> separate >>> document, which can continue its life independently, and if the WG >>> decides can >>> be included as a future WG item. If a future devices implement these >>> other >>> fragmentation mechanisms, they will be perfectly compatible with the >>> default >>> Window mode (the Rule ID can indicate which fragmentation mode is >>> used). >>> >>> We would like to confirm that you approve the Window mode as the >>> default >>> mode for fragmentation to be included in the SCHC IP/UDP document. >>> >>> Best, >>> The chairs >>> >>> _______________________________________________ >>> lp-wan mailing list >>> lp-wan@ietf.org >>> https://www.ietf.org/mailman/listinfo/lp-wan >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >> > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > From nobody Thu Jun 1 00:34:58 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457E212AF77 for ; Thu, 1 Jun 2017 00:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 Hu3GT_cDrp_b for ; Thu, 1 Jun 2017 00:34:53 -0700 (PDT) Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id B2BD71294AB for ; Thu, 1 Jun 2017 00:34:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 7A3D63025A for ; Thu, 1 Jun 2017 09:34:51 +0200 (CEST) Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xECA-oYBHAQD for ; Thu, 1 Jun 2017 09:34:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 9F59830262 for ; Thu, 1 Jun 2017 09:34:50 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy220.enst-bretagne.fr 9F59830262 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1496302490; bh=xQoZ9BGuv56AvXOYtNhzErDTJhQhjddLx04ccfcIe9Y=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=O225gB4/VQpi7WEo3ky6JnRo2Cr8y3wI2D76aRt/2rYD4JYLC7e5nT2L2nORq3Qys PpGtuh7yWWlo72tJ0au9xhpnWI3bHFMPH86OgRNL3NO2to39rOYPyNDzUYQOST23si b7jTDY0AkSyK7rvQvin4aRwWdbVHC4lLyR8A1Dkk= X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D3fKbqefT69s for ; Thu, 1 Jun 2017 09:34:50 +0200 (CEST) Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com [209.85.216.177]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTPSA id 27DDA3025B for ; Thu, 1 Jun 2017 09:34:50 +0200 (CEST) Received: by mail-qt0-f177.google.com with SMTP id w1so2901557qtg.2 for ; Thu, 01 Jun 2017 00:34:50 -0700 (PDT) X-Gm-Message-State: AODbwcAh6aqFxA3tkdjqECneMjKhAUYKJHM1Hb8ntA/sfwAUDcqSDmIY hJsxJG4p71Y/8lercBFsnbv39jyZuQ== X-Received: by 10.237.55.193 with SMTP id j59mr121192qtb.238.1496302488886; Thu, 01 Jun 2017 00:34:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.4 with HTTP; Thu, 1 Jun 2017 00:34:08 -0700 (PDT) In-Reply-To: References: <3c5e78783f5ab589b74f3a5556df434e.squirrel@webmail.entel.upc.edu> From: Laurent Toutain Date: Thu, 1 Jun 2017 09:34:08 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carles Gomez Montenegro Cc: lp-wan , Alexander Pelov , Juan Carlos Zuniga Content-Type: multipart/alternative; boundary="001a113b0f9453c8db0550e112fc" Archived-At: Subject: Re: [lp-wan] Window mode as default fragmentation in SCHC + Minutes from Interim on 24/05 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 07:34:57 -0000 --001a113b0f9453c8db0550e112fc Content-Type: text/plain; charset="UTF-8" good point Laurent On Thu, Jun 1, 2017 at 9:27 AM, Carles Gomez Montenegro < carlesgo@entel.upc.edu> wrote: > ... and here are the slides I promised: > https://www.dropbox.com/s/40opp6d2bx6nt9p/Overhead%20analysis.pdf?dl=0 > > Note that as suggested in recent discussions, for Window mode, it is > possible to define use of a CFN size (i.e. N) one bit greater than the > maximum one we are currently considering. The latter is given by > floor[log_2(L2_MTU+1)], with L2_MTU expressed in bits. > > The "trick" is to support a bitmap size lower than 2^N bits. > > For example, for fragmented IPv6 packet transmission in Sigfox uplink, N=6 > can be used. However, the maximum bitmap size would be 56 bits, assuming > an 8-bit ACK header, since the downlink L2 MTU is 64 bits. > > This technique, which should be explicitly described in the draft, allows > to further reduce the ACK overhead in Window mode (e.g. one ACK every 56 > fragments, in the above example, for a large enough IPv6 packet). > > Cheers, > > Carles > > > > Hi, > > > > I also agree. > > > > After looking carefully at evaluation results [1], an overall conclusion > > is that it is possible to configure the window size to have low ACK > > overhead at a reasonably low cost in terms of fragmentation header size > > (and number of fragments for a given IPv6 packet size). > > > > Supporting more than one window size (e.g. advertised by means of a > > corresponding Rule ID), when possible, is a further interesting feature > > for performance improvement. > > > > On the other hand, I think we need more time to better analyze the > > different proposals for Packet mode, so working on it in a different > > document will allow for a longer term effort. > > > > Cheers, > > > > Carles > > > > [1] I will soon share some slides on this... > > > > > > > > > > > > > >> Hi Alex, > >> > >> I agree that the window mode provides enough support and flexibility for > >> the basic use cases. The more advanced fragmentation mechanisms to be > >> defined later on can be easily supported and communicated with Rule IDs, > >> as you mention. > >> > >> +1 for Window as default fragmentation mode. > >> > >> Best, > >> > >> Juan Carlos > >> > >>> -----Original Message----- > >>> From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Alexander > >>> Pelov > >>> Sent: May 29, 2017 12:34 PM > >>> To: lp-wan > >>> Subject: [lp-wan] Window mode as default fragmentation in SCHC + > >>> Minutes > >>> from Interim on 24/05 > >>> > >>> Dear all, > >>> > >>> The minutes from the last interim meeting have been uploaded and can be > >>> found at the following address: > >>> https://www.ietf.org/proceedings/interim- > >>> 2017-lpwan-03/minutes/minutes-interim-2017-lpwan-03-201705241600-00 > >>> > >>> One of the main topics that were discussed was the advancement of the > >>> fragmentation part of the IP/UDP SCHC document ( > >>> https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03 > >>> ). > >>> > >>> During the call we have reached a rough consensus that the Window mode > >>> covers all use-cases, is simple (from implementation and protocol point > >>> of > >>> view), is well understood, and can be included as a default mode for > >>> fragmentation in the RFC. > >>> > >>> We have also indicated that there are other ways of doing the > >>> fragmentation > >>> (most notably the Packet mode), but some corner cases still need to be > >>> covered > >>> (e.g. bitmap sizes bigger than available payload limiting the MTU to > >>> less than > >>> 1280), and some advanced ways of actually solving this (Bloom filters > >>> were > >>> mentioned I think). These are all interesting ideas and they merit a > >>> longer > >>> discussion to find the right balance. These are to be kept in a > >>> separate > >>> document, which can continue its life independently, and if the WG > >>> decides can > >>> be included as a future WG item. If a future devices implement these > >>> other > >>> fragmentation mechanisms, they will be perfectly compatible with the > >>> default > >>> Window mode (the Rule ID can indicate which fragmentation mode is > >>> used). > >>> > >>> We would like to confirm that you approve the Window mode as the > >>> default > >>> mode for fragmentation to be included in the SCHC IP/UDP document. > >>> > >>> Best, > >>> The chairs > >>> > >>> _______________________________________________ > >>> lp-wan mailing list > >>> lp-wan@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lp-wan > >> > >> _______________________________________________ > >> lp-wan mailing list > >> lp-wan@ietf.org > >> https://www.ietf.org/mailman/listinfo/lp-wan > >> > > > > > > _______________________________________________ > > lp-wan mailing list > > lp-wan@ietf.org > > https://www.ietf.org/mailman/listinfo/lp-wan > > > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > --001a113b0f9453c8db0550e112fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
good point

Laurent

On Thu, Jun 1, 2017 at 9:27= AM, Carles Gomez Montenegro <carlesgo@entel.upc.edu> w= rote:
... and here are the slides I promi= sed:
https://www.dropbox.com/s/40opp6d2bx6nt9p/Overhead%20analysis.pdf?dl=3D0

Note that as suggested in recent discussions, for Window mode, it is
possible to define use of a CFN size (i.e. N) one bit greater than the
maximum one we are currently considering. The latter is given by
floor[log_2(L2_MTU+1)], with L2_MTU expressed in bits.

The "trick" is to support a bitmap size lower than 2^N bits.

For example, for fragmented IPv6 packet transmission in Sigfox uplink, N=3D= 6
can be used. However, the maximum bitmap size would be 56 bits, assuming an 8-bit ACK header, since the downlink L2 MTU is 64 bits.

This technique, which should be explicitly described in the draft, allows to further reduce the ACK overhead in Window mode (e.g. one ACK every 56 fragments, in the above example, for a large enough IPv6 packet).

Cheers,

Carles


> Hi,
>
> I also agree.
>
> After looking carefully at evaluation results [1], an overall conclusi= on
> is that it is possible to configure the window size to have low ACK > overhead at a reasonably low cost in terms of fragmentation header siz= e
> (and number of fragments for a given IPv6 packet size).
>
> Supporting more than one window size (e.g. advertised by means of a > corresponding Rule ID), when possible, is a further interesting featur= e
> for performance improvement.
>
> On the other hand, I think we need more time to better analyze the
> different proposals for Packet mode, so working on it in a different > document will allow for a longer term effort.
>
> Cheers,
>
> Carles
>
> [1] I will soon share some slides on this...
>
>
>
>
>
>
>> Hi Alex,
>>
>> I agree that the window mode provides enough support and flexibili= ty for
>> the basic use cases. The more advanced fragmentation mechanisms to= be
>> defined later on can be easily supported and communicated with Rul= e IDs,
>> as you mention.
>>
>> +1=C2=A0 =C2=A0 =C2=A0 =C2=A0for Window as default fragmentation m= ode.
>>
>> Best,
>>
>> Juan Carlos
>>
>>> -----Original Message-----
>>> From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Alexander
>>> Pelov
>>> Sent: May 29, 2017 12:34 PM
>>> To: lp-wan <lp-wan@ietf.= org>
>>> Subject: [lp-wan] Window mode as default fragmentation in SCHC= +
>>> Minutes
>>> from Interim on 24/05
>>>
>>> Dear all,
>>>
>>> The minutes from the last interim meeting have been uploaded a= nd can be
>>> found at the following address:
>>> https://www.ietf.org/proceedings/interim-=
>>> 2017-lpwan-03/minutes/minutes-interim-2017-lpwan-03-= 201705241600-00
>>>
>>> One of the main topics that were discussed was the advancement= of the
>>> fragmentation part of the IP/UDP SCHC document (
>>> https://tools.iet= f.org/html/draft-ietf-lpwan-ipv6-static-context-hc-03
>>> ).
>>>
>>> During the call we have reached a rough consensus that the Win= dow mode
>>> covers all use-cases, is simple (from implementation and proto= col point
>>> of
>>> view), is well understood, and can be included as a default mo= de for
>>> fragmentation in the RFC.
>>>
>>> We have also indicated that there are other ways of doing the<= br> >>> fragmentation
>>> (most notably the Packet mode), but some corner cases still ne= ed to be
>>> covered
>>> (e.g. bitmap sizes bigger than available payload limiting the = MTU to
>>> less than
>>> 1280), and some advanced ways of actually solving this (Bloom = filters
>>> were
>>> mentioned I think). These are all interesting ideas and they m= erit a
>>> longer
>>> discussion to find the right balance. These are to be kept in = a
>>> separate
>>> document, which can continue its life independently, and if th= e WG
>>> decides can
>>> be included as a future WG item. If a future devices implement= these
>>> other
>>> fragmentation mechanisms, they will be perfectly compatible wi= th the
>>> default
>>> Window mode (the Rule ID can indicate which fragmentation mode= is
>>> used).
>>>
>>> We would like to confirm that you approve the Window mode as t= he
>>> default
>>> mode for fragmentation to be included in the SCHC IP/UDP docum= ent.
>>>
>>> Best,
>>> The chairs
>>>
>>> _______________________________________________
>>> lp-wan mailing list
>>> lp-wan@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/lp-wan
>>
>> _______________________________________________
>> lp-wan mailing list
>> lp-wan@ietf.org
>> https://www.ietf.org/mailman/listinfo/lp-w= an
>>
>
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>


_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

--001a113b0f9453c8db0550e112fc-- From nobody Thu Jun 1 00:39:53 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F07129458; Thu, 1 Jun 2017 00:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 yeE4tF9u_V2F; Thu, 1 Jun 2017 00:39:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A42D129426; Thu, 1 Jun 2017 00:39:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4EB47BE2D; Thu, 1 Jun 2017 08:39:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqA7u35Lqg4d; Thu, 1 Jun 2017 08:39:47 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 72CB1BE2E; Thu, 1 Jun 2017 08:39:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1496302786; bh=XyDU1+tq9uij3xRda4A3w/zl7nbcE8UG5e89xGRxUKA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VCYI1dNz6wjRJlV26e6RXeZOWl3nLyUeCJ88FxPnm7f9ATqyZgDf/ZmhGlO4y6WsS qa3nwYf1EkI0etvZu39pQaKHU5ZMZPzoWHxQBg9r8cKRUZFMfRniSURNefvZI/DoFg 6PFhjmfZe2QiyTv5dXMPD+KTDUHkW/hKAJlTS6fI= To: Alexander Pelov , lp-wan Cc: Core References: <58E6D5AA-1F9D-4455-9D64-C59CCFF5E7B3@ackl.io> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 1 Jun 2017 08:39:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <58E6D5AA-1F9D-4455-9D64-C59CCFF5E7B3@ackl.io> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qRG0aTFuik7rFwjWQF1TuE2u4wIgGCa6J" Archived-At: Subject: Re: [lp-wan] Agenda for LPWAN interim meeting next Wednesday, June 7th X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 07:39:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qRG0aTFuik7rFwjWQF1TuE2u4wIgGCa6J Content-Type: multipart/mixed; boundary="Bw1NaNhee35nNGilX5X1fPBkp7GJNm4xi"; protected-headers="v1" From: Stephen Farrell To: Alexander Pelov , lp-wan Cc: Core Message-ID: Subject: Re: [lp-wan] Agenda for LPWAN interim meeting next Wednesday, June 7th References: <58E6D5AA-1F9D-4455-9D64-C59CCFF5E7B3@ackl.io> In-Reply-To: <58E6D5AA-1F9D-4455-9D64-C59CCFF5E7B3@ackl.io> --Bw1NaNhee35nNGilX5X1fPBkp7GJNm4xi Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, I don't really have any items to discuss about the overview draft unless someone else does (in which case raising those on the list beforehand would be good). The only outstanding item wrt that afaik is for the chairs to figure out if you think it's ready for WGLC or what. If you're happy that it is, then saying so on the list and just starting that would seem like a fine plan. If there are issues though, please let me know and I can try address 'em without having to sit through a phone call (you can tell that phone calls aren't my fav things I guess:-) Cheers, S. On 31/05/17 18:04, Alexander Pelov wrote: > Dear all, >=20 > You=E2=80=99ll find the updated agenda at the following address: https:= //datatracker.ietf.org/doc/agenda-interim-2017-lpwan-04-lpwan-01/ >=20 > We=E2=80=99re nearing the finalization of the LPWAN Overview and the IP= /UDP SCHC document. >=20 > The CoAP SCHC document is also on track to be completed in the followin= g month. (thus CCing CORE) >=20 > Best, > The Chairs of LPWAN=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >=20 --Bw1NaNhee35nNGilX5X1fPBkp7GJNm4xi-- --qRG0aTFuik7rFwjWQF1TuE2u4wIgGCa6J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZL8TBAAoJEC88hzaAX42iqvEH/1wMQALiLngdj4Dq7OcpMEax DNsQQDss6PtlpaLLzCCKwL2B3OcSPepU6wixTDT2xlJgOaQ0xIgIQpGEbCtkidqX 3m2SU5x/f1TabTKP0Q8drGohrGB36KhDNDGGYJgzy+oYNjuw3aEWt90zLk0axlmz Ox7jUeGSftDBjUBb1JsQPGJ2+awL75xlKSGQyG8rIQxg6S5CLF+U0vgfbcoVQc3/ 7zW0cpwQKcwyM5MlK7OKvrx0LGSnOy396n1yjY3qNWd1+JVH/7qN3JSI/QTmH6w5 9GHkxq3rrrrpVxPHG6qphtz8QVIS057Z00VaWxPgMP+ro3bA/PRGxRD/28/OQlg= =AiCZ -----END PGP SIGNATURE----- --qRG0aTFuik7rFwjWQF1TuE2u4wIgGCa6J-- From nobody Thu Jun 1 06:32:38 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1F12EBEB for ; Thu, 1 Jun 2017 06:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WRDEXjnclXDM for ; Thu, 1 Jun 2017 06:32:33 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D1612EBD3 for ; Thu, 1 Jun 2017 06:32:32 -0700 (PDT) Received: from 2a01cb088947ca00f0a676c0445dd7e1.ipv6.abo.wanadoo.fr (2a01cb088947ca00f0a676c0445dd7e1.ipv6.abo.wanadoo.fr [IPv6:2a01:cb08:8947:ca00:f0a6:76c0:445d:d7e1]) (Authenticated sender: ana@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id A85A9A80F9; Thu, 1 Jun 2017 15:32:30 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8E56D89F-7D00-4EC8-941E-8A9095A207D9" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ana Minaburo In-Reply-To: Date: Thu, 1 Jun 2017 15:32:29 +0200 Cc: lp-wan Message-Id: <48665FB1-5708-4B10-ADF7-CE09D3BEAB66@ackl.io> References: To: Juan Carlos Zuniga X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lp-wan] Review of draft-ietf-lpwan-ipv6-static-context-hc-03 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 13:32:37 -0000 --Apple-Mail=_8E56D89F-7D00-4EC8-941E-8A9095A207D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, Thanks for your comments, I=E2=80=99m doing my best to get them ready = for the end of the week, but I would like to put in a discussion that = seems to me very important after reading your comments, After reading that you want to change the name of the DEV-iid and the = APP-iid is that perhaps is not clear that this two = Compression/Decompression Actions were created specifically to compress = the IPv6 address, so we use the IPv6 terminology (prefix and interface = identifier) in order that everybody at IETF recognises that we are = compressing the IPv6@-iid and knows which part of the header is = compressed. I=E2=80=99m not agree with your modifications about this = part because this could create ambiguity in the use of this CDAs, why = not used them for other fields whereas they were only created for L3 = addresses? I would like to know which is the feeling of the ML in order = to make this change. Thanks Ana > On 30 May 2017, at 22:25, Juan Carlos Zuniga = wrote: >=20 > Hello, > =20 > Below are my comments on draft-ietf-lpwan-ipv6-static-context-hc-03: > =20 > General: > =20 > - Throughout the document it is mentioned that this is a = =E2=80=9Cheader=E2=80=9D compression mechanism. > However, in some cases the baseline principles can also be applied to = packet payloads. For that reason, I suggest removing =E2=80=9Cheader=E2=80= =9D from all instances in sentences that are not specific to the header = itself, like the abstract and the introduction, e.g. =E2=80=9CThis = document describes a header compression scheme and fragmentation = functionality for IPv6/UDP protocols.=E2=80=9D > =20 > Editorial/Technical: > =20 > - Section 2: =20 > o Rule ID: An identifier for a rule, SCHC C/D and DEV share the same = rule ID for a specific flow. > =C2=A7 Remove: Rule ID is sent on the LPWAN. > o Add Field Identifier (FID) definition > o Add IID, DEV ID, and APP ID definitions (for these two latter, = please see comments on sections 6 and 7 below) > - Section 3:=20 > o ROHC: Add reference to RFC 5795 > o =E2=80=9CThe context must be stored in both ends. It can also be = learned by using a provisionning protocol that is out of the scope of = this draft.=E2=80=9D > =C2=A7 Change to >> The context must be stored in both ends, and it = can either be leaned by a provisioning protocol, by out of band means, = it can be pre-provisioned, etc. The way the context is learned on both = sides is out of scope of this document. > o The principle is the same in the other direction. > =C2=A7 Change to >> The SCHC process is bidirectional, so the same = principles can be applied in the other direction > o Add a new subsection header (e.g. 3.1) called =E2=80=9CSCHC = Rules=E2=80=9D before the following paragraph: > =C2=A7 =E2=80=9CThe context contains a list of rules...=E2=80=9D > o Move the following paragraph to the beginning of the proposed new = subsection 3.1: > =C2=A7 =E2=80=9CThe main idea of the compression scheme...=E2=80=9D > - Current section 3.2 Packet processing: > o =E2=80=9Ccompression rule selection: the goal is to identify which = rule(s)will be used to compress the headers. Each field is associated to = a matching operator for compression. Each header field=E2=80=99s value = is compared to the corresponding target value stored in the rule for = that field using the matching operator. If all the fields in the = packet=E2=80=99s header satisfied all the matching operators of a rule, = the packet is processed using Compression Decompression Function = associated with the fields. Otherwise the next rule is tested. If no = eligible rule is found, then the packet is sent without compression, = which may require using the fragmentation procedure.=E2=80=9D > =C2=A7 Change to >> =E2=80=9Ccompression rule selection: the goal is = to identify which rule(s) will be used to compress the packet. Fields = are first identified according to their field identifier (FID), field = position (FP) and direction indicator (DI). Each field=E2=80=99s value = is then compared to the corresponding target value (TV) stored in the = rule for that specific field using the matching operator (MO). If all = the fields in the packet satisfy all the matching operators (MOs) of a = rule (i.e. all results are True), the fields of the packet are then = processed according to the Compression Decompression Actions (CDAs) and = a compressed packet is obtained. Otherwise the next rule is tested. If = no eligible rule is found, then the packet must be sent without = compression, in which case the fragmentation process may be required.=E2=80= =9D > o Not sure why the following sentence was added from rev 02 to rev = 03: =E2=80=9CIn the downstrean direction, the rule is also used to find = the device ID. =E2=80=9D > =C2=A7 Should probably remove the sentence, as it looks out of place.=20= > =C2=A7 Also, isn=E2=80=99t it that in DL first the DEV ID is used to = know the rule, as the same rule ID can be used to identify different = rules for different devices? > o =E2=80=9Csending: The rule ID is sent to the other end followed by = information resulting from the compression of header fields. This = information is sent in the order expressed in the rule for the matching = fields. The way the rule ID is sent depends on the layer two technology = and will be specified in a specific document. For example, it can = either be included in a Layer 2 header or sent in the first byte of the = L2 payload. (cf. Figure 3) > =C2=A7 Change to >> =E2=80=9Csending: The rule ID is sent to the = other end followed by information resulting from the compression of the = packet=E2=80=99s fields. This information is sent in the order = expressed in the rule for the matching fields. The way the rule ID is = sent depends on the specific LPWAN technology and will be specified in a = specific document. For example, it can either be included in a Layer 2 = header or sent in the first byte of the L2 payload. (cf. Figure 3) > o =E2=80=9Cdecompression: The receiver identifies the sender through = its device-id (e.g. MAC address) and selects the appropriate rule = through the rule ID. This rule gives the compressed header format and = associates these values to header fields. It applies the CDA action to = reconstruct the original header fields. The CDA order can be different = of the order given by the rule. For instance Compute-* may be applied = after the other CDAs. > =C2=A7 Change to >> =E2=80=9Cdecompression: In the upstream = direction, the receiver first identifies the sender through its device = identifier (DID) and selects the appropriate rule through the rule ID. = This rule gives the compressed header format and associates these values = to header fields. It applies the CDA action to reconstruct the original = header fields. The CDA order can be different of the order given by the = rule. For instance Compute-* may be applied after the other CDAs.=E2=80=9D= > - Section 4 > o =E2=80=9CThis document describes basic matching operators (MO)s = which must be known by both SCHC C/D, endpoints involved in the header = compression/decompression. They are not typed and can be applied = indifferently to integer, string or any other type. The MOs and their = definitions are provided next:=E2=80=9D > =C2=A7 Change to >> =E2=80=9CMatching operators (MOs) are functions = used by both SCHC C/D endpoints involved in the header = compression/decompression. They are not typed and can be applied = indifferently to integer, string or any other data type. The result of = the operation can either be True or False. MOs are defined as = follows:=E2=80=9D > o =E2=80=9Cequal: a field value in a packet matches with a field = value in a rule if they are equal.=E2=80=9D > =C2=A7 Change to>> =E2=80=9Cequal: a field value in a packet matches = with a TV in a rule if they are equal.=E2=80=9D > o =E2=80=9CMSB(length): a field value of a size equal to "length" = bits in a packet matches with a field value in a rule if the most = significant "length" bits are equal.=E2=80=9D > =C2=A7 Change to>> =E2=80=9CMSB (length): a matching is obtained if = the most significant bits of the length field value of the packet are = equal to the TV in the rule.=E2=80=9D > - Section 5 > o In figure 4 (should probably be called table instead of figure), = change the following Action: > =C2=A7 LSB(length)|send LSB|ctxt value OR rcvd value >> = LSB(length)|send LSB|TV (OR) received value > o In 5.4: =E2=80=9CLSB action is used to send a fixed part of the = packet field header to the other end.=E2=80=9D > =C2=A7 Change to>> =E2=80=9CLSB action is used to avoid sending the = fixed part of the packet field to the other end.=E2=80=9D > o 5.5. DEViid-DID, APPiid-DID CDA:=20 > =C2=A7 =E2=80=9CThese functions are used to process respectively the = Device and the Application Device Identifier (DID). APPiid-DID CDA is = less common, since current LPWAN technologies frames contain a single = address. > =C2=A7 The IID value is computed from the Device ID present in the = Layer 2 header. The computation depends on the technology and the = Device ID size. > =C2=A7 In the downstream direction, these CDA are used to determine = the L2 addresses used by the LPWAN.=E2=80=9D > =C2=A7 Change to>> DEV ID, APP ID CDAs: > =C2=A7 =E2=80=9CThese functions are used to process the DEV and the = APP Identifiers. The value can be computed from the Device ID present = in the Layer 2 header. The computation is specific for each LPWAN = technology and depends on the Device ID size. > o In 5.6 =E2=80=93 Add new subsections (5.6.1 and 5.6.2) to the = compute-length and compute-checksum function paragraph descriptions, = respectively > - Section 6 > o 6.2: wellknown >> well-known > o 6.3: dpending >> depending > o 6.7.2 IPv6 source and destination IID: =E2=80=9CIf the DEV or APP = IID are based on an LPWAN address, then the IID can be reconstructed = with information coming from the LPWAN header. In that case, the TV is = not set, the MO is set to "ignore" and the CDA is set to "DEViid-DID" or = "APPiid-DID". Note that the LPWAN technology is generally carrying a = single device identifier corresponding to the DEV.=E2=80=9D > o Change to>> =E2=80=9CIf the DEV or APP IID are based on an LPWAN = address, then the IID can be reconstructed with information coming from = the LPWAN header. In that case, the TV is not set, the MO is set to = "ignore" and the CDA is set to "DEV IID" or "APP IID". Note that the = LPWAN technology is generally carrying a single device identifier = corresponding to the DEV.=E2=80=9D > o The following paragraph is contradictory:=20 > =C2=A7 For privacy reasons or if the DEV address is changing over = time, it maybe better to use a static value. In that case, the TV = contains the value, the MO operator is set to "equal" and the CDA is set = to "not-sent". > =C2=A7 If we are adding privacy features, the use of long-lasting = identifiers should be avoided. It is not clear if in this case it is the = source or the destination (compressor or decompressor) that is in charge = of changing the identity, and what effect does this have on the CDA. > - Section 7 > o Figure 6: Context rules (and rest of section 7) > =C2=A7 Change all instances of =E2=80=9CDEViid-DID=E2=80=9D >> =E2=80=9C= DEV IID=E2=80=9D > o Remove the following sentence: =E2=80=9CThe DEViid-DID value is = found in the L2 header.=E2=80=9D > =20 > =20 > For comments on Section 8 onwards, I will wait for a new revision of = the draft incorporating the potential changes to come after the latest = discussions about the fragmentation modes. > =20 > Best, > =20 > Juan Carlos=20 > =20 > =20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan = --Apple-Mail=_8E56D89F-7D00-4EC8-941E-8A9095A207D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

Thanks for your comments, I=E2=80=99m doing my best to get = them ready for the end of the week, but I would like to put in a = discussion that = seems to me very important after reading your comments,

After reading that you want to change the name of the DEV-iid = and the APP-iid is that perhaps is not clear that this two = Compression/Decompression Actions were created specifically to compress = the IPv6 address, so we use the IPv6 terminology (prefix and interface = identifier) in order that everybody at IETF recognises that we are = compressing the IPv6@-iid and knows which part of the header is = compressed. I=E2=80=99m not agree with your modifications about this = part because this could create ambiguity in the use of this CDAs, why = not used them for other fields whereas they were only created for L3 = addresses? I would like to know which is the feeling of the ML in order = to make this change.


Thanks
Ana


On 30 May 2017, at 22:25, Juan = Carlos Zuniga <juancarlos.zuniga@sigfox.com> wrote:

Hello,
 
Below are = my comments on draft-ietf-lpwan-ipv6-static-context-hc-03:
 
General:
 
-          Throughout = the document it is mentioned that this is a =E2=80=9Cheader=E2=80=9D = compression mechanism.
However, in some cases the = baseline principles can also be applied to packet payloads. For that = reason, I suggest removing =E2=80=9Cheader=E2=80=9D from all instances = in sentences that are not specific to the header itself, like the = abstract and the introduction, e.g. =E2=80=9CThis document describes a header compression scheme and = fragmentation functionality for IPv6/UDP protocols.=E2=80=9D
 
Editorial/Technical:
 
-          Section 2: =  
o   Rule ID: An = identifier for a rule, SCHC C/D and DEV share the same rule ID for a = specific flow.
=C2=A7  Remove: Rule ID is = sent on the LPWAN.
o   Add = Field Identifier (FID) definition
o   Add = IID, DEV ID, and APP ID definitions (for these two latter, please see = comments on sections 6 and 7 below)
-          Section = 3: 
o   ROHC: = Add reference to RFC 5795
o   =E2=80=9C= The context must be stored in both ends. It can also be learned by using = a provisionning protocol that is out of the scope of this draft.=E2=80=9D<= o:p class=3D"">
=C2=A7  Change to >> The = context must be stored in both ends, and it can either be leaned = by a provisioning protocol, by out of band means, it can be = pre-provisioned, etc. The way the context is learned on both sides is = out of scope of this document.
o   The = principle is the same in the other direction.
=C2=A7  Change to >> The SCHC process is bidirectional, so the same principles can = be applied in the other direction
o   Add a new subsection header (e.g. 3.1) called = =E2=80=9CSCHC Rules=E2=80=9D before the following paragraph:
=C2=A7  =
=E2=80=9CThe context =
contains a list of rules...=E2=80=9D
o   Move = the following paragraph to the beginning of the proposed new subsection = 3.1:
=C2=A7  =
=E2=80=9CThe main idea =
of the compression scheme...=E2=80=9D
-          =
Current section 3.2 Packet =
processing:
o   =E2=80=9Ccompr= ession rule selection: the goal is to identify which rule(s)will be used = to compress the headers. Each field is associated to a matching operator = for compression. Each header field=E2=80=99s value is compared to the = corresponding target value stored in the rule for that field using the = matching operator. If all the fields in the packet=E2=80=99s header = satisfied all the matching operators of a rule, the packet is processed = using Compression Decompression Function associated with the fields. = Otherwise the next rule is tested. If no eligible rule is found, then = the packet is sent without compression, which may require using the = fragmentation procedure.=E2=80=9D
=C2=A7  Change to >> = =E2=80=9Ccompression rule selection: the goal is to identify which = rule(s) will be used to compress the packet. Fields are first identified = according to their field identifier (FID), field position (FP) and = direction indicator (DI). Each field=E2=80=99s value is then compared to = the corresponding target value (TV) stored in the rule for that specific = field using the matching operator (MO). If all the fields in the packet = satisfy all the matching operators (MOs) of a rule (i.e. all results are = True), the fields of the packet are then processed according to the = Compression Decompression Actions (CDAs) and a compressed packet is = obtained. Otherwise the next rule is tested. If no eligible rule is = found, then the packet must be sent without compression, in which case = the fragmentation process may be required.=E2=80=9D
o   =
Not sure why the following sentence was =
added from rev 02 to rev 03: =E2=80=9CI=
n the downstrean direction, the rule is also used to find the device ID. =
=E2=80=9D
=C2=A7  =
Should probably remove =
the sentence, as it looks out of place. 
=C2=A7  =
Also, isn=E2=80=99t it =
that in DL first the DEV ID is used to know the rule, as the same rule =
ID can be used to identify different rules for different devices?
o   =E2=80=9Csending: The rule ID is sent to the other end =
followed by information resulting from the compression of header =
fields.  This information is sent in the order expressed in the =
rule for the matching fields.  The way the rule ID is sent depends =
on the layer two technology and will be specified in a specific =
document.  For example, it can either be included in a Layer 2 =
header or sent in the first byte of the L2 payload. (cf.  Figure =
3)
=C2=A7  =
Change to >> =E2=80=9Csending: The rule ID is sent to the other =
end followed by information resulting from the compression of the =
packet=E2=80=99s fields.  This information is sent in the order =
expressed in the rule for the matching fields.  The way the rule ID =
is sent depends on the specific LPWAN technology and will be specified =
in a specific document.  For example, it can either be included in =
a Layer 2 header or sent in the first byte of the L2 payload. (cf.  =
Figure 3)
o   =
=E2=80=9Cdecompression: =
The receiver identifies the sender through its device-id (e.g.  MAC =
address) and selects the appropriate rule through the rule ID. This rule =
gives the compressed header format and associates these values to header =
fields.  It applies the CDA action to reconstruct the original =
header fields.  The CDA order can be different of the order given =
by the rule.  For instance Compute-* may be applied after the other =
CDAs.
=C2=A7  =
Change to >> =E2=80=9Cdecompression: In the upstream direction, =
the receiver first identifies the sender through its device identifier =
(DID) and selects the appropriate rule through the rule ID. This rule =
gives the compressed header format and associates these values to header =
fields.  It applies the CDA action to reconstruct the original =
header fields.  The CDA order can be different of the order given =
by the rule.  For instance Compute-* may be applied after the other =
CDAs.=E2=80=9D
-         =
 Section 4
o   =E2=80=9CThis document describes basic matching operators =
(MO)s which must be known by both SCHC C/D, endpoints involved in the =
header compression/decompression.  They are not typed and can be =
applied indifferently to integer, string or any other type.  The =
MOs and their definitions are provided next:=E2=80=9D
=C2=A7  =
Change to >> =E2=80=9CMatching operators (MOs) are functions used =
by both SCHC C/D endpoints involved in the header =
compression/decompression.  They are not typed and can be applied =
indifferently to integer, string or any other data type.  The =
result of the operation can either be True or False. MOs are defined as =
follows:=E2=80=9D
o   =
=E2=80=9Cequal: a field =
value in a packet matches with a field value in a rule if they are =
equal.=E2=80=9D
=C2=A7  =
Change to>> =E2=80=9Cequal: a field value in a packet matches =
with a TV in a rule if they are equal.=E2=80=9D
o   =E2=80=9CMSB(length): a field value of a size equal to =
"length" bits in a packet matches with a field value in a rule if the =
most significant "length" bits are equal.=E2=80=9D
=C2=A7  =
Change to>> =E2=80=9CMSB (length): a matching is obtained if the =
most significant bits of the length field value of the packet are equal =
to the TV in the rule.=E2=80=9D
-          =
Section 5
o   In figure 4 (should probably be called table instead of =
figure), change the following Action:
=C2=A7  =
LSB(length)|send =
LSB|ctxt value OR rcvd value  >>  LSB(length)|send =
LSB|TV (OR) received value
o   In 5.4: =E2=80=9CLSB action is used to send a fixed part of =
the packet field header to the other end.=E2=80=9D
=C2=A7  =
Change to>> =E2=80=9CLSB action is used to avoid sending the =
fixed part of the packet field to the other end.=E2=80=9D
o   5.5.  DEViid-DID, APPiid-DID CDA: 
=C2=A7  =
=E2=80=9CThese =
functions are used to process respectively the Device and the =
Application Device Identifier (DID).  APPiid-DID CDA is less =
common, since current LPWAN technologies frames contain a single =
address.
=C2=A7  =
The IID value is =
computed from the Device ID present in the Layer 2 header.  The =
computation depends on the technology and the Device ID size.
=C2=A7  =
In the downstream =
direction, these CDA are used to determine the L2 addresses used by the =
LPWAN.=E2=80=9D
=C2=A7  =
Change to>> DEV ID, APP ID CDAs:
=C2=A7  =
=E2=80=9CThese =
functions are used to process the DEV and the APP Identifiers.  The =
value can be computed from the Device ID present in the Layer 2 =
header.  The computation is specific for each LPWAN technology and =
depends on the Device ID size.
o   In 5.6 =E2=80=93 Add new subsections (5.6.1 and 5.6.2) to the =
compute-length and compute-checksum function paragraph descriptions, =
respectively
-         =
 Section 6
o   6.2: wellknown >> well-known
o   6.3: dpending >> depending
o   6.7.2 IPv6 source and destination IID: =E2=80=9CIf the DEV or =
APP IID are based on an LPWAN address, then the IID can be reconstructed =
with information coming from the LPWAN header.  In that case, the =
TV is not set, the MO is set to "ignore" and the CDA is set to =
"DEViid-DID" or "APPiid-DID".  Note that the LPWAN technology is =
generally carrying a single device identifier corresponding to the =
DEV.=E2=80=9D
o   =
Change to>> =E2=80=9CIf the DEV or APP IID are based on an LPWAN =
address, then the IID can be reconstructed with information coming from =
the LPWAN header.  In that case, the TV is not set, the MO is set =
to "ignore" and the CDA is set to "DEV IID" or "APP IID".  Note =
that the LPWAN technology is generally carrying a single device =
identifier corresponding to the DEV.=E2=80=9D
o   The following paragraph is contradictory: 
=C2=A7  =
For privacy reasons or =
if the DEV address is changing over time, it maybe better to use a =
static value.  In that case, the TV contains the value, the MO =
operator is set to "equal" and the CDA is set to "not-sent".
=C2=A7  =
If we are adding privacy features, the =
use of long-lasting identifiers should be avoided. It is not clear if in =
this case it is the source or the destination (compressor or =
decompressor) that is in charge of changing the identity, and what =
effect does this have on the CDA.
-          =
Section 7
o   Figure 6: Context rules (and rest of section 7)
=C2=A7  =
Change all instances of =
=E2=80=9CDEViid-DID=E2=80=9D >> =E2=80=9CDEV IID=E2=80=9D
o   Remove the following sentence: =E2=80=9CThe DEViid-DID value =
is found in the L2 header.=E2=80=9D
 
 
For comments on Section 8 onwards, I =
will wait for a new revision of the draft incorporating the potential =
changes to come after the latest discussions about the fragmentation =
modes.
 
Best,
 
Juan Carlos 
 
 
_______________________________________________
lp-wan mailing = list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

= --Apple-Mail=_8E56D89F-7D00-4EC8-941E-8A9095A207D9-- From nobody Fri Jun 2 05:49:11 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8E312EB5E for ; Fri, 2 Jun 2017 05:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 1E525KqLp3Ie for ; Fri, 2 Jun 2017 05:49:06 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10111.outbound.protection.outlook.com [40.107.1.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2700612E042 for ; Fri, 2 Jun 2017 05:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GAjHiKvmkGCDoz04U/bRBRsAMRZKvTpRQI+7cSBgYXE=; b=oeNn8DuHPmpGTYlzcVAIBjEhZieLqs32ohmOeexGiIYbHKhhgJ2VnZ7cVdnUIKry5Vd9fN9BGrFR8ErFBmB8Ikax3MZz/NVy969BxYYk+V8hTYcfXSA50Nw67p+A2PwR3F+N2pDzEzwbH05Sw3i/XnUGIw4gsAe5crCosbpWMB8= Received: from VI1PR08MB2688.eurprd08.prod.outlook.com (10.175.245.26) by VI1PR08MB2687.eurprd08.prod.outlook.com (10.175.245.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Fri, 2 Jun 2017 12:49:01 +0000 Received: from VI1PR08MB2688.eurprd08.prod.outlook.com ([fe80::ad6f:79cb:db32:9318]) by VI1PR08MB2688.eurprd08.prod.outlook.com ([fe80::ad6f:79cb:db32:9318%13]) with mapi id 15.01.1124.013; Fri, 2 Jun 2017 12:49:01 +0000 From: Juan Carlos Zuniga To: Ana Minaburo CC: lp-wan Thread-Topic: [lp-wan] Review of draft-ietf-lpwan-ipv6-static-context-hc-03 Thread-Index: AdLYtD5WSRWdUxCvTV+W5HdcWDFNlwCJ0VmAADCnlvA= Date: Fri, 2 Jun 2017 12:49:01 +0000 Message-ID: References: <48665FB1-5708-4B10-ADF7-CE09D3BEAB66@ackl.io> In-Reply-To: <48665FB1-5708-4B10-ADF7-CE09D3BEAB66@ackl.io> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ackl.io; dkim=none (message not signed) header.d=none;ackl.io; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [104.163.152.104] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR08MB2687; 7:XDF/ebGCBIFwlfR6gJUtZDmWt11bTAR0bLbjG9G83mfolo1hur5ADxebfN/zbp4SU00aiN1elh+jhroudQ29wFLq5RtF7iEatTdoQynBr2yk+Y4G7RmQ+Pyvh2/C+pPZL5UA+cPEe5X9goCc8KWr9vBeZVHT+8q7H170vXceJR8uJr9Lt7uUpfkQKSu3fT/gHXqUONZ8yI7x65JwBwHNNLkSqD+lhRORVp6f1ubetrUm7SbiSx2ibLl8vVbzy/MP3P3wIjUCrLU4oEbagocCzTETZupoEo5d+6174sdrHozsQQvtXhV3M2ASITVaLv43I3m4Np4YQ+9RpPTZNtTmDw== x-ms-traffictypediagnostic: VI1PR08MB2687: x-ms-office365-filtering-correlation-id: 9fa904af-6a0c-497f-1afc-08d4a9b5beab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR08MB2687; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR08MB2687; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR08MB2687; x-forefront-prvs: 03264AEA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39400400002)(39410400002)(39830400002)(39450400003)(377454003)(24454002)(50986999)(6246003)(236005)(76176999)(3660700001)(53546009)(9326002)(110136004)(7906003)(478600001)(53936002)(38730400002)(606005)(54356999)(6306002)(14454004)(74316002)(55016002)(54896002)(99286003)(9686003)(2906002)(2900100001)(8676002)(33656002)(6506006)(53946003)(229853002)(25786009)(3280700002)(81166006)(4326008)(6436002)(2950100002)(966005)(7736002)(230783001)(8936002)(66066001)(5250100002)(790700001)(7696004)(5660300001)(6916009)(86362001)(6116002)(189998001)(3846002)(102836003)(557034004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR08MB2687; H:VI1PR08MB2688.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR08MB26882BAC525B63E4346EFDC789F70VI1PR08MB2688eurp_" MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2017 12:49:01.6954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2687 Archived-At: Subject: Re: [lp-wan] Review of draft-ietf-lpwan-ipv6-static-context-hc-03 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 12:49:10 -0000 --_000_VI1PR08MB26882BAC525B63E4346EFDC789F70VI1PR08MB2688eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5hLA0KDQpUcnVlLCBJIHNob3VsZCBoYXZlIHNlbnQgc29tZSByZWFzb25pbmcgZm9yIG15 IGNvbW1lbnRzIG9uIERFViBhbmQgQVBQIElELg0KDQpJIGFncmVlIHRoYXQgdGhlIGRvY3VtZW50 IHNob3VsZCBmb2N1cyBvbiBJUHY2IGFuZCBVRFAgaGVhZGVyIGNvbXByZXNzaW9uLiBIb3dldmVy LCBJIHRoaW5rIHdlIG5lZWQgdG8gY2xhcmlmeSB0aGUgd2F5IHRoZSBJUHY2IGFkZHJlc3MgaXMg Y2FycmllZC9nZW5lcmF0ZWQuIElmIHdlIGFyZSB1c2luZyBzdGF0aWMgYWRkcmVzcyBhdXRvY29u ZmlndXJhdGlvbiAoU0xBQUMpLCB0aGVuIHRoZXJlIGFyZSBzb21lIHByaXZhY3kgY29uc2lkZXJh dGlvbnMgd2UgbmVlZCB0byB0YWtlIGludG8gYWNjb3VudCB0byBkZXJpdmUgdGhlIElQdjYgSUlE IChzZWUgUkZDIDcyMTcpLg0KDQpCZWNhdXNlIHdlIG1heSB3YW50IHRvIHN1cHBvcnQgZGlmZmVy ZW50IHdheXMgdG8gZ2VuZXJhdGUgdGhlIElJRCwgSSB0aGluayBpdCBpcyBlYXNpZXIgaWYgd2Ug ZGVmaW5lIGluIFNlY3Rpb24gNSBhbiBBY3Rpb24gKENEQSkgdGhhdCBjYW4gYmUgYXBwbGllZCBv biB0aGUgREVWIElELCBhbmQgdGhlbiBpbiBTZWN0aW9uIDYgd2UgY2FuIGV4cGxhaW4gdGhhdCB0 aGVyZSBhcmUgZGlmZmVyZW50IHdheXMgdG8gZGVyaXZlIHRoZSBJUHY2IElJRC4gT25lIG9mIHRo ZW0gaXMgaW5kZWVkIGZyb20gdGhlIERFViBJRCwgYnV0IHRoZXJlIGNvdWxkIGJlIG90aGVyIHdh eXMgKGUuZy4gUkZDIDcyMTcpLiBCeSBkb2luZyB0aGlzIHNlcGFyYXRpb24gSSB0aGluayB3ZSBh bHNvIHByb3ZpZGUgZmxleGliaWxpdHkgdG8gcHJvdmlkZSBwcml2YWN5IGZlYXR1cmVzIGF0IHRo ZSBTQ0hDIGRlY29tcHJlc3NvciwgZXZlbiBmb3IgbG93IGVuZCBkZXZpY2VzIChlLmcuIGxlZ2Fj eSkgdGhhdCBtYXkgbm90IGltcGxlbWVudCB0aGUgZnVsbCBJUCBzdGFjay4NCg0KQmVzdCwNCg0K SnVhbiBDYXJsb3MNCg0KDQpGcm9tOiBscC13YW4gW21haWx0bzpscC13YW4tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEFuYSBNaW5hYnVybw0KU2VudDogSnVuZSAxLCAyMDE3IDk6MzIg QU0NClRvOiBKdWFuIENhcmxvcyBadW5pZ2EgPGp1YW5jYXJsb3MuenVuaWdhQHNpZ2ZveC5jb20+ DQpDYzogbHAtd2FuIDxscC13YW5AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xwLXdhbl0gUmV2 aWV3IG9mIGRyYWZ0LWlldGYtbHB3YW4taXB2Ni1zdGF0aWMtY29udGV4dC1oYy0wMw0KDQpIZWxs bywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBJ4oCZbSBkb2luZyBteSBiZXN0IHRvIGdl dCB0aGVtIHJlYWR5IGZvciB0aGUgZW5kIG9mIHRoZSB3ZWVrLCBidXQgSSB3b3VsZCBsaWtlIHRv IHB1dCBpbiBhIGRpc2N1c3Npb24gdGhhdCBzZWVtcyB0byBtZSB2ZXJ5IGltcG9ydGFudCBhZnRl ciByZWFkaW5nIHlvdXIgY29tbWVudHMsDQoNCkFmdGVyIHJlYWRpbmcgdGhhdCB5b3Ugd2FudCB0 byBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIERFVi1paWQgYW5kIHRoZSBBUFAtaWlkIGlzIHRoYXQg cGVyaGFwcyBpcyBub3QgY2xlYXIgdGhhdCB0aGlzIHR3byBDb21wcmVzc2lvbi9EZWNvbXByZXNz aW9uIEFjdGlvbnMgd2VyZSBjcmVhdGVkIHNwZWNpZmljYWxseSB0byBjb21wcmVzcyB0aGUgSVB2 NiBhZGRyZXNzLCBzbyB3ZSB1c2UgdGhlIElQdjYgdGVybWlub2xvZ3kgKHByZWZpeCBhbmQgaW50 ZXJmYWNlIGlkZW50aWZpZXIpIGluIG9yZGVyIHRoYXQgZXZlcnlib2R5IGF0IElFVEYgcmVjb2du aXNlcyB0aGF0IHdlIGFyZSBjb21wcmVzc2luZyB0aGUgSVB2NkAtaWlkIGFuZCBrbm93cyB3aGlj aCBwYXJ0IG9mIHRoZSBoZWFkZXIgaXMgY29tcHJlc3NlZC4gSeKAmW0gbm90IGFncmVlIHdpdGgg eW91ciBtb2RpZmljYXRpb25zIGFib3V0IHRoaXMgcGFydCBiZWNhdXNlIHRoaXMgY291bGQgY3Jl YXRlIGFtYmlndWl0eSBpbiB0aGUgdXNlIG9mIHRoaXMgQ0RBcywgd2h5IG5vdCB1c2VkIHRoZW0g Zm9yIG90aGVyIGZpZWxkcyB3aGVyZWFzIHRoZXkgd2VyZSBvbmx5IGNyZWF0ZWQgZm9yIEwzIGFk ZHJlc3Nlcz8gSSB3b3VsZCBsaWtlIHRvIGtub3cgd2hpY2ggaXMgdGhlIGZlZWxpbmcgb2YgdGhl IE1MIGluIG9yZGVyIHRvIG1ha2UgdGhpcyBjaGFuZ2UuDQoNCg0KVGhhbmtzDQpBbmENCg0KDQpP biAzMCBNYXkgMjAxNywgYXQgMjI6MjUsIEp1YW4gQ2FybG9zIFp1bmlnYSA8anVhbmNhcmxvcy56 dW5pZ2FAc2lnZm94LmNvbTxtYWlsdG86anVhbmNhcmxvcy56dW5pZ2FAc2lnZm94LmNvbT4+IHdy b3RlOg0KDQpIZWxsbywNCg0KQmVsb3cgYXJlIG15IGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbHB3 YW4taXB2Ni1zdGF0aWMtY29udGV4dC1oYy0wMzoNCg0KR2VuZXJhbDoNCg0KLSAgICAgICAgICBU aHJvdWdob3V0IHRoZSBkb2N1bWVudCBpdCBpcyBtZW50aW9uZWQgdGhhdCB0aGlzIGlzIGEg4oCc aGVhZGVy4oCdIGNvbXByZXNzaW9uIG1lY2hhbmlzbS4NCkhvd2V2ZXIsIGluIHNvbWUgY2FzZXMg dGhlIGJhc2VsaW5lIHByaW5jaXBsZXMgY2FuIGFsc28gYmUgYXBwbGllZCB0byBwYWNrZXQgcGF5 bG9hZHMuIEZvciB0aGF0IHJlYXNvbiwgSSBzdWdnZXN0IHJlbW92aW5nIOKAnGhlYWRlcuKAnSBm cm9tIGFsbCBpbnN0YW5jZXMgaW4gc2VudGVuY2VzIHRoYXQgYXJlIG5vdCBzcGVjaWZpYyB0byB0 aGUgaGVhZGVyIGl0c2VsZiwgbGlrZSB0aGUgYWJzdHJhY3QgYW5kIHRoZSBpbnRyb2R1Y3Rpb24s IGUuZy4g4oCcVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBoZWFkZXIgY29tcHJlc3Npb24gc2No ZW1lIGFuZCBmcmFnbWVudGF0aW9uIGZ1bmN0aW9uYWxpdHkgZm9yIElQdjYvVURQIHByb3RvY29s cy7igJ0NCg0KRWRpdG9yaWFsL1RlY2huaWNhbDoNCg0KLSAgICAgICAgICBTZWN0aW9uIDI6DQpv ICAgUnVsZSBJRDogQW4gaWRlbnRpZmllciBmb3IgYSBydWxlLCBTQ0hDIEMvRCBhbmQgREVWIHNo YXJlIHRoZSBzYW1lIHJ1bGUgSUQgZm9yIGEgc3BlY2lmaWMgZmxvdy4NCuKAoiAgUmVtb3ZlOiBS dWxlIElEIGlzIHNlbnQgb24gdGhlIExQV0FOLg0KbyAgIEFkZCBGaWVsZCBJZGVudGlmaWVyIChG SUQpIGRlZmluaXRpb24NCm8gICBBZGQgSUlELCBERVYgSUQsIGFuZCBBUFAgSUQgZGVmaW5pdGlv bnMgKGZvciB0aGVzZSB0d28gbGF0dGVyLCBwbGVhc2Ugc2VlIGNvbW1lbnRzIG9uIHNlY3Rpb25z IDYgYW5kIDcgYmVsb3cpDQotICAgICAgICAgIFNlY3Rpb24gMzoNCm8gICBST0hDOiBBZGQgcmVm ZXJlbmNlIHRvIFJGQyA1Nzk1DQpvICAg4oCcVGhlIGNvbnRleHQgbXVzdCBiZSBzdG9yZWQgaW4g Ym90aCBlbmRzLiBJdCBjYW4gYWxzbyBiZSBsZWFybmVkIGJ5IHVzaW5nIGEgcHJvdmlzaW9ubmlu ZyBwcm90b2NvbCB0aGF0IGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBkcmFmdC7igJ0NCuKA oiAgQ2hhbmdlIHRvID4+IFRoZSBjb250ZXh0IG11c3QgYmUgc3RvcmVkIGluIGJvdGggZW5kcywg YW5kIGl0IGNhbiBlaXRoZXIgYmUgbGVhbmVkIGJ5IGEgcHJvdmlzaW9uaW5nIHByb3RvY29sLCBi eSBvdXQgb2YgYmFuZCBtZWFucywgaXQgY2FuIGJlIHByZS1wcm92aXNpb25lZCwgZXRjLiBUaGUg d2F5IHRoZSBjb250ZXh0IGlzIGxlYXJuZWQgb24gYm90aCBzaWRlcyBpcyBvdXQgb2Ygc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4NCm8gICBUaGUgcHJpbmNpcGxlIGlzIHRoZSBzYW1lIGluIHRoZSBv dGhlciBkaXJlY3Rpb24uDQrigKIgIENoYW5nZSB0byA+PiBUaGUgU0NIQyBwcm9jZXNzIGlzIGJp ZGlyZWN0aW9uYWwsIHNvIHRoZSBzYW1lIHByaW5jaXBsZXMgY2FuIGJlIGFwcGxpZWQgaW4gdGhl IG90aGVyIGRpcmVjdGlvbg0KbyAgIEFkZCBhIG5ldyBzdWJzZWN0aW9uIGhlYWRlciAoZS5nLiAz LjEpIGNhbGxlZCDigJxTQ0hDIFJ1bGVz4oCdIGJlZm9yZSB0aGUgZm9sbG93aW5nIHBhcmFncmFw aDoNCg0K4oCiICDigJxUaGUgY29udGV4dCBjb250YWlucyBhIGxpc3Qgb2YgcnVsZXMuLi7igJ0N Cm8gICBNb3ZlIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhl IHByb3Bvc2VkIG5ldyBzdWJzZWN0aW9uIDMuMToNCg0K4oCiICDigJxUaGUgbWFpbiBpZGVhIG9m IHRoZSBjb21wcmVzc2lvbiBzY2hlbWUuLi7igJ0NCg0KLSAgICAgICAgICBDdXJyZW50IHNlY3Rp b24gMy4yIFBhY2tldCBwcm9jZXNzaW5nOg0KbyAgIOKAnGNvbXByZXNzaW9uIHJ1bGUgc2VsZWN0 aW9uOiB0aGUgZ29hbCBpcyB0byBpZGVudGlmeSB3aGljaCBydWxlKHMpd2lsbCBiZSB1c2VkIHRv IGNvbXByZXNzIHRoZSBoZWFkZXJzLiBFYWNoIGZpZWxkIGlzIGFzc29jaWF0ZWQgdG8gYSBtYXRj aGluZyBvcGVyYXRvciBmb3IgY29tcHJlc3Npb24uIEVhY2ggaGVhZGVyIGZpZWxk4oCZcyB2YWx1 ZSBpcyBjb21wYXJlZCB0byB0aGUgY29ycmVzcG9uZGluZyB0YXJnZXQgdmFsdWUgc3RvcmVkIGlu IHRoZSBydWxlIGZvciB0aGF0IGZpZWxkIHVzaW5nIHRoZSBtYXRjaGluZyBvcGVyYXRvci4gSWYg YWxsIHRoZSBmaWVsZHMgaW4gdGhlIHBhY2tldOKAmXMgaGVhZGVyIHNhdGlzZmllZCBhbGwgdGhl IG1hdGNoaW5nIG9wZXJhdG9ycyBvZiBhIHJ1bGUsIHRoZSBwYWNrZXQgaXMgcHJvY2Vzc2VkIHVz aW5nIENvbXByZXNzaW9uIERlY29tcHJlc3Npb24gRnVuY3Rpb24gYXNzb2NpYXRlZCB3aXRoIHRo ZSBmaWVsZHMuIE90aGVyd2lzZSB0aGUgbmV4dCBydWxlIGlzIHRlc3RlZC4gSWYgbm8gZWxpZ2li bGUgcnVsZSBpcyBmb3VuZCwgdGhlbiB0aGUgcGFja2V0IGlzIHNlbnQgd2l0aG91dCBjb21wcmVz c2lvbiwgd2hpY2ggbWF5IHJlcXVpcmUgdXNpbmcgdGhlIGZyYWdtZW50YXRpb24gcHJvY2VkdXJl LuKAnQ0K4oCiICBDaGFuZ2UgdG8gPj4g4oCcY29tcHJlc3Npb24gcnVsZSBzZWxlY3Rpb246IHRo ZSBnb2FsIGlzIHRvIGlkZW50aWZ5IHdoaWNoIHJ1bGUocykgd2lsbCBiZSB1c2VkIHRvIGNvbXBy ZXNzIHRoZSBwYWNrZXQuIEZpZWxkcyBhcmUgZmlyc3QgaWRlbnRpZmllZCBhY2NvcmRpbmcgdG8g dGhlaXIgZmllbGQgaWRlbnRpZmllciAoRklEKSwgZmllbGQgcG9zaXRpb24gKEZQKSBhbmQgZGly ZWN0aW9uIGluZGljYXRvciAoREkpLiBFYWNoIGZpZWxk4oCZcyB2YWx1ZSBpcyB0aGVuIGNvbXBh cmVkIHRvIHRoZSBjb3JyZXNwb25kaW5nIHRhcmdldCB2YWx1ZSAoVFYpIHN0b3JlZCBpbiB0aGUg cnVsZSBmb3IgdGhhdCBzcGVjaWZpYyBmaWVsZCB1c2luZyB0aGUgbWF0Y2hpbmcgb3BlcmF0b3Ig KE1PKS4gSWYgYWxsIHRoZSBmaWVsZHMgaW4gdGhlIHBhY2tldCBzYXRpc2Z5IGFsbCB0aGUgbWF0 Y2hpbmcgb3BlcmF0b3JzIChNT3MpIG9mIGEgcnVsZSAoaS5lLiBhbGwgcmVzdWx0cyBhcmUgVHJ1 ZSksIHRoZSBmaWVsZHMgb2YgdGhlIHBhY2tldCBhcmUgdGhlbiBwcm9jZXNzZWQgYWNjb3JkaW5n IHRvIHRoZSBDb21wcmVzc2lvbiBEZWNvbXByZXNzaW9uIEFjdGlvbnMgKENEQXMpIGFuZCBhIGNv bXByZXNzZWQgcGFja2V0IGlzIG9idGFpbmVkLiBPdGhlcndpc2UgdGhlIG5leHQgcnVsZSBpcyB0 ZXN0ZWQuIElmIG5vIGVsaWdpYmxlIHJ1bGUgaXMgZm91bmQsIHRoZW4gdGhlIHBhY2tldCBtdXN0 IGJlIHNlbnQgd2l0aG91dCBjb21wcmVzc2lvbiwgaW4gd2hpY2ggY2FzZSB0aGUgZnJhZ21lbnRh dGlvbiBwcm9jZXNzIG1heSBiZSByZXF1aXJlZC7igJ0NCg0KbyAgIE5vdCBzdXJlIHdoeSB0aGUg Zm9sbG93aW5nIHNlbnRlbmNlIHdhcyBhZGRlZCBmcm9tIHJldiAwMiB0byByZXYgMDM6IOKAnElu IHRoZSBkb3duc3RyZWFuIGRpcmVjdGlvbiwgdGhlIHJ1bGUgaXMgYWxzbyB1c2VkIHRvIGZpbmQg dGhlIGRldmljZSBJRC4g4oCdDQoNCuKAoiAgU2hvdWxkIHByb2JhYmx5IHJlbW92ZSB0aGUgc2Vu dGVuY2UsIGFzIGl0IGxvb2tzIG91dCBvZiBwbGFjZS4NCg0K4oCiICBBbHNvLCBpc27igJl0IGl0 IHRoYXQgaW4gREwgZmlyc3QgdGhlIERFViBJRCBpcyB1c2VkIHRvIGtub3cgdGhlIHJ1bGUsIGFz IHRoZSBzYW1lIHJ1bGUgSUQgY2FuIGJlIHVzZWQgdG8gaWRlbnRpZnkgZGlmZmVyZW50IHJ1bGVz IGZvciBkaWZmZXJlbnQgZGV2aWNlcz8NCg0KbyAgIOKAnHNlbmRpbmc6IFRoZSBydWxlIElEIGlz IHNlbnQgdG8gdGhlIG90aGVyIGVuZCBmb2xsb3dlZCBieSBpbmZvcm1hdGlvbiByZXN1bHRpbmcg ZnJvbSB0aGUgY29tcHJlc3Npb24gb2YgaGVhZGVyIGZpZWxkcy4gIFRoaXMgaW5mb3JtYXRpb24g aXMgc2VudCBpbiB0aGUgb3JkZXIgZXhwcmVzc2VkIGluIHRoZSBydWxlIGZvciB0aGUgbWF0Y2hp bmcgZmllbGRzLiAgVGhlIHdheSB0aGUgcnVsZSBJRCBpcyBzZW50IGRlcGVuZHMgb24gdGhlIGxh eWVyIHR3byB0ZWNobm9sb2d5IGFuZCB3aWxsIGJlIHNwZWNpZmllZCBpbiBhIHNwZWNpZmljIGRv Y3VtZW50LiAgRm9yIGV4YW1wbGUsIGl0IGNhbiBlaXRoZXIgYmUgaW5jbHVkZWQgaW4gYSBMYXll ciAyIGhlYWRlciBvciBzZW50IGluIHRoZSBmaXJzdCBieXRlIG9mIHRoZSBMMiBwYXlsb2FkLiAo Y2YuICBGaWd1cmUgMykNCg0K4oCiICBDaGFuZ2UgdG8gPj4g4oCcc2VuZGluZzogVGhlIHJ1bGUg SUQgaXMgc2VudCB0byB0aGUgb3RoZXIgZW5kIGZvbGxvd2VkIGJ5IGluZm9ybWF0aW9uIHJlc3Vs dGluZyBmcm9tIHRoZSBjb21wcmVzc2lvbiBvZiB0aGUgcGFja2V04oCZcyBmaWVsZHMuICBUaGlz IGluZm9ybWF0aW9uIGlzIHNlbnQgaW4gdGhlIG9yZGVyIGV4cHJlc3NlZCBpbiB0aGUgcnVsZSBm b3IgdGhlIG1hdGNoaW5nIGZpZWxkcy4gIFRoZSB3YXkgdGhlIHJ1bGUgSUQgaXMgc2VudCBkZXBl bmRzIG9uIHRoZSBzcGVjaWZpYyBMUFdBTiB0ZWNobm9sb2d5IGFuZCB3aWxsIGJlIHNwZWNpZmll ZCBpbiBhIHNwZWNpZmljIGRvY3VtZW50LiAgRm9yIGV4YW1wbGUsIGl0IGNhbiBlaXRoZXIgYmUg aW5jbHVkZWQgaW4gYSBMYXllciAyIGhlYWRlciBvciBzZW50IGluIHRoZSBmaXJzdCBieXRlIG9m IHRoZSBMMiBwYXlsb2FkLiAoY2YuICBGaWd1cmUgMykNCg0KbyAgIOKAnGRlY29tcHJlc3Npb246 IFRoZSByZWNlaXZlciBpZGVudGlmaWVzIHRoZSBzZW5kZXIgdGhyb3VnaCBpdHMgZGV2aWNlLWlk IChlLmcuICBNQUMgYWRkcmVzcykgYW5kIHNlbGVjdHMgdGhlIGFwcHJvcHJpYXRlIHJ1bGUgdGhy b3VnaCB0aGUgcnVsZSBJRC4gVGhpcyBydWxlIGdpdmVzIHRoZSBjb21wcmVzc2VkIGhlYWRlciBm b3JtYXQgYW5kIGFzc29jaWF0ZXMgdGhlc2UgdmFsdWVzIHRvIGhlYWRlciBmaWVsZHMuICBJdCBh cHBsaWVzIHRoZSBDREEgYWN0aW9uIHRvIHJlY29uc3RydWN0IHRoZSBvcmlnaW5hbCBoZWFkZXIg ZmllbGRzLiAgVGhlIENEQSBvcmRlciBjYW4gYmUgZGlmZmVyZW50IG9mIHRoZSBvcmRlciBnaXZl biBieSB0aGUgcnVsZS4gIEZvciBpbnN0YW5jZSBDb21wdXRlLSogbWF5IGJlIGFwcGxpZWQgYWZ0 ZXIgdGhlIG90aGVyIENEQXMuDQoNCuKAoiAgQ2hhbmdlIHRvID4+IOKAnGRlY29tcHJlc3Npb246 IEluIHRoZSB1cHN0cmVhbSBkaXJlY3Rpb24sIHRoZSByZWNlaXZlciBmaXJzdCBpZGVudGlmaWVz IHRoZSBzZW5kZXIgdGhyb3VnaCBpdHMgZGV2aWNlIGlkZW50aWZpZXIgKERJRCkgYW5kIHNlbGVj dHMgdGhlIGFwcHJvcHJpYXRlIHJ1bGUgdGhyb3VnaCB0aGUgcnVsZSBJRC4gVGhpcyBydWxlIGdp dmVzIHRoZSBjb21wcmVzc2VkIGhlYWRlciBmb3JtYXQgYW5kIGFzc29jaWF0ZXMgdGhlc2UgdmFs dWVzIHRvIGhlYWRlciBmaWVsZHMuICBJdCBhcHBsaWVzIHRoZSBDREEgYWN0aW9uIHRvIHJlY29u c3RydWN0IHRoZSBvcmlnaW5hbCBoZWFkZXIgZmllbGRzLiAgVGhlIENEQSBvcmRlciBjYW4gYmUg ZGlmZmVyZW50IG9mIHRoZSBvcmRlciBnaXZlbiBieSB0aGUgcnVsZS4gIEZvciBpbnN0YW5jZSBD b21wdXRlLSogbWF5IGJlIGFwcGxpZWQgYWZ0ZXIgdGhlIG90aGVyIENEQXMu4oCdDQoNCi0gICAg ICAgICAgU2VjdGlvbiA0DQoNCm8gICDigJxUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBiYXNpYyBt YXRjaGluZyBvcGVyYXRvcnMgKE1PKXMgd2hpY2ggbXVzdCBiZSBrbm93biBieSBib3RoIFNDSEMg Qy9ELCBlbmRwb2ludHMgaW52b2x2ZWQgaW4gdGhlIGhlYWRlciBjb21wcmVzc2lvbi9kZWNvbXBy ZXNzaW9uLiAgVGhleSBhcmUgbm90IHR5cGVkIGFuZCBjYW4gYmUgYXBwbGllZCBpbmRpZmZlcmVu dGx5IHRvIGludGVnZXIsIHN0cmluZyBvciBhbnkgb3RoZXIgdHlwZS4gIFRoZSBNT3MgYW5kIHRo ZWlyIGRlZmluaXRpb25zIGFyZSBwcm92aWRlZCBuZXh0OuKAnQ0KDQrigKIgIENoYW5nZSB0byA+ PiDigJxNYXRjaGluZyBvcGVyYXRvcnMgKE1PcykgYXJlIGZ1bmN0aW9ucyB1c2VkIGJ5IGJvdGgg U0NIQyBDL0QgZW5kcG9pbnRzIGludm9sdmVkIGluIHRoZSBoZWFkZXIgY29tcHJlc3Npb24vZGVj b21wcmVzc2lvbi4gIFRoZXkgYXJlIG5vdCB0eXBlZCBhbmQgY2FuIGJlIGFwcGxpZWQgaW5kaWZm ZXJlbnRseSB0byBpbnRlZ2VyLCBzdHJpbmcgb3IgYW55IG90aGVyIGRhdGEgdHlwZS4gIFRoZSBy ZXN1bHQgb2YgdGhlIG9wZXJhdGlvbiBjYW4gZWl0aGVyIGJlIFRydWUgb3IgRmFsc2UuIE1PcyBh cmUgZGVmaW5lZCBhcyBmb2xsb3dzOuKAnQ0KDQpvICAg4oCcZXF1YWw6IGEgZmllbGQgdmFsdWUg aW4gYSBwYWNrZXQgbWF0Y2hlcyB3aXRoIGEgZmllbGQgdmFsdWUgaW4gYSBydWxlIGlmIHRoZXkg YXJlIGVxdWFsLuKAnQ0KDQrigKIgIENoYW5nZSB0bz4+IOKAnGVxdWFsOiBhIGZpZWxkIHZhbHVl IGluIGEgcGFja2V0IG1hdGNoZXMgd2l0aCBhIFRWIGluIGEgcnVsZSBpZiB0aGV5IGFyZSBlcXVh bC7igJ0NCg0KbyAgIOKAnE1TQihsZW5ndGgpOiBhIGZpZWxkIHZhbHVlIG9mIGEgc2l6ZSBlcXVh bCB0byAibGVuZ3RoIiBiaXRzIGluIGEgcGFja2V0IG1hdGNoZXMgd2l0aCBhIGZpZWxkIHZhbHVl IGluIGEgcnVsZSBpZiB0aGUgbW9zdCBzaWduaWZpY2FudCAibGVuZ3RoIiBiaXRzIGFyZSBlcXVh bC7igJ0NCg0K4oCiICBDaGFuZ2UgdG8+PiDigJxNU0IgKGxlbmd0aCk6IGEgbWF0Y2hpbmcgaXMg b2J0YWluZWQgaWYgdGhlIG1vc3Qgc2lnbmlmaWNhbnQgYml0cyBvZiB0aGUgbGVuZ3RoIGZpZWxk IHZhbHVlIG9mIHRoZSBwYWNrZXQgYXJlIGVxdWFsIHRvIHRoZSBUViBpbiB0aGUgcnVsZS7igJ0N Cg0KLSAgICAgICAgICBTZWN0aW9uIDUNCg0KbyAgIEluIGZpZ3VyZSA0IChzaG91bGQgcHJvYmFi bHkgYmUgY2FsbGVkIHRhYmxlIGluc3RlYWQgb2YgZmlndXJlKSwgY2hhbmdlIHRoZSBmb2xsb3dp bmcgQWN0aW9uOg0KDQrigKIgIExTQihsZW5ndGgpfHNlbmQgTFNCfGN0eHQgdmFsdWUgT1IgcmN2 ZCB2YWx1ZSAgPj4gIExTQihsZW5ndGgpfHNlbmQgTFNCfFRWIChPUikgcmVjZWl2ZWQgdmFsdWUN Cg0KbyAgIEluIDUuNDog4oCcTFNCIGFjdGlvbiBpcyB1c2VkIHRvIHNlbmQgYSBmaXhlZCBwYXJ0 IG9mIHRoZSBwYWNrZXQgZmllbGQgaGVhZGVyIHRvIHRoZSBvdGhlciBlbmQu4oCdDQoNCuKAoiAg Q2hhbmdlIHRvPj4g4oCcTFNCIGFjdGlvbiBpcyB1c2VkIHRvIGF2b2lkIHNlbmRpbmcgdGhlIGZp eGVkIHBhcnQgb2YgdGhlIHBhY2tldCBmaWVsZCB0byB0aGUgb3RoZXIgZW5kLuKAnQ0KDQpvICAg NS41LiAgREVWaWlkLURJRCwgQVBQaWlkLURJRCBDREE6DQoNCuKAoiAg4oCcVGhlc2UgZnVuY3Rp b25zIGFyZSB1c2VkIHRvIHByb2Nlc3MgcmVzcGVjdGl2ZWx5IHRoZSBEZXZpY2UgYW5kIHRoZSBB cHBsaWNhdGlvbiBEZXZpY2UgSWRlbnRpZmllciAoRElEKS4gIEFQUGlpZC1ESUQgQ0RBIGlzIGxl c3MgY29tbW9uLCBzaW5jZSBjdXJyZW50IExQV0FOIHRlY2hub2xvZ2llcyBmcmFtZXMgY29udGFp biBhIHNpbmdsZSBhZGRyZXNzLg0KDQrigKIgIFRoZSBJSUQgdmFsdWUgaXMgY29tcHV0ZWQgZnJv bSB0aGUgRGV2aWNlIElEIHByZXNlbnQgaW4gdGhlIExheWVyIDIgaGVhZGVyLiAgVGhlIGNvbXB1 dGF0aW9uIGRlcGVuZHMgb24gdGhlIHRlY2hub2xvZ3kgYW5kIHRoZSBEZXZpY2UgSUQgc2l6ZS4N Cg0K4oCiICBJbiB0aGUgZG93bnN0cmVhbSBkaXJlY3Rpb24sIHRoZXNlIENEQSBhcmUgdXNlZCB0 byBkZXRlcm1pbmUgdGhlIEwyIGFkZHJlc3NlcyB1c2VkIGJ5IHRoZSBMUFdBTi7igJ0NCg0K4oCi ICBDaGFuZ2UgdG8+PiBERVYgSUQsIEFQUCBJRCBDREFzOg0KDQrigKIgIOKAnFRoZXNlIGZ1bmN0 aW9ucyBhcmUgdXNlZCB0byBwcm9jZXNzIHRoZSBERVYgYW5kIHRoZSBBUFAgSWRlbnRpZmllcnMu ICBUaGUgdmFsdWUgY2FuIGJlIGNvbXB1dGVkIGZyb20gdGhlIERldmljZSBJRCBwcmVzZW50IGlu IHRoZSBMYXllciAyIGhlYWRlci4gIFRoZSBjb21wdXRhdGlvbiBpcyBzcGVjaWZpYyBmb3IgZWFj aCBMUFdBTiB0ZWNobm9sb2d5IGFuZCBkZXBlbmRzIG9uIHRoZSBEZXZpY2UgSUQgc2l6ZS4NCg0K byAgIEluIDUuNiDigJMgQWRkIG5ldyBzdWJzZWN0aW9ucyAoNS42LjEgYW5kIDUuNi4yKSB0byB0 aGUgY29tcHV0ZS1sZW5ndGggYW5kIGNvbXB1dGUtY2hlY2tzdW0gZnVuY3Rpb24gcGFyYWdyYXBo IGRlc2NyaXB0aW9ucywgcmVzcGVjdGl2ZWx5DQoNCi0gICAgICAgICAgU2VjdGlvbiA2DQoNCm8g ICA2LjI6IHdlbGxrbm93biA+PiB3ZWxsLWtub3duDQoNCm8gICA2LjM6IGRwZW5kaW5nID4+IGRl cGVuZGluZw0KDQpvICAgNi43LjIgSVB2NiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIElJRDog4oCc SWYgdGhlIERFViBvciBBUFAgSUlEIGFyZSBiYXNlZCBvbiBhbiBMUFdBTiBhZGRyZXNzLCB0aGVu IHRoZSBJSUQgY2FuIGJlIHJlY29uc3RydWN0ZWQgd2l0aCBpbmZvcm1hdGlvbiBjb21pbmcgZnJv bSB0aGUgTFBXQU4gaGVhZGVyLiAgSW4gdGhhdCBjYXNlLCB0aGUgVFYgaXMgbm90IHNldCwgdGhl IE1PIGlzIHNldCB0byAiaWdub3JlIiBhbmQgdGhlIENEQSBpcyBzZXQgdG8gIkRFVmlpZC1ESUQi IG9yICJBUFBpaWQtRElEIi4gIE5vdGUgdGhhdCB0aGUgTFBXQU4gdGVjaG5vbG9neSBpcyBnZW5l cmFsbHkgY2FycnlpbmcgYSBzaW5nbGUgZGV2aWNlIGlkZW50aWZpZXIgY29ycmVzcG9uZGluZyB0 byB0aGUgREVWLuKAnQ0KDQpvICAgQ2hhbmdlIHRvPj4g4oCcSWYgdGhlIERFViBvciBBUFAgSUlE IGFyZSBiYXNlZCBvbiBhbiBMUFdBTiBhZGRyZXNzLCB0aGVuIHRoZSBJSUQgY2FuIGJlIHJlY29u c3RydWN0ZWQgd2l0aCBpbmZvcm1hdGlvbiBjb21pbmcgZnJvbSB0aGUgTFBXQU4gaGVhZGVyLiAg SW4gdGhhdCBjYXNlLCB0aGUgVFYgaXMgbm90IHNldCwgdGhlIE1PIGlzIHNldCB0byAiaWdub3Jl IiBhbmQgdGhlIENEQSBpcyBzZXQgdG8gIkRFViBJSUQiIG9yICJBUFAgSUlEIi4gIE5vdGUgdGhh dCB0aGUgTFBXQU4gdGVjaG5vbG9neSBpcyBnZW5lcmFsbHkgY2FycnlpbmcgYSBzaW5nbGUgZGV2 aWNlIGlkZW50aWZpZXIgY29ycmVzcG9uZGluZyB0byB0aGUgREVWLuKAnQ0KDQpvICAgVGhlIGZv bGxvd2luZyBwYXJhZ3JhcGggaXMgY29udHJhZGljdG9yeToNCg0K4oCiICBGb3IgcHJpdmFjeSBy ZWFzb25zIG9yIGlmIHRoZSBERVYgYWRkcmVzcyBpcyBjaGFuZ2luZyBvdmVyIHRpbWUsIGl0IG1h eWJlIGJldHRlciB0byB1c2UgYSBzdGF0aWMgdmFsdWUuICBJbiB0aGF0IGNhc2UsIHRoZSBUViBj b250YWlucyB0aGUgdmFsdWUsIHRoZSBNTyBvcGVyYXRvciBpcyBzZXQgdG8gImVxdWFsIiBhbmQg dGhlIENEQSBpcyBzZXQgdG8gIm5vdC1zZW50Ii4NCg0K4oCiICBJZiB3ZSBhcmUgYWRkaW5nIHBy aXZhY3kgZmVhdHVyZXMsIHRoZSB1c2Ugb2YgbG9uZy1sYXN0aW5nIGlkZW50aWZpZXJzIHNob3Vs ZCBiZSBhdm9pZGVkLiBJdCBpcyBub3QgY2xlYXIgaWYgaW4gdGhpcyBjYXNlIGl0IGlzIHRoZSBz b3VyY2Ugb3IgdGhlIGRlc3RpbmF0aW9uIChjb21wcmVzc29yIG9yIGRlY29tcHJlc3NvcikgdGhh dCBpcyBpbiBjaGFyZ2Ugb2YgY2hhbmdpbmcgdGhlIGlkZW50aXR5LCBhbmQgd2hhdCBlZmZlY3Qg ZG9lcyB0aGlzIGhhdmUgb24gdGhlIENEQS4NCg0KLSAgICAgICAgICBTZWN0aW9uIDcNCg0KbyAg IEZpZ3VyZSA2OiBDb250ZXh0IHJ1bGVzIChhbmQgcmVzdCBvZiBzZWN0aW9uIDcpDQoNCuKAoiAg Q2hhbmdlIGFsbCBpbnN0YW5jZXMgb2Yg4oCcREVWaWlkLURJROKAnSA+PiDigJxERVYgSUlE4oCd DQoNCm8gICBSZW1vdmUgdGhlIGZvbGxvd2luZyBzZW50ZW5jZTog4oCcVGhlIERFVmlpZC1ESUQg dmFsdWUgaXMgZm91bmQgaW4gdGhlIEwyIGhlYWRlci7igJ0NCg0KDQoNCg0KDQpGb3IgY29tbWVu dHMgb24gU2VjdGlvbiA4IG9ud2FyZHMsIEkgd2lsbCB3YWl0IGZvciBhIG5ldyByZXZpc2lvbiBv ZiB0aGUgZHJhZnQgaW5jb3Jwb3JhdGluZyB0aGUgcG90ZW50aWFsIGNoYW5nZXMgdG8gY29tZSBh ZnRlciB0aGUgbGF0ZXN0IGRpc2N1c3Npb25zIGFib3V0IHRoZSBmcmFnbWVudGF0aW9uIG1vZGVz Lg0KDQoNCg0KQmVzdCwNCg0KDQoNCkp1YW4gQ2FybG9zDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbHAtd2FuIG1haWxpbmcgbGlzdA0KbHAt d2FuQGlldGYub3JnPG1haWx0bzpscC13YW5AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xwLXdhbg0KDQo= --_000_VI1PR08MB26882BAC525B63E4346EFDC789F70VI1PR08MB2688eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UN Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEFuYSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VHJ1ZSwg SSBzaG91bGQgaGF2ZSBzZW50IHNvbWUgcmVhc29uaW5nIGZvciBteSBjb21tZW50cyBvbiBERVYg YW5kIEFQUCBJRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBhZ3JlZSB0aGF0IHRoZSBkb2N1bWVudCBzaG91bGQg Zm9jdXMgb24gSVB2NiBhbmQgVURQIGhlYWRlciBjb21wcmVzc2lvbi4gSG93ZXZlciwgSSB0aGlu ayB3ZSBuZWVkIHRvIGNsYXJpZnkgdGhlIHdheSB0aGUgSVB2NiBhZGRyZXNzIGlzIGNhcnJpZWQv Z2VuZXJhdGVkLg0KIElmIHdlIGFyZSB1c2luZyBzdGF0aWMgYWRkcmVzcyBhdXRvY29uZmlndXJh dGlvbiAoU0xBQUMpLCB0aGVuIHRoZXJlIGFyZSBzb21lIHByaXZhY3kgY29uc2lkZXJhdGlvbnMg d2UgbmVlZCB0byB0YWtlIGludG8gYWNjb3VudCB0byBkZXJpdmUgdGhlIElQdjYgSUlEIChzZWUg UkZDIDcyMTcpLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJlY2F1c2Ugd2UgbWF5IHdhbnQgdG8gc3VwcG9ydCBk aWZmZXJlbnQgd2F5cyB0byBnZW5lcmF0ZSB0aGUgSUlELCBJIHRoaW5rIGl0IGlzIGVhc2llciBp ZiB3ZSBkZWZpbmUgaW4gU2VjdGlvbiA1IGFuIEFjdGlvbiAoQ0RBKSB0aGF0IGNhbiBiZSBhcHBs aWVkDQogb24gdGhlIERFViBJRCwgYW5kIHRoZW4gaW4gU2VjdGlvbiA2IHdlIGNhbiBleHBsYWlu IHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVudCB3YXlzIHRvIGRlcml2ZSB0aGUgSVB2NiBJSUQuIE9u ZSBvZiB0aGVtIGlzIGluZGVlZCBmcm9tIHRoZSBERVYgSUQsIGJ1dCB0aGVyZSBjb3VsZCBiZSBv dGhlciB3YXlzIChlLmcuIFJGQyA3MjE3KS4gQnkgZG9pbmcgdGhpcyBzZXBhcmF0aW9uIEkgdGhp bmsgd2UgYWxzbyBwcm92aWRlIGZsZXhpYmlsaXR5IHRvDQogcHJvdmlkZSBwcml2YWN5IGZlYXR1 cmVzIGF0IHRoZSBTQ0hDIGRlY29tcHJlc3NvciwgZXZlbiBmb3IgbG93IGVuZCBkZXZpY2VzIChl LmcuIGxlZ2FjeSkgdGhhdCBtYXkgbm90IGltcGxlbWVudCB0aGUgZnVsbCBJUCBzdGFjay48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+QmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SnVhbiBDYXJsb3MNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gbHAtd2FuIFttYWlsdG86bHAtd2FuLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkFuYSBNaW5hYnVybzxicj4NCjxiPlNlbnQ6PC9iPiBKdW5lIDEs IDIwMTcgOTozMiBBTTxicj4NCjxiPlRvOjwvYj4gSnVhbiBDYXJsb3MgWnVuaWdhICZsdDtqdWFu Y2FybG9zLnp1bmlnYUBzaWdmb3guY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbHAtd2FuICZsdDts cC13YW5AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbHAtd2FuXSBSZXZp ZXcgb2YgZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjLTAzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdCI+SGVsbG8sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+VGhhbmtzIGZvciB5 b3VyIGNvbW1lbnRzLCBJ4oCZbSBkb2luZyBteSBiZXN0IHRvIGdldCB0aGVtIHJlYWR5IGZvciB0 aGUgZW5kIG9mIHRoZSB3ZWVrLCBidXQgSSB3b3VsZCBsaWtlIHRvIHB1dCBpbiBhIGRpc2N1c3Np b24mbmJzcDt0aGF0IHNlZW1zIHRvIG1lIHZlcnkgaW1wb3J0YW50IGFmdGVyIHJlYWRpbmcgeW91 ciBjb21tZW50cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQiPkFmdGVyIHJlYWRp bmcgdGhhdCB5b3Ugd2FudCB0byBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIERFVi1paWQgYW5kIHRo ZSBBUFAtaWlkIGlzIHRoYXQgcGVyaGFwcyBpcyBub3QgY2xlYXIgdGhhdCB0aGlzIHR3byBDb21w cmVzc2lvbi9EZWNvbXByZXNzaW9uIEFjdGlvbnMgd2VyZSBjcmVhdGVkIHNwZWNpZmljYWxseSB0 byBjb21wcmVzcyB0aGUgSVB2NiBhZGRyZXNzLA0KIHNvIHdlIHVzZSB0aGUgSVB2NiB0ZXJtaW5v bG9neSAocHJlZml4IGFuZCBpbnRlcmZhY2UgaWRlbnRpZmllcikgaW4gb3JkZXIgdGhhdCBldmVy eWJvZHkgYXQgSUVURiByZWNvZ25pc2VzIHRoYXQgd2UgYXJlIGNvbXByZXNzaW5nIHRoZSBJUHY2 QC1paWQgYW5kIGtub3dzIHdoaWNoIHBhcnQgb2YgdGhlIGhlYWRlciBpcyBjb21wcmVzc2VkLiBJ 4oCZbSBub3QgYWdyZWUgd2l0aCB5b3VyIG1vZGlmaWNhdGlvbnMgYWJvdXQgdGhpcyBwYXJ0IGJl Y2F1c2UNCiB0aGlzIGNvdWxkIGNyZWF0ZSBhbWJpZ3VpdHkgaW4gdGhlIHVzZSBvZiB0aGlzIENE QXMsIHdoeSBub3QgdXNlZCB0aGVtIGZvciBvdGhlciBmaWVsZHMgd2hlcmVhcyB0aGV5IHdlcmUg b25seSBjcmVhdGVkIGZvciBMMyBhZGRyZXNzZXM/IEkgd291bGQgbGlrZSB0byBrbm93IHdoaWNo IGlzIHRoZSBmZWVsaW5nIG9mIHRoZSBNTCBpbiBvcmRlciB0byBtYWtlIHRoaXMgY2hhbmdlLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij5UaGFua3M8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0Ij5BbmE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMwIE1heSAyMDE3LCBhdCAyMjoyNSwgSnVh biBDYXJsb3MgWnVuaWdhICZsdDs8YSBocmVmPSJtYWlsdG86anVhbmNhcmxvcy56dW5pZ2FAc2ln Zm94LmNvbSI+anVhbmNhcmxvcy56dW5pZ2FAc2lnZm94LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QmVs b3cgYXJlIG15IGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbHB3YW4taXB2Ni1zdGF0aWMtY29udGV4 dC1oYy0wMzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+R2Vu ZXJhbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRocm91Z2hvdXQNCiB0 aGUgZG9jdW1lbnQgaXQgaXMgbWVudGlvbmVkIHRoYXQgdGhpcyBpcyBhIOKAnGhlYWRlcuKAnSBj b21wcmVzc2lvbiBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Ib3dldmVyLCBpbiBzb21lIGNhc2VzIHRoZSBiYXNlbGluZSBwcmluY2lw bGVzIGNhbiBhbHNvIGJlIGFwcGxpZWQgdG8gcGFja2V0IHBheWxvYWRzLiBGb3IgdGhhdCByZWFz b24sIEkgc3VnZ2VzdCByZW1vdmluZyDigJxoZWFkZXLigJ0gZnJvbSBhbGwgaW5zdGFuY2VzDQog aW4gc2VudGVuY2VzIHRoYXQgYXJlIG5vdCBzcGVjaWZpYyB0byB0aGUgaGVhZGVyIGl0c2VsZiwg bGlrZSB0aGUgYWJzdHJhY3QgYW5kIHRoZSBpbnRyb2R1Y3Rpb24sIGUuZy4g4oCcPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPlRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGE8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PHM+aGVhZGVyPC9zPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5jb21wcmVzc2lvbg0KIHNjaGVtZSBhbmQgZnJhZ21lbnRhdGlvbiBmdW5j dGlvbmFsaXR5IGZvciBJUHY2L1VEUCBwcm90b2NvbHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ 4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVkaXRvcmlh bC9UZWNobmljYWw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4t PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZWN0aW9u DQogMjogJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q291cmllciI+UnVsZSBJRDoNCiBBbiBpZGVudGlmaWVyIGZvciBhIHJ1bGUsIFNDSEMgQy9EIGFu ZCBERVYgc2hhcmUgdGhlIHNhbWUgcnVsZSBJRCBmb3IgYSBzcGVjaWZpYyBmbG93Ljwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6V2luZ2RpbmdzIj7Cpzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJz cDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+UmVtb3ZlOjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb3Vy aWVyIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPlJ1bGUNCiBJRCBpcyBzZW50IG9uIHRoZSBMUFdBTi48L3Nw YW4+PC9zPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BZGQNCiBGaWVsZCBJ ZGVudGlmaWVyIChGSUQpIGRlZmluaXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFkZA0KIElJRCwg REVWIElELCBhbmQgQVBQIElEIGRlZmluaXRpb25zIChmb3IgdGhlc2UgdHdvIGxhdHRlciwgcGxl YXNlIHNlZSBjb21tZW50cyBvbiBzZWN0aW9ucyA2IGFuZCA3IGJlbG93KTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNl Y3Rpb24NCiAzOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPm88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7 Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJPSEM6DQogQWRkIHJlZmVyZW5jZSB0byBSRkMgNTc5NTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij7igJxUaGUNCiBjb250ZXh0IG11c3QgYmUgc3RvcmVkIGluIGJvdGggZW5kcy4g SXQgY2FuIGFsc28gYmUgbGVhcm5lZCBieSB1c2luZyBhIHByb3Zpc2lvbm5pbmcgcHJvdG9jb2wg dGhhdCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQu4oCdPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDoxMDguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3MiPsKnPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5DaGFuZ2UNCiB0bzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRoZSBjb250ZXh0IG11c3QgYmUgc3RvcmVk IGluIGJvdGggZW5kcyw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+YW5kIGl0IGNhbiBlaXRoZXINCiBiZSBsZWFuZWQgYnkgYSBwcm92aXNpb25pbmcgcHJv dG9jb2wsIGJ5IG91dCBvZiBiYW5kIG1lYW5zLCBpdCBjYW4gYmUgcHJlLXByb3Zpc2lvbmVkLCBl dGMuIFRoZSB3YXkgdGhlIGNvbnRleHQgaXMgbGVhcm5lZCBvbiBib3RoIHNpZGVzIGlzIG91dCBv ZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5UaGUNCiBwcmluY2lwbGUgaXMgdGhlIHNhbWUgaW4gdGhlIG90aGVyIGRpcmVjdGlvbi48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OldpbmdkaW5ncyI+wqc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dCI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoYW5nZQ0KIHRvPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZndDs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGhlIFNDSEMgcHJv Y2VzcyBpcyBiaWRpcmVjdGlvbmFsLCBzbyB0aGUgc2FtZSBwcmluY2lwbGVzIGNhbiBiZSBhcHBs aWVkIGluIHRoZSBvdGhlciBkaXJlY3Rpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPm88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkFkZA0KIGEgbmV3IHN1YnNlY3Rpb24gaGVhZGVyIChlLmcuIDMuMSkgY2Fs bGVkIOKAnFNDSEMgUnVsZXPigJ0gYmVmb3JlIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBw dDt0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rpbmdz Ij7Cpzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7IDwvc3Bhbj7igJxUaGUgY29udGV4 dCBjb250YWlucyBhIGxpc3Qgb2YgcnVsZXMuLi7igJ08bzpwPjwvbzpwPjwvcHJlPg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TW92ZQ0KIHRoZSBmb2xsb3dp bmcgcGFyYWdyYXBoIHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhlIHByb3Bvc2VkIG5ldyBzdWJzZWN0 aW9uIDMuMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OldpbmdkaW5ncyI+wqc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyA8L3NwYW4+ 4oCcVGhlIG1haW4gaWRlYSBvZiB0aGUgY29tcHJlc3Npb24gc2NoZW1lLi4u4oCdPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTgu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5DdXJyZW50IHNlY3Rpb24gMy4yIFBhY2tldCBwcm9jZXNzaW5nOjwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ bzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPuKAnGNvbXByZXNzaW9u DQogcnVsZSBzZWxlY3Rpb246IHRoZSBnb2FsIGlzIHRvIGlkZW50aWZ5IHdoaWNoIHJ1bGUocyl3 aWxsIGJlIHVzZWQgdG8gY29tcHJlc3MgdGhlIGhlYWRlcnMuIEVhY2ggZmllbGQgaXMgYXNzb2Np YXRlZCB0byBhIG1hdGNoaW5nIG9wZXJhdG9yIGZvciBjb21wcmVzc2lvbi4gRWFjaCBoZWFkZXIg ZmllbGTigJlzIHZhbHVlIGlzIGNvbXBhcmVkIHRvIHRoZSBjb3JyZXNwb25kaW5nIHRhcmdldCB2 YWx1ZSBzdG9yZWQgaW4gdGhlIHJ1bGUgZm9yIHRoYXQNCiBmaWVsZCB1c2luZyB0aGUgbWF0Y2hp bmcgb3BlcmF0b3IuIElmIGFsbCB0aGUgZmllbGRzIGluIHRoZSBwYWNrZXTigJlzIGhlYWRlciBz YXRpc2ZpZWQgYWxsIHRoZSBtYXRjaGluZyBvcGVyYXRvcnMgb2YgYSBydWxlLCB0aGUgcGFja2V0 IGlzIHByb2Nlc3NlZCB1c2luZyBDb21wcmVzc2lvbiBEZWNvbXByZXNzaW9uIEZ1bmN0aW9uIGFz c29jaWF0ZWQgd2l0aCB0aGUgZmllbGRzLiBPdGhlcndpc2UgdGhlIG5leHQgcnVsZSBpcyB0ZXN0 ZWQuIElmIG5vDQogZWxpZ2libGUgcnVsZSBpcyBmb3VuZCwgdGhlbiB0aGUgcGFja2V0IGlzIHNl bnQgd2l0aG91dCBjb21wcmVzc2lvbiwgd2hpY2ggbWF5IHJlcXVpcmUgdXNpbmcgdGhlIGZyYWdt ZW50YXRpb24gcHJvY2VkdXJlLuKAnTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj7Cpzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hhbmdlDQog dG88c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPiZndDsm Z3Q7IOKAnGNvbXByZXNzaW9uIHJ1bGUgc2VsZWN0aW9uOiB0aGUgZ29hbCBpcyB0byBpZGVudGlm eSB3aGljaCBydWxlKHMpIHdpbGwgYmUgdXNlZCB0byBjb21wcmVzcyB0aGUgcGFja2V0LiBGaWVs ZHMgYXJlIGZpcnN0IGlkZW50aWZpZWQgYWNjb3JkaW5nIHRvIHRoZWlyDQogZmllbGQgaWRlbnRp ZmllciAoRklEKSwgZmllbGQgcG9zaXRpb24gKEZQKSBhbmQgZGlyZWN0aW9uIGluZGljYXRvciAo REkpLiBFYWNoIGZpZWxk4oCZcyB2YWx1ZSBpcyB0aGVuIGNvbXBhcmVkIHRvIHRoZSBjb3JyZXNw b25kaW5nIHRhcmdldCB2YWx1ZSAoVFYpIHN0b3JlZCBpbiB0aGUgcnVsZSBmb3IgdGhhdCBzcGVj aWZpYyBmaWVsZCB1c2luZyB0aGUgbWF0Y2hpbmcgb3BlcmF0b3IgKE1PKS4gSWYgYWxsIHRoZSBm aWVsZHMgaW4gdGhlIHBhY2tldA0KIHNhdGlzZnkgYWxsIHRoZSBtYXRjaGluZyBvcGVyYXRvcnMg KE1Pcykgb2YgYSBydWxlIChpLmUuIGFsbCByZXN1bHRzIGFyZSBUcnVlKSwgdGhlIGZpZWxkcyBv ZiB0aGUgcGFja2V0IGFyZSB0aGVuIHByb2Nlc3NlZCBhY2NvcmRpbmcgdG8gdGhlIENvbXByZXNz aW9uIERlY29tcHJlc3Npb24gQWN0aW9ucyAoQ0RBcykgYW5kIGEgY29tcHJlc3NlZCBwYWNrZXQg aXMgb2J0YWluZWQuIE90aGVyd2lzZSB0aGUgbmV4dCBydWxlIGlzIHRlc3RlZC4gSWYNCiBubyBl bGlnaWJsZSBydWxlIGlzIGZvdW5kLCB0aGVuIHRoZSBwYWNrZXQgbXVzdCBiZSBzZW50IHdpdGhv dXQgY29tcHJlc3Npb24sIGluIHdoaWNoIGNhc2UgdGhlIGZyYWdtZW50YXRpb24gcHJvY2VzcyBt YXkgYmUgcmVxdWlyZWQu4oCdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdCI+bzxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Tm90IHN1cmUgd2h5IHRoZSBmb2xsb3dpbmcgc2VudGVuY2Ugd2FzIGFkZGVk IGZyb20gcmV2IDAyIHRvIHJldiAwMzo8L3NwYW4+IOKAnEluIHRoZSBkb3duc3RyZWFuIGRpcmVj dGlvbiwgdGhlIHJ1bGUgaXMgYWxzbyB1c2VkIHRvIGZpbmQgdGhlIGRldmljZSBJRC4g4oCdPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+wqc8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyA8L3NwYW4+U2hvdWxkIHByb2JhYmx5IHJlbW92ZSB0 aGUgc2VudGVuY2UsIGFzIGl0IGxvb2tzIG91dCBvZiBwbGFjZS4gPG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+wqc8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPiZuYnNwOyA8L3NwYW4+QWxzbywgaXNu4oCZdCBpdCB0aGF0IGluIERMIGZpcnN0IHRoZSBE RVYgSUQgaXMgdXNlZCB0byBrbm93IHRoZSBydWxlLCBhcyB0aGUgc2FtZSBydWxlIElEIGNhbiBi ZSB1c2VkIHRvIGlkZW50aWZ5IGRpZmZlcmVudCBydWxlcyBmb3IgZGlmZmVyZW50IGRldmljZXM/ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWlu ZGVudDotMTguMHB0Ij5vPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyA8L3NwYW4+4oCc c2VuZGluZzogVGhlIHJ1bGUgSUQgaXMgc2VudCB0byB0aGUgb3RoZXIgZW5kIGZvbGxvd2VkIGJ5 IGluZm9ybWF0aW9uIHJlc3VsdGluZyBmcm9tIHRoZSBjb21wcmVzc2lvbiBvZiBoZWFkZXIgZmll bGRzLiZuYnNwOyBUaGlzIGluZm9ybWF0aW9uIGlzIHNlbnQgaW4gdGhlIG9yZGVyIGV4cHJlc3Nl ZCBpbiB0aGUgcnVsZSBmb3IgdGhlIG1hdGNoaW5nIGZpZWxkcy4mbmJzcDsgVGhlIHdheSB0aGUg cnVsZSBJRCBpcyBzZW50IGRlcGVuZHMgb24gdGhlIGxheWVyIHR3byB0ZWNobm9sb2d5IGFuZCB3 aWxsIGJlIHNwZWNpZmllZCBpbiBhIHNwZWNpZmljIGRvY3VtZW50LiZuYnNwOyBGb3IgZXhhbXBs ZSwgaXQgY2FuIGVpdGhlciBiZSBpbmNsdWRlZCBpbiBhIExheWVyIDIgaGVhZGVyIG9yIHNlbnQg aW4gdGhlIGZpcnN0IGJ5dGUgb2YgdGhlIEwyIHBheWxvYWQuIChjZi4mbmJzcDsgRmlndXJlIDMp PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+wqc8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGFu Z2UgdG88L3NwYW4+ICZndDsmZ3Q7IOKAnHNlbmRpbmc6IFRoZSBydWxlIElEIGlzIHNlbnQgdG8g dGhlIG90aGVyIGVuZCBmb2xsb3dlZCBieSBpbmZvcm1hdGlvbiByZXN1bHRpbmcgZnJvbSB0aGUg Y29tcHJlc3Npb24gb2YgdGhlIHBhY2tldOKAmXMgZmllbGRzLiZuYnNwOyBUaGlzIGluZm9ybWF0 aW9uIGlzIHNlbnQgaW4gdGhlIG9yZGVyIGV4cHJlc3NlZCBpbiB0aGUgcnVsZSBmb3IgdGhlIG1h dGNoaW5nIGZpZWxkcy4mbmJzcDsgVGhlIHdheSB0aGUgcnVsZSBJRCBpcyBzZW50IGRlcGVuZHMg b24gdGhlIHNwZWNpZmljIExQV0FOIHRlY2hub2xvZ3kgYW5kIHdpbGwgYmUgc3BlY2lmaWVkIGlu IGEgc3BlY2lmaWMgZG9jdW1lbnQuJm5ic3A7IEZvciBleGFtcGxlLCBpdCBjYW4gZWl0aGVyIGJl IGluY2x1ZGVkIGluIGEgTGF5ZXIgMiBoZWFkZXIgb3Igc2VudCBpbiB0aGUgZmlyc3QgYnl0ZSBv ZiB0aGUgTDIgcGF5bG9hZC4gKGNmLiZuYnNwOyBGaWd1cmUgMyk8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPm88c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj7igJxkZWNvbXByZXNzaW9uOiBUaGUg cmVjZWl2ZXIgaWRlbnRpZmllcyB0aGUgc2VuZGVyIHRocm91Z2ggaXRzIGRldmljZS1pZCAoZS5n LiZuYnNwOyBNQUMgYWRkcmVzcykgYW5kIHNlbGVjdHMgdGhlIGFwcHJvcHJpYXRlIHJ1bGUgdGhy b3VnaCB0aGUgcnVsZSBJRC4gVGhpcyBydWxlIGdpdmVzIHRoZSBjb21wcmVzc2VkIGhlYWRlciBm b3JtYXQgYW5kIGFzc29jaWF0ZXMgdGhlc2UgdmFsdWVzIHRvIGhlYWRlciBmaWVsZHMuJm5ic3A7 IEl0IGFwcGxpZXMgdGhlIENEQSBhY3Rpb24gdG8gcmVjb25zdHJ1Y3QgdGhlIG9yaWdpbmFsIGhl YWRlciBmaWVsZHMuJm5ic3A7IFRoZSBDREEgb3JkZXIgY2FuIGJlIGRpZmZlcmVudCBvZiB0aGUg b3JkZXIgZ2l2ZW4gYnkgdGhlIHJ1bGUuJm5ic3A7IEZvciBpbnN0YW5jZSBDb21wdXRlLSogbWF5 IGJlIGFwcGxpZWQgYWZ0ZXIgdGhlIG90aGVyIENEQXMuPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+wqc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZu YnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGFuZ2UgdG88L3NwYW4+ICZndDsmZ3Q7IOKA nGRlY29tcHJlc3Npb246IEluIHRoZSB1cHN0cmVhbSBkaXJlY3Rpb24sIHRoZSByZWNlaXZlciBm aXJzdCBpZGVudGlmaWVzIHRoZSBzZW5kZXIgdGhyb3VnaCBpdHMgZGV2aWNlIGlkZW50aWZpZXIg KERJRCkgYW5kIHNlbGVjdHMgdGhlIGFwcHJvcHJpYXRlIHJ1bGUgdGhyb3VnaCB0aGUgcnVsZSBJ RC4gVGhpcyBydWxlIGdpdmVzIHRoZSBjb21wcmVzc2VkIGhlYWRlciBmb3JtYXQgYW5kIGFzc29j aWF0ZXMgdGhlc2UgdmFsdWVzIHRvIGhlYWRlciBmaWVsZHMuJm5ic3A7IEl0IGFwcGxpZXMgdGhl IENEQSBhY3Rpb24gdG8gcmVjb25zdHJ1Y3QgdGhlIG9yaWdpbmFsIGhlYWRlciBmaWVsZHMuJm5i c3A7IFRoZSBDREEgb3JkZXIgY2FuIGJlIGRpZmZlcmVudCBvZiB0aGUgb3JkZXIgZ2l2ZW4gYnkg dGhlIHJ1bGUuJm5ic3A7IEZvciBpbnN0YW5jZSBDb21wdXRlLSogbWF5IGJlIGFwcGxpZWQgYWZ0 ZXIgdGhlIG90aGVyIENEQXMu4oCdPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZWN0aW9uIDQ8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0 LWluZGVudDotMTguMHB0Ij5vPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyA8L3NwYW4+ 4oCcVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYmFzaWMgbWF0Y2hpbmcgb3BlcmF0b3JzIChNTylz IHdoaWNoIG11c3QgYmUga25vd24gYnkgYm90aCBTQ0hDIEMvRCwgZW5kcG9pbnRzIGludm9sdmVk IGluIHRoZSBoZWFkZXIgY29tcHJlc3Npb24vZGVjb21wcmVzc2lvbi4mbmJzcDsgVGhleSBhcmUg bm90IHR5cGVkIGFuZCBjYW4gYmUgYXBwbGllZCBpbmRpZmZlcmVudGx5IHRvIGludGVnZXIsIHN0 cmluZyBvciBhbnkgb3RoZXIgdHlwZS4mbmJzcDsgVGhlIE1PcyBhbmQgdGhlaXIgZGVmaW5pdGlv bnMgYXJlIHByb3ZpZGVkIG5leHQ64oCdPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OldpbmdkaW5ncyI+wqc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyA8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5DaGFuZ2UgdG8gPC9zcGFuPiZndDsmZ3Q7IOKAnE1hdGNoaW5n IG9wZXJhdG9ycyAoTU9zKSBhcmUgZnVuY3Rpb25zIHVzZWQgYnkgYm90aCBTQ0hDIEMvRCBlbmRw b2ludHMgaW52b2x2ZWQgaW4gdGhlIGhlYWRlciBjb21wcmVzc2lvbi9kZWNvbXByZXNzaW9uLiZu YnNwOyBUaGV5IGFyZSBub3QgdHlwZWQgYW5kIGNhbiBiZSBhcHBsaWVkIGluZGlmZmVyZW50bHkg dG8gaW50ZWdlciwgc3RyaW5nIG9yIGFueSBvdGhlciBkYXRhIHR5cGUuJm5ic3A7IFRoZSByZXN1 bHQgb2YgdGhlIG9wZXJhdGlvbiBjYW4gZWl0aGVyIGJlIFRydWUgb3IgRmFsc2UuIE1PcyBhcmUg ZGVmaW5lZCBhcyBmb2xsb3dzOuKAnTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+bzxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4m bmJzcDsmbmJzcDsgPC9zcGFuPuKAnGVxdWFsOiBhIGZpZWxkIHZhbHVlIGluIGEgcGFja2V0IG1h dGNoZXMgd2l0aCBhIGZpZWxkIHZhbHVlIGluIGEgcnVsZSBpZiB0aGV5IGFyZSBlcXVhbC7igJ08 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDt0ZXh0LWlu ZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj7Cpzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoYW5n ZSB0bzwvc3Bhbj4mZ3Q7Jmd0OyDigJxlcXVhbDogYSBmaWVsZCB2YWx1ZSBpbiBhIHBhY2tldCBt YXRjaGVzIHdpdGggYSBUViBpbiBhIHJ1bGUgaWYgdGhleSBhcmUgZXF1YWwu4oCdPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTgu MHB0Ij5vPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyA8L3NwYW4+4oCcTVNCKGxlbmd0 aCk6IGEgZmllbGQgdmFsdWUgb2YgYSBzaXplIGVxdWFsIHRvICZxdW90O2xlbmd0aCZxdW90OyBi aXRzIGluIGEgcGFja2V0IG1hdGNoZXMgd2l0aCBhIGZpZWxkIHZhbHVlIGluIGEgcnVsZSBpZiB0 aGUgbW9zdCBzaWduaWZpY2FudCAmcXVvdDtsZW5ndGgmcXVvdDsgYml0cyBhcmUgZXF1YWwu4oCd PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+wqc8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGFu Z2UgdG88L3NwYW4+Jmd0OyZndDsg4oCcTVNCIChsZW5ndGgpOiBhIG1hdGNoaW5nIGlzIG9idGFp bmVkIGlmIHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdHMgb2YgdGhlIGxlbmd0aCBmaWVsZCB2YWx1 ZSBvZiB0aGUgcGFja2V0IGFyZSBlcXVhbCB0byB0aGUgVFYgaW4gdGhlIHJ1bGUu4oCdPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDot MTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5TZWN0aW9uIDU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ij5vPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPiZuYnNwOyZuYnNwOyA8L3NwYW4+SW4gZmlndXJlIDQgKHNob3VsZCBwcm9iYWJs eSBiZSBjYWxsZWQgdGFibGUgaW5zdGVhZCBvZiBmaWd1cmUpLCBjaGFuZ2UgdGhlIGZvbGxvd2lu ZyBBY3Rpb246PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4w cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5n cyI+wqc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyA8L3NwYW4+TFNCKGxlbmd0aCl8 c2VuZCBMU0J8Y3R4dCB2YWx1ZSBPUiByY3ZkIHZhbHVlJm5ic3A7ICZndDsmZ3Q7Jm5ic3A7IExT QihsZW5ndGgpfHNlbmQgTFNCfFRWIChPUikgcmVjZWl2ZWQgdmFsdWU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPm88 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5JbiA1LjQ6IOKAnExTQiBhY3Rp b24gaXMgdXNlZCB0byBzZW5kIGEgZml4ZWQgcGFydCBvZiB0aGUgcGFja2V0IGZpZWxkIGhlYWRl ciB0byB0aGUgb3RoZXIgZW5kLuKAnTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDoxMDguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpXaW5nZGluZ3MiPsKnPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsgPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Q2hhbmdlIHRvPC9zcGFuPiZndDsmZ3Q7IOKAnExTQiBhY3Rpb24g aXMgdXNlZCB0byBhdm9pZCBzZW5kaW5nIHRoZSBmaXhlZCBwYXJ0IG9mIHRoZSBwYWNrZXQgZmll bGQgdG8gdGhlIG90aGVyIGVuZC7igJ08bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPm88c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ Jm5ic3A7Jm5ic3A7IDwvc3Bhbj41LjUuJm5ic3A7IERFVmlpZC1ESUQsIEFQUGlpZC1ESUQgQ0RB OiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDt0ZXh0 LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj7Cpzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7IDwvc3Bhbj7igJxUaGVzZSBmdW5jdGlvbnMg YXJlIHVzZWQgdG8gcHJvY2VzcyByZXNwZWN0aXZlbHkgdGhlIERldmljZSBhbmQgdGhlIEFwcGxp Y2F0aW9uIERldmljZSBJZGVudGlmaWVyIChESUQpLiZuYnNwOyBBUFBpaWQtRElEIENEQSBpcyBs ZXNzIGNvbW1vbiwgc2luY2UgY3VycmVudCBMUFdBTiB0ZWNobm9sb2dpZXMgZnJhbWVzIGNvbnRh aW4gYSBzaW5nbGUgYWRkcmVzcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTA4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6V2luZ2RpbmdzIj7Cpzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7IDwvc3Bhbj5U aGUgSUlEIHZhbHVlIGlzIGNvbXB1dGVkIGZyb20gdGhlIERldmljZSBJRCBwcmVzZW50IGluIHRo ZSBMYXllciAyIGhlYWRlci4mbmJzcDsgVGhlIGNvbXB1dGF0aW9uIGRlcGVuZHMgb24gdGhlIHRl Y2hub2xvZ3kgYW5kIHRoZSBEZXZpY2UgSUQgc2l6ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj7Cpzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5i c3A7IDwvc3Bhbj5JbiB0aGUgZG93bnN0cmVhbSBkaXJlY3Rpb24sIHRoZXNlIENEQSBhcmUgdXNl ZCB0byBkZXRlcm1pbmUgdGhlIEwyIGFkZHJlc3NlcyB1c2VkIGJ5IHRoZSBMUFdBTi7igJ08bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDt0ZXh0LWluZGVu dDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj7Cpzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoYW5nZSB0 bzwvc3Bhbj4mZ3Q7Jmd0OyBERVYgSUQsIEFQUCBJRCBDREFzOjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPsKnPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij4mbmJzcDsgPC9zcGFuPuKAnFRoZXNlIGZ1bmN0aW9ucyBhcmUgdXNlZCB0byBwcm9jZXNzIHRo ZSBERVYgYW5kIHRoZSBBUFAgSWRlbnRpZmllcnMuJm5ic3A7IFRoZSB2YWx1ZSBjYW4gYmUgY29t cHV0ZWQgZnJvbSB0aGUgRGV2aWNlIElEIHByZXNlbnQgaW4gdGhlIExheWVyIDIgaGVhZGVyLiZu YnNwOyBUaGUgY29tcHV0YXRpb24gaXMgc3BlY2lmaWMgZm9yIGVhY2ggTFBXQU4gdGVjaG5vbG9n eSBhbmQgZGVwZW5kcyBvbiB0aGUgRGV2aWNlIElEIHNpemUuPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ij5vPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyA8L3NwYW4+SW4gNS42IOKAkyBBZGQgbmV3IHN1YnNl Y3Rpb25zICg1LjYuMSBhbmQgNS42LjIpIHRvIHRoZSBjb21wdXRlLWxlbmd0aCBhbmQgY29tcHV0 ZS1jaGVja3N1bSBmdW5jdGlvbiBwYXJhZ3JhcGggZGVzY3JpcHRpb25zLCByZXNwZWN0aXZlbHk8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5k ZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlY3Rpb24gNjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPm88c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj42LjI6IHdlbGxrbm93biAmZ3Q7Jmd0 OyB3ZWxsLWtub3duPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ij5vPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNw OyA8L3NwYW4+Ni4zOiBkcGVuZGluZyAmZ3Q7Jmd0OyBkZXBlbmRpbmc8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPm88 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj42LjcuMiBJUHY2IHNvdXJjZSBh bmQgZGVzdGluYXRpb24gSUlEOiDigJxJZiB0aGUgREVWIG9yIEFQUCBJSUQgYXJlIGJhc2VkIG9u IGFuIExQV0FOIGFkZHJlc3MsIHRoZW4gdGhlIElJRCBjYW4gYmUgcmVjb25zdHJ1Y3RlZCB3aXRo IGluZm9ybWF0aW9uIGNvbWluZyBmcm9tIHRoZSBMUFdBTiBoZWFkZXIuJm5ic3A7IEluIHRoYXQg Y2FzZSwgdGhlIFRWIGlzIG5vdCBzZXQsIHRoZSBNTyBpcyBzZXQgdG8gJnF1b3Q7aWdub3JlJnF1 b3Q7IGFuZCB0aGUgQ0RBIGlzIHNldCB0byAmcXVvdDtERVZpaWQtRElEJnF1b3Q7IG9yICZxdW90 O0FQUGlpZC1ESUQmcXVvdDsuJm5ic3A7IE5vdGUgdGhhdCB0aGUgTFBXQU4gdGVjaG5vbG9neSBp cyBnZW5lcmFsbHkgY2FycnlpbmcgYSBzaW5nbGUgZGV2aWNlIGlkZW50aWZpZXIgY29ycmVzcG9u ZGluZyB0byB0aGUgREVWLuKAnTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+bzxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJz cDsmbmJzcDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hhbmdlIHRvPC9zcGFuPiZndDsmZ3Q7 IOKAnElmIHRoZSBERVYgb3IgQVBQIElJRCBhcmUgYmFzZWQgb24gYW4gTFBXQU4gYWRkcmVzcywg dGhlbiB0aGUgSUlEIGNhbiBiZSByZWNvbnN0cnVjdGVkIHdpdGggaW5mb3JtYXRpb24gY29taW5n IGZyb20gdGhlIExQV0FOIGhlYWRlci4mbmJzcDsgSW4gdGhhdCBjYXNlLCB0aGUgVFYgaXMgbm90 IHNldCwgdGhlIE1PIGlzIHNldCB0byAmcXVvdDtpZ25vcmUmcXVvdDsgYW5kIHRoZSBDREEgaXMg c2V0IHRvICZxdW90O0RFViBJSUQmcXVvdDsgb3IgJnF1b3Q7QVBQIElJRCZxdW90Oy4mbmJzcDsg Tm90ZSB0aGF0IHRoZSBMUFdBTiB0ZWNobm9sb2d5IGlzIGdlbmVyYWxseSBjYXJyeWluZyBhIHNp bmdsZSBkZXZpY2UgaWRlbnRpZmllciBjb3JyZXNwb25kaW5nIHRvIHRoZSBERVYu4oCdPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDot MTguMHB0Ij5vPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaGUgZm9sbG93aW5nIHBhcmFncmFwaCBpcyBjb250cmFkaWN0b3J5PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjog PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3Mi PsKnPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsgPC9zcGFuPkZvciBwcml2YWN5IHJl YXNvbnMgb3IgaWYgdGhlIERFViBhZGRyZXNzIGlzIGNoYW5naW5nIG92ZXIgdGltZSwgaXQgbWF5 YmUgYmV0dGVyIHRvIHVzZSBhIHN0YXRpYyB2YWx1ZS4mbmJzcDsgSW4gdGhhdCBjYXNlLCB0aGUg VFYgY29udGFpbnMgdGhlIHZhbHVlLCB0aGUgTU8gb3BlcmF0b3IgaXMgc2V0IHRvICZxdW90O2Vx dWFsJnF1b3Q7IGFuZCB0aGUgQ0RBIGlzIHNldCB0byAmcXVvdDtub3Qtc2VudCZxdW90Oy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDt0ZXh0LWluZGVu dDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3MiPsKnPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsgPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+SWYgd2UgYXJlIGFkZGluZyBwcml2YWN5IGZlYXR1cmVzLCB0aGUgdXNlIG9mIGxv bmctbGFzdGluZyBpZGVudGlmaWVycyBzaG91bGQgYmUgYXZvaWRlZC4gSXQgaXMgbm90IGNsZWFy IGlmIGluIHRoaXMgY2FzZSBpdCBpcyB0aGUgc291cmNlIG9yIHRoZSBkZXN0aW5hdGlvbiAoY29t cHJlc3NvciBvciBkZWNvbXByZXNzb3IpIHRoYXQgaXMgaW4gY2hhcmdlIG9mIGNoYW5naW5nIHRo ZSBpZGVudGl0eSwgYW5kIHdoYXQgZWZmZWN0IGRvZXMgdGhpcyBoYXZlIG9uIHRoZSBDREEuPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VjdGlvbiA3PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+ bzxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgPC9zcGFuPkZpZ3VyZSA2OiBDb250ZXh0 IHJ1bGVzIChhbmQgcmVzdCBvZiBzZWN0aW9uIDcpPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+wqc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNw OyA8L3NwYW4+Q2hhbmdlIGFsbCBpbnN0YW5jZXMgb2Yg4oCcREVWaWlkLURJROKAnSAmZ3Q7Jmd0 OyDigJxERVYgSUlE4oCdPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0Ij5vPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZu YnNwOyA8L3NwYW4+UmVtb3ZlIHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6IOKAnFRoZSBERVZpaWQt RElEIHZhbHVlIGlzIGZvdW5kIGluIHRoZSBMMiBoZWFkZXIu4oCdPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgY29tbWVudHMgb24gU2VjdGlvbiA4IG9ud2Fy ZHMsIEkgd2lsbCB3YWl0IGZvciBhIG5ldyByZXZpc2lvbiBvZiB0aGUgZHJhZnQgaW5jb3Jwb3Jh dGluZyB0aGUgcG90ZW50aWFsIGNoYW5nZXMgdG8gY29tZSBhZnRlciB0aGUgbGF0ZXN0IGRpc2N1 c3Npb25zIGFib3V0IHRoZSBmcmFnbWVudGF0aW9uIG1vZGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJlc3QsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SnVhbiBDYXJsb3MgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbHAtd2FuIG1haWxpbmcg bGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bHAtd2FuQGlldGYub3JnIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM5NTRGNzIiPmxwLXdhbkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHAtd2FuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5NTRGNzIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHAtd2FuPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_VI1PR08MB26882BAC525B63E4346EFDC789F70VI1PR08MB2688eurp_-- From nobody Mon Jun 5 06:48:07 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67801294D4 for ; Mon, 5 Jun 2017 06:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 paQcNVWl6nkQ for ; Mon, 5 Jun 2017 06:47:54 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 BE4791294AB for ; Mon, 5 Jun 2017 06:47:53 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v55DlnHa039638; Mon, 5 Jun 2017 15:47:50 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 1878F1D53C1; Mon, 5 Jun 2017 15:47:49 +0200 (CEST) Received: from 10.193.93.143 by webmail.entel.upc.edu with HTTP; Mon, 5 Jun 2017 15:47:25 +0200 Message-ID: <9a7df13686f6a86b97865e826bed3d78.squirrel@webmail.entel.upc.edu> In-Reply-To: References: Date: Mon, 5 Jun 2017 15:47:25 +0200 From: "Carles Gomez Montenegro" To: "Prof. Diego Dujovne" Cc: "lp-wan" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Mon, 05 Jun 2017 15:47:50 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] review draft-ietf-lpwan-ipv6-static-context-hc-03 (part II) X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 13:47:57 -0000 Hi Diego, Thanks a lot for your review. The fragmentation part has been updated (now in github, and hopefully in the -04 to be published soon). Your comments should hopefully be addressed in the updated version. On the other hand, please find below inline responses to your questions or to comments that needed discussion. (Everything else is agreed or done and snipped.) > - "If the datagram does not fit within a single L2 data unit, it SHALL > > be broken into fragments." > > > And if not broken into fragments, the alternative is to > > drop the packet? Yes. > - "provides flow control" > > > I don't know if this is exactly flow control in the terms > > of what it is known in TCP. For TCP, one lost packet signals > > that the bandwidth limit for the flow is full (probably due > > to congestion), and there is no congestion at the lpwan level. > > What is true is that this mechanism stops 'Flow control' is used here to refer to the fact that a receiver ACKing a window of fragments means that it has been able to perform the corresponding operations on the received (or missing) fragments. > Fragmentation header formats > > > > I am worried about the "SHALL" term. The header MUST be > > as described, if not, there will be no interoperability. Well, RFC 2119 defines use of "SHALL" for the same purpose as "MUST". (It is true that "MUST" is more common, though...) > I can understand you have to create a rule for each > > fragmentation reliability option used. Am I right? Yes (this is mentioned in the document, and hopefully clearer now). Cheers, Carles From nobody Wed Jun 7 06:22:01 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1300812EC25; Wed, 7 Jun 2017 06:22:00 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 WlJHbemM9eME; Wed, 7 Jun 2017 06:21:55 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF3D12946F; Wed, 7 Jun 2017 06:21:55 -0700 (PDT) Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 8027AA80F5; Wed, 7 Jun 2017 15:21:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter9-d.gandi.net (mfilter9-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id LwyNnsBYXz-l; Wed, 7 Jun 2017 15:21:51 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from el-meco.rennes.enst-bretagne.fr (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: ana@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 8B061A811C; Wed, 7 Jun 2017 15:21:48 +0200 (CEST) Content-Type: multipart/mixed; boundary="Apple-Mail=_5A6A0425-F6F3-4A7B-B7EB-1E36D7778DED" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ana Minaburo In-Reply-To: <58E6D5AA-1F9D-4455-9D64-C59CCFF5E7B3@ackl.io> Date: Wed, 7 Jun 2017 15:21:48 +0200 Cc: lp-wan , Core Message-Id: <3CE1CCAF-7586-4393-B130-6FA5431A2544@ackl.io> References: <58E6D5AA-1F9D-4455-9D64-C59CCFF5E7B3@ackl.io> To: Alexander Pelov X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lp-wan] Agenda for LPWAN interim meeting next Wednesday, June 7th X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 13:22:00 -0000 --Apple-Mail=_5A6A0425-F6F3-4A7B-B7EB-1E36D7778DED Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hello, Here you will find the slides for SCHC Ana --Apple-Mail=_5A6A0425-F6F3-4A7B-B7EB-1E36D7778DED Content-Disposition: attachment; filename=SCHC-compression-7june.pptx Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="SCHC-compression-7june.pptx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDohFCtygEAAOwKAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE VslOwzAQvSPxD5GvqHFbJIRQUw4sJ5ZKwAeYZNoaHNuyp6X9eyZJCymKmkAacYk0tt8y9ozj0eUq VcESnJdGR2wQ9lkAOjaJ1LOIvTzf9s5Z4FHoRCijIWJr8OxyfHw0el5b8AGhtY/YHNFecO7jOaTC h8aCppmpcalACt2MWxG/ixnwYb9/xmOjETT2MONg49E1TMVCYXCzouHCCcFZcFWsy6QiJqxVMhZI 0zyb5ZW4NwuzH0CZZsL5RDXG6mpINl6NcKD8HntLnfzYg94m/5CQ+Ro/l9afbPJ4pANwMoFgIhw+ iJTouLXIrQNPAjkg3L8jFZJmOpUxJCZepAQJy2Sp2gnDVEhdZ8YrGrwXHqlYysHg0M5K3I08bdx0 4+M3Dob/7uD0Xxxog+C3lVEKDn4iJe46T3O6sswCt652woP72mFv0tQTZ6zvoqNz4joHSwkfnTj4 Iq5zgPSfgOLb/jBymlpF8argCdcKDp51ibpRr96JNRXLpmOLoJu7q+D+q6dubrN2nrq535p5KtVs +61pVrPfiu0Tr1WklXnv0uvMwe/ltg+cDN2zRAQO5f6O+FIk6tb5QfY6SyCp0Ob5W3X8CQAA//8D AFBLAwQUAAYACAAAACEAo+yCJgIBAADiAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySz0oDMRCH 74LvEObezbaKiDTbiwi9iawPMCazu6mbPyRTad/e2IO6sBTBHjPzm49vkqw3BzeKD0rZBq9gWdUg yOtgrO8VvLZPi3sQmdEbHIMnBUfKsGmur9YvNCKXoTzYmEWh+KxgYI4PUmY9kMNchUi+dLqQHHI5 pl5G1O/Yk1zV9Z1MvxnQTJhiaxSkrbkB0R4j/Y8tHTEaZJQ6JFrEVKYT27KLaDH1xApM0M+lnE+J qpBBzgvd/l0odJ3V9Bj03pHnOS86MHlD5rwSxnjOaHlJo2niRyZGljFRLsVT+pzQ6rJvxsPevXm0 48zVfPeqXaT+S0hOfmbzCQAA//8DAFBLAwQUAAYACAAAACEANYm6LykBAADAAgAAIAAAAHBwdC9z bGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxztJLBagIxEEDvhf7DknuSVUGKuOqhLQjtpdgPGLKz u8FkEpLR6t83FkoVFHpoj5nMvHkzyXx58K7aY8o2UCNGqhYVkgmtpb4R75tn+SCqzEAtuEDYiCNm sVzc383f0AGXojzYmKtCodyIgTnOtM5mQA9ZhYhUbrqQPHA5pl5HMFvoUY/reqrTOUMsLpjVum1E WrcjUW2OEX/DDl1nDT4Gs/NIfKWFzs62+ALHsOOChdQjN0Kp8/hF0kSVFkJfNxv/pdlQSMlZ2v54 nbC5cDkEl5VF7r5YA3un2wQdy1NMuvgBJG3cT2V5KLZGmkCMB5aDkfXkm/ca2qL6dGBMBDdnOqX/ 50werOMwc7BLpUhx2TFYWlnPEtgBFX1UXbotrS/+3eITAAD//wMAUEsDBBQABgAIAAAAIQBL9T3s vQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHOMz70KwjAQB/Bd8B3C 7SbVQUSauoggOIk+wJFc22CbhFwU+/ZmtODgeF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfTageC M3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTPGvqc414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2Kn0b 0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8/hGheHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5tPgAA AP//AwBQSwMEFAAGAAgAAAAhAOab9xA4AQAADwYAAB8ACAFwcHQvX3JlbHMvcHJlc2VudGF0aW9u LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvJTBTsQgEIbvJr4D 4W5pu7quZulejMkeTIyuD4DttCVSIMCu9u0lq6ltsyEeyB7nZ+bnyzDMevPVCXQAY7mSFGdJihHI UlVcNhS/7R6vVhhZx2TFhJJAcQ8Wb4rLi/ULCOZ8kW25tsi7SEtx65y+J8SWLXTMJkqD9Ce1Mh1z PjQN0az8YA2QPE2XxIw9cDHxRNuKYrOtFhjteg3/8VZ1zUt4UOW+A+lOXEGs4BV4Q2YacBQfw181 T7wbJqchrs8EsQhB3MSEkMqBfWLWgflDGYmTjCyEtYyJ1fpJU3s3B5vIs6wg3G1MOG3APhvlR3UA G6QQxComxIHD5wxikEIQdzEhnK8djfAx/BGDr5GlUSHYu4BX1wsY9WIkBkmif+j5yI7ESUawQfmZ 9swAQSZrvPgGAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTIueG1sLnJlbHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/Zm tODgeF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTP Gvqc414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8 /hGheHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAhAEQvG48g AwAAKA8AABQAAABwcHQvcHJlc2VudGF0aW9uLnhtbOyX32/aMBDH3yftf4jyOtHEzg8CAipol2lS J6HS/QFuYiCqE0e2Q2mn/e87GwdSiqpKe81Tzr67r51Pzopvcr0vmbOjQha8mrroyncdWmU8L6rN 1P39kA4S15GKVDlhvKJT94VK93r29cukHteCSlopoiDVAZlKjsnU3SpVjz1PZltaEnnFa1qBb81F SRQMxcbLBXkG+ZJ52PdjryRF5dp88Zl8vl4XGb3lWVPC8gcRQZnZh9wWtWzV6s+odd/i7ZYk2dFV 8yipSnmlJNBxHdIofsNLnSSXRaYaMKau786Ah2T5LyIVFT/zO6nOZpwin7oYhcMwCeIhKImxngEP 2N5s4l3Kr7ii8qO5k0rUqlzK2cL34436ePakFbdal/Ngn29t827hKOi8FDYSXX/kd/3BBX/Y8Ycd KN3FVq9Otp+6IxSGvg+1mr1AJgqDSA/USw0VKjNBaYXi/ciuYYjYxDiJkmPiUcWE5XRNGqYe6F6t 1AujswnRc8ulsNb9UjiM6HOxFoP0/rDDbgzbMVRDUEnEnS4Kh7ANHCrmOhDzQB5Xr4ApGvqx/vyK mRBK7qqFeDLFpUu4skNwAf0NnJNlU2VK+zvbkKCEEr31Jyr0uYWyNX7JWZGnBWNmoKue3jDh7Ais pva21M7CzLIG3ppkAPBbWQ2YMqFkTMmZhxLryeSZJ5MdJPcaiXdkYvHgE54WRM+oBWMZBSdGUKAI 94wsIw3GMgpPjFAwRCgJekgHSJqMhRR1ICU4wWEPyULSZCyk+AQJ4yQK9F+qh9SSsZCGHUjDEAdx D8lC0mQspOQEKUCjUYjDHtIBkiZjIY06kOIoDpOoh3SApMmYG+/7e2g9BtvegcFyGlFM3T/f03m6 wEEw8OMgHYR4EQ0S+BkORrdpkEZoMUf+/K9uTFCkb84/miKnINL2Rih61x2VRSa45Gt1lfHStlle zZ+pqHlhOi2ED73RQXWjJc3lHZBxUUAbBZpcvLpOzXW/FGPTGUFoxkwFSLF5PJKeh/Ng3l702xhj GeHzNbBVxUnyX6rG7gAx0AFr+2ynuo3h7B8AAAD//wMAUEsDBBQABgAIAAAAIQDDE4Er4AMAAJwM AAAVAAAAcHB0L3NsaWRlcy9zbGlkZTIueG1svFddcts2EH7vTO+ww4dOMh6aEkWpsho5kSipUcdx PJbz0jcIBCVMSIAFQFlqJzO9Ro/gc/gmPUkX/IlkR0n8Wz0QIAjst99+C2D16vU6TWDFlOZS9J3m YcMBJqiMuFj0nQ8XE7frgDZERCSRgvWdDdPO6+Mff3iV9XQSAa4Wukf6ztKYrOd5mi5ZSvShzJjA b7FUKTH4qhZepMglWk0Tz280Ol5KuHCq9eou62Ucc8pGkuYpE6Y0olhCDHqulzzTtbXsLtYyxTSa KVbfcOkYmdFZEtlWZxeKMdsTq19VNsvOVPH5dHWmgEcYLwcESTEsDnjVl2pe+S7sROx5tyws6i7p rWOV2hbpwbrvYPw3xdOzg2xtgJajdGeYLt/vm02X433zvRrE2wG25EoPv2Tl16wuuFEMmltytdM6 O5H0owYhkVQRhpLk5yklddtmSzCbDI0ZbhJWTyy/Fp2tP3XUzHooo43FmWNbIgrUbpAbGXMDsRRm RkmCRo8a+KtZbmcn2szMJmFlXDL7KMYVQiTEpjYT7oeZAxFXpgyUTk2YMCK24TTHs/BtCKFMbbLY DWJBTAFVWGMiOiOKnH/daOlXVjCtWXl16L8uQKsWYKwzQhmo6yvN1Or6CqIcKLJnIgf/sbLwaL0z 58kU8dtWkUTMMnrOopzaHYY59axC/ZYTASFRidTwey74goBiK84u//37H31DtVKO+mFRVkkdhYdh T6cj5K9gerbqAIkimysgRbKB6egO0KWMD4TehaSYp1KzqAedAOYoyiKRc5IAJm/M13BQDevSWcwh FdvcmkZ4DPKYMwUvkMpL6P+0ML/ArVT/nneVQy9OmbmU6iPgvjAI+VZqU/Rf3jb4/b1zm/DTh+9i ifRRPYrJM2cwJxg9VK53B9Vaj4B9NwjhzTNjnPg7wj4z1jlWBzIFkafzZ8ea2Rub/j9YuLuCN3Bw cA+Yp8rq+jx6qL37XTfBt64bDPX1lZIQMUQleMJww1cMSsaPLgqwhjzNU6TxZ9/5I8eDgimnupjK nX3fm6mM255rJcZq1ZL9y/dH/tjvjtxW2A3cySCYuIPBUdsdTRqT0G+Ph37Q/uR89o/jNkIPb+ZP rNzJ+f6s8bfpEtsqco+I1epvqFU0de2JReCJNlUPcsWRxHB41PHD7tAdNtH/YHT0szuYdNrupN0K gnDYHYSt8SdbyzaDHlWsKHOndbmOg1+UyCmnSmoZm0O8R6pa28vkJVOZ5EW53WxUNfuK2HO32wiC bqPRLhPBK5yr28Jdq3xVR9NEvSPZ+1WRJoiGKofFUIZ/COos2c6x7HHhfwAAAP//AwBQSwMEFAAG AAgAAAAhAKAd+7uyBQAAxBgAABUAAABwcHQvc2xpZGVzL3NsaWRlMS54bWzsWNty2zYQfe9M/wHD 1w4lkqKoy0ROLNpKPeMkHkt56RsMghZrEGBBUL5k8kH5jvxYFwBpKrLsys7F7TQvIkiAu2fP7lmI ePHyKmdoRWWZCT5x/I7nIMqJSDJ+PnHeL2bu0EGlwjzBTHA6ca5p6bzc+/WXF8W4ZAmCt3k5xhNn qVQx7nZLsqQ5LjuioBzmUiFzrOBWnncTiS/Bas66gedF3Rxn3Knfl7u8L9I0I/RAkCqnXFkjkjKs AHm5zIqysVbsYq2QtAQz5u0vIO1BZGTOEn0ti4WkVI/46rUs5sWJNNNvVycSZQnw5SCOc6DFQd16 pl5n77leCKPuhoXzZojHV6nM9RXCQ1cTB/i/Nr9d/ZBeKUTsU7L2mCzfbVtNlofb1ncbJ901xzo4 i/BuVL0mqsOywIQi+flTSeXq8yeUVIhX+edPUqCEoiTDhSgzla0oCloGmsjK4liQixJxAZEbriwT t0ssP/paLJG6LsAj1NTbKoeSu5k4f1VYKiodwAQh+daDYVK/ZAZtLA3j6moqkmvt/gyu9ikes1LN 1TWj9q7QPylUrw72QxAcBIfB8MDtxcPQne2HM3d/f9R3D2beLA76h9Mg7H90bvFlCQUKHG1CgnmG tVBS6c5OAXWuYkYxb1Oi9nzNvzJZSHVVQVJ5coIlPt1826aqMKE1YXSbPN2frbDJ1iJTkiJL8y3L SFvS9BnETUq2JuKW3nVW7y1R3+/1RoFNSluoIz8MPa8uv5Hn+U3aWiuFLNVrKnKkBxNHUqIMNrw6 LlVDQr2mJsDCuZNaaFtgYCnkjYPYES+Nex8IUOYm7A+8gYPk+szZFzOKxYKZgDAnYGfiECUNGA6t Yr9SIs0USgVXc4IZUDzwTHCMzwtySpOK6PYxcQL72GK34NarzoxXzNfpwOycWzegoHSBz+Y3Fk/k G0AGDcXHfCovjGZ0g+P1LUwtoWKgi55UnKg2q2RK03p0QhRaYWvHAmqnz6q30MRtxsC7rkAtNJ0y B11QqXcAiMUaFVDqs4wxc6MbKY2ZtKbVVS3mjWUGq1FKCn1j4vyW/+ky1ZQI3pihuOlb5cYMKRvz FqUZ1gza8RqzRs2G71aPlLvv55Btw2CSSWWb4bo+7ziGVn9WQZwKvZk37qVNpNqbx7/HKBa53jb0 VtmK2gIyIB5AUkHr4OdrWPSqJcv4RcwycoHkWEtZHiW3crl1DftmqtyMqtRlxSXmblasIrfUWxdx CdQmaM9dEtfrfQFqS5+psbR8PLHj9J+n4wSjgT8YjR7qOH5/GHlDu+S/3HJ+dpJ/WSfRweku/1A3 uYuZt5h3bzVQA1AX5fixLeZHQuQYvck4Pqvgj+BG19kdHJXS1OV3Aok5foXJBetkYsfG+P0ZbD1/ s5TuTsgxriR88nz7hO0OYSEqBR9ZT0bwdM9Pj/pxPrfv6r07eJhNRkdZRl5luXKxAjCwq9NOKr9h yf6Iqvz60oixZLR8jsp4LXJ685yqICb0c/EKCoKyTlWQDnxbPL0Cnpj0x/0JjJ7nT2Do98NBNPwf fHb+/A/4bP8BH6m1TaBbNoXvLsdBI8c/ICcL0AVF0X2S3HI2+Q/aiwbDQRiGVoHRMBzW31itAv1h GEWRFWAvGvV6XylArQVdCDXCe8V4KXExcTgEvS4sW71aSbMHlLR2GvhV38rm0pwUAyEQTz1Clcwm zofpdBQF8XDqTv1w5oYHo4G7P4v67qzfC8N4OtyPe4cf9cmzH46JpOZQ+qg5XIeHdw6084xIUYpU dYjI65PxbiEuqSxEZg7Hfa8+YTcSg4z4XhAGXr85RAVwzdXA1X25PvUmTL7BxbuV4Qq8KSpj86iA VtH08HYN0JHlMGNGvI69wLY+F7w5J08q6HMZBwlmPFM6W7RUWHdSTlf6lJeLhC7MIavKT4WwQu/W pjTp1rYe1f407wD5bwAAAP//AwBQSwMEFAAGAAgAAAAhADd+MgH0AwAAmwsAABUAAABwcHQvc2xp ZGVzL3NsaWRlMy54bWy0Vtty2zYQfe9M/2GHz6UpU5IraSJ7JMpqMpOLx3I+AAZBERMQQAFQltrJ v3cBCpZvSR3H0QMBAYu9nD1Y7JuzbSNgw4zlSk6T46NeAkxSVXK5niafr5bpKAHriCyJUJJNkx2z ydnp77+90RMrSsDT0k7INKmd05Mss7RmDbFHSjOJe5UyDXH416yz0pAb1NqILO/1TrKGcJnsz5vn nFdVxSlbKNo2TLpOiWGCOPTc1lzbqE0/R5s2zKKacPqeS6cYGV2J0o9WXxnG/Exu/jJ6pS9M2P64 uTDAS8QrAUkahCWBbL+zl+v+Sy+Is+yBhnWcksm2Mo0fMTzYThPEfxe+mV9kWwe0W6V3lmn96Slp Wp8/JZ9FI9kdwz64zsPHUeUxqivuBIPjQ3DRaavfK/rFglQYVIChC/JWpAvdj7oGt9OozHllUbDb DZODPxE1t52rcuftXOPYWZSYu1nrVMUdVEq6FSUClY57+ItRHqSFdSu3Q98DLtp/wrpBE4J4ajOZ fl4lUHLjOqBs4wrBiDzA6U5XxdsCCtV4svgL4o24YCpoY7K8IIZcfltp55cOkcaosgj9txPQjwko MFJkKVwIQlmtRMkM5D+bDl5u78i8Wibyoc+EkCtNL1nZUn+zkEuvlqCYE0Zbw90OEHoHqgJXM3iQ mJfkGstT5e7p6TIXP17bRkTgXmZjoeCGQakgB43eW1AGlBQ7/LCzX2x7ibbeMuIZdIfRk2dY7Qj3 MqszaIjglKvWQt1ZpwfrOG/xEaGktSzk0TCKxdyZjj0+uwRujJJrxIt+YQ6FiEMAmee6Q92O1nDD XR1OK8PXXBLh4fwDbIt7VBnT6qCsITu4RvSZY9SxsjuGVzh1KsUBSIs6pOM0vAmATx5wvH3rQLaG 0ZpIbht7dJ9srw/ZgknuY6hgxcwGn7zouTYKrxV6ft064MgeYjjiptBtAzZeC5S6FqyxHVT7o1aJ TQwZeeBHhUoeZ+ToB1j4/+XvYXg/q++hil9WgAexAK8ELxl8bJtrxOluFe6/zqOIPRQqR6T+mSZ/ t1gTmEn2Bbrj0I9W6A7KJ8prhRfNh/Zvni/y83y0SPvFaJAuZ4NlOpuNh+li2VsW+fB8ng+GX5Nb /zB+iR7eJ3Jl0uXl0/TtHxhU+S7qiSztT38nN2GIvRc2Qe+t288AWY5BzOfjk7wYzdP5Mfo/WIz/ TGfLk2G6HPYHg2I+mhX986++lzseTKhh4Uq/i+0qLj5qERtOjbKqckd4G/a9ZqbVDTNa8dBuHvf2 PeuGIGnHo9GgNx73brOEvsUxeOsTv28jqTAfiP60CSxBY5jkIixp7IcjSQ4yPng8+B8AAAD//wMA UEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlk ZUxheW91dDIueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD 4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhy jjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE 4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3 AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxzjM+9CsIw EAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3v Ndyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17 Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt 1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhAIbNcbH2AAAAeQMAACwAAABwcHQvc2xpZGVNYXN0ZXJz L19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8STz2oDIRCH74W+g8y9urtpSwlxcymBQE8lfQDR WVe6/kFN6L59paEQIQ09BHIR/Ol88+Hgav1lJ3LAmIx3HFraAEEnvTJOc/jYbR5egKQsnBKTd8hh xgTr/v5u9Y6TyKUojSYkUigucRhzDkvGkhzRikR9QFdOBh+tyGUbNQtCfgqNrGuaZxZPGdBXTLJV HOJWLYDs5oD/YfthMBJfvdxbdPlMC5Ymo/BNzH6fC1ZEjZkDpad5dWlBSwtg580er2mWSy1WTj/J cW0vaTxdU8PYMpxKw6Iy4pi3NDj9l0Z7yzldfKDulmbdrxmrPkz/DQAA//8DAFBLAwQUAAYACAAA ACEASUGHK5QCAADjBAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbIxUzVLb MBC+d6bvoFHPxrHj0CSDw8RJ3OkMBYbQ3oUtEw+2pEqym7TDDK/DI7RX3oQn6Uq2GgocuHil9f59 ++3q6HhbV6ilUpWcxTg4GGBEWcbzkl3H+Otl6o0xUpqwnFSc0RjvqMLHs/fvjsRUVfkJ2fFGI4jB 1JTEeKO1mPq+yja0JuqAC8rgX8FlTTRc5bWfS/IDYteVHw4Gh35NSoZ7f/kWf14UZUaXPGtqynQX RNKKaKhfbUqhXDTxlmhCUgVhrPf/JemdALRXFWE3GFkz2YIiwDNAnq2rHDFSg+JbmVOrU+JSUmpO rP0kxVqcS2t62p5LVObGtXfByO//9HbdnRlDOPnPIly7I5luC1kbCU1A2xgDVzv79Y2SbjXKOm32 RJ1tzl6zzjar1+x9l8R/ktiA6yp8iSpyqFZKkIwi+XBvWvVwj/IGsaZ+uJcc5RTlJRFclbpsKRru O+CQKXHCsxuFGAfktlddJ/6ZdP0xUmx6cmD+TpsaxvNnjL83RGoqMdQEkILQ+XdO9rDH4jqutwnP dyb9FchOS6aV0mu9q2h3E+ZTAN0G7K8wXIarcLz0hotx5KXzKPXm88nIW6aDdBGOVkkYjW7d8KgK ZgNagE0ICeFhmGCpCumlF1B1rRcVJWxPiZ493v3+8Hj3x7CgLReQ2FLL8nMiycXzGB1hwgJ0YPyO LSvcRMJonCjdn1AjS4CSJJPDcDFOvCQAFNFy8tGbp4cjLx0No2iRjOeL4erWTHYQTTNJ7Yp8zt1y BdGL9arLTHLFC32Q8brfU1/wH1QKXtpVDQb9crWkivEkiAZRNAwnjiuozUlbraF/bRoAspJfiDhr 7axAMqB6YVUC3hI3KnsbA949TrO/AAAA//8DAFBLAwQUAAYACAAAACEAHR7OwRcEAADqDgAAIQAA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbMyX3W7bNhTH7wfsHQjt2pVJfdqoU8R2 PAzI0iDJHoCV6JgYJbIk5dotCvR18gjbbd6kTzJ+KfKaNAjQYfCNSdGHh79z/hR1+PrNrmFgS6Si vJ1F8NU4AqSteE3b21n0x81qVEZAadzWmPGWzKI9UdGbk59/ei2mitXneM87DYyPVk3xLNpoLaZx rKoNabB6xQVpzX9rLhuszaO8jWuJPxjfDYvReJzHDaZtFObLl8zn6zWtyJJXXUNa7Z1IwrA2/GpD heq9iZd4E5Io48bN/jeS3gsTraaakQg4M7k1AzA6MZFX16wGLW7MwJJiwRXVdEtATYCZIImzUeJG EmJ77fZXKa7FpXRTL7aXEtDaugouIhCHf4Kdf26toenF33i47bt4ulvLxrYmKWA3i4x2e/cb20Gy 06Dyo9XBcLV5+5R1tTl7yj7uF4kPFrbBecLHUaE+qhubCQCH4HpoJc559acCLTdBuTT4IB9MfOi2 FZugQ6XljZeiT4g1cJ0B6cmc5GVWjn2oMJsUJcq+SU9RFCi1FjZoCMcog5NHoXvnYqp3c17v7fR3 pvX64ClT+lrvGfFPwv44FGkMGLYv0lqOVlcRqKnUPrWq0QtGcDsIoE8WjL7vyEdANGjMC7imps/C lrI02jE5z6StL7HEV99fwAcgHH1P7QJ5Xr6kl++ad2rklgbov9FQde+ChrTeHcx5uZYwKWAexEQT mOaZdzKImRslndxOzASmafZ4H79MTNffMmjfxwbLc5dV2tbmuHBdzG5btzEj56G7MMej91CT9VVI E2e0XlHG3IM9hsiCSbDFzBwtO3uWGFVpq/1IkY0tuqd9sPZPg6N4WCB+IAywaIBNs2Kcw+MktpiB OBmIjaAQHSmxxQzE6UBs9yMsk+NEtpwBOTtALlGJ0iNFtpwBOR+QESqzZHykyJYzIBcHyEWKkvxI kS1nQC4H5AROJilKjxPZcgbkyQFynuVpmR0nsuX0/YPvyQ+XBoJ3si8OpC0OlKs7aqKAevhgK1B3 JkXKzPi/yoa8LxvOlMAVAfL+zhbM93cWpe2a+zvJbXlcH1TLvhD78bKC1RddY9L2cRa977DURPYV hi9cvl9i+PVfXNOtTdFvg/2E0BKdoXI5ShZlOlqdpqvR6ekkGy1X49UCZWdzlGaf+yuEMnuEmBS4 bfVI9qfE/vrlr1++fvl70M4s/Jx6z2jmmv4eYoqkc6VDD3SSmlDm80mOFuV8NIcminQ5KUanqzwb rbIkTRfz8nSRnH229xmYTitJ3EXpt7q/YsH00SWroZXkiq/1q4o34bYWC/6BSMGpu7DBcbhiudcL lmVRpEWehM3n4PrW4Vr9r20GTMvk71i83brNYlYzWi/ckDBXyn6vDDY2+v6OevIPAAAA//8DAFBL AwQUAAYACAAAACEAxzlRIDYDAABYCQAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQy LnhtbKxWXVLbMBB+70zvoHGfjRPHCUmGwOS30xkKlNADCFsmam1JSHJI6DDDccoR2tfchJN0JVuE 3w5pebH+Vrv7fbvr1c7eIs/QnEhFOet59a2ahwiLeULZWc/7ejLx2x5SGrMEZ5yRnrckytvbff9u R3RVluzjJS80Ah1MdXHPm2ktukGg4hnJsdrigjA4S7nMsYalPAsSiS9Ad54FYa3WCnJMmVfdl6+5 z9OUxmTE4yInTJdKJMmwBv/VjArltInXaBOSKFBjbz90SS8FoOWn3zxkheQclnVvF3DH0yxBDOew cUK1JIhoFHOmCSvsuRInkhAzY/OPUkzFkbTXDuZHEtHEqKmueyioTiq5cs2MIMyCRxrO3BR3F6nM zQh0oEXPg6gt7Tcwm2QBDpW78b3teHb4nHQ8Gz8nHzgjwT3DBlzp4VNUoUNVklJfg3NOK7HP4+8K MQ6gLA0lyDuREroZxayKgKY6I06wPLWTtT+ONb0Y8GRp7JzCWO7ibqb0VC8zUq6E+VhfJAhk2CR5 Kv3JMSR5rocZwWxNjN4dZvS8IJcmwDmUREphDqq0AWgI0pYmq4+w5AhLfPxYbcmksF47DwNH48tk NhyZYyVwTJBc3ZgcXN2gpHDJhsL/pZgmi3syb8OuuZHNszWNm9MteCEd4XCNKPgDLc0A2DUkNzET qGgQfhCFkujHfpT4NvFjRIoFXf3MCWJ0TnDxCiNlKDYxciI5VRtaaWxs5UuBtdzQSrR54Cg7L160 8ubF0fpbcbAiX91IjhLIEooFV1SDS6j5Nr8j6HkHRQ4sXPa88wJLTaRXlVGZAm9WRyk0GQP2RxiO wnHYHvmNYTvyJ/1o4vf7naY/mtQmw7A5HoRR88o1LJXRBH4Nuffq2N1e//pwe/17HTEw/I8xs4Pr fVCn+0pXM1RIClAGg04rHLYH/qAOKKJRZ9vvT1pNf9JsRNFw0O4PG+Mr00PrUTeWxLblT4lr6PXo SUvPaSy54qneinlevQ0CwS+IFJza50G9VjX0OTYF1Gm0Gtu1KLwLFjjnRuuuif/UMABjJj9jcTi3 yQLWINZDuyXgAeNyZS1j0LsX0e4fAAAA//8DAFBLAwQUAAYACAAAACEAtnzx1AcKAABlQQAAIQAA AHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxc3Y7buBW+L9B3ENTLrmL9UH9GPAv/ jHcHmKTTJPsAtESP1ciSlpLnJ8UCQfYR+ga9ai6KFmiBom2umjdJHiCv0HNI0ZY9lmeSTDCZhR1g RFM0efh95xyeQ3L34bcX81Q7Y7xM8qynWw9MXWNZlMdJdtrTf3g2NgJdKyuaxTTNM9bTL1mpf3vw 6189LLplGj+iZcW4Bn1kZZf29FlVFd1Op4xmbE7LB3nBMng3zfmcVvCVn3ZiTs+h73nasU3T68xp kun17/lNfp9Pp0nERnm0mLOskp1wltIK5C9nSVGq3oqb9FZwVkI34tfrIok3/AxmbOkHMNnoaRrj c3Iq/z5hUy2JL+C1aWIL2hXDsGHKtTOa9vTJqaVrnYOHnbp1XcJfl8UzzhiWsrPvePG0OOFiiMdn Jxw6xSG1jM5hbNGDeFO3k98zbCj7XuvhVBVp92LK5/gEvDSQEmi9FH87WMkuKi2StVGjOpr9blvr aHa4rX1HDdJpDIyTkxJenZWtZnVYFjRiGn/7GiF++1qLF1qVVJxpEjLxIzWRsjjOo+elluUwUQGN nPiyiYQDn8VMqy4LGAA6S5lqKN+KwkrGrSAR1wcNEHO3TTcMNuEKbDv0sAGC4Dm+SZx1JGi34GX1 HcvnGhZ6OmdRJZSDnh2XVd1WtRFCSVGKbnUxyONLbDqBJyAGNgkdzHL+QtfSo6zs6aFFLJh+Jb6A rKava7z5ZrL2pkqHeSrIolkE/fT0qOJCmAwsoL+o8mmiRJJj4ru0rJ5WlymTMy/wj6jnIFJK0SlM uTF+omtxwiupC+W8GqaMZiuNqQ6GafLjgr3QWKXNwZlMEyhDp4JlHLASw4qeWRafUE6ftA9Qwybw UjgJ6Hbrm7NT34BUptm3o28In167g89SOwsKlkt26Z3jhIT4UvCvXPE+QdfQxaVnUm1F7ecoX5Ev uFI/6ICVsJJd4mPJPxRgZYDGazoplW1TIsnsp0k0YouL5O1f5kzLkjNGFzcYTjL8acM943lSfuR4 0pV92ni/X9CKf+R4Ssk/ieAk+3HROt4XdCneLpeSLeZvX/Nci0GvElrkZVKBcJp7Oz4Goq3Hizng 8aKn/7igHOKu2uVIJD/K5QS2H4aBJXwOCWxCzHDD55AA3IwrXY7tOwGpR7lHS52ckHIyonyWWqiA ND0FfZKLYcymqCcIK3pfGcrlaRKPkzTdEtdVFzVdG80wBM0EV1PQjJ7+23lmpJVqKkcRxVoIWW4I J8xjmsZC0f5o2yP70A5GhjMMiDHuk7HR74euMRqb46HtHg5s4v6kL3UjiRmonxD+ii1dtaA6kESb effy37959/I/KwOaYpzbbkI7DadIolp3k2jTdHxlOvCuWkCs56/som5OsQNlGcMZDMv6ZQF6tW4i y85FGLwAAxxBUoHZS8MQVJtJmhSKIixrvMvmEwYC8aPYFYCByoPGKuVf8AThD/qmGdoDY+iaQ4OY /qHRD4lv+OahT0wSWENr+BP+2iJdkACEpumoSFQmZJEr2cc8iXhe5tPqQZTP6zRGZUOQeFhmnXgI JVt6KJBIPYWMuH7CLIRe8ugJYCOJLCGuqqKZUCGYrXqBSqreYPqxBENaozY5f5THwAmFFVpgseEn fJc4QR2bOPAJNryE5VqhjbXoJogXONZnBiYYMKCEte1m6zVoMaJqG2WhGR4Gh2AsxPYOgbI4Nvrj ITG8seW7I2c0HI4sRdksicFgRLeCMcy0Ppu6q56Dn06WfmMsPltcR2ddoBXta5OzbGIO7NAYe4Fv kClxjdA3A8O0wgHEhiQko/H65I6TjN3i5LRz8L2uLS2mfZam+Gx1kPMEtwrSZA7Lz6oV7c4YjQ+z uHZINEnrLw1ccC7bzUGtKp2l82lfvAPlgZ4hroP8QpPqvFx3NXRoIoZfX6RrV8R5fo7Clu0rdos3 aq7G19ocomzLldkPTdvftDngxLXDeml2TB8+t2tza1Q3X308g8Jcdy3955xCAJTlGasxx1xhvCNX aC7jjB5nA/5cuEukCDT2ZJHhciGXcbXo3s6C3ucJTXWtoFlewlfTNgcmWB481T8IkYoEfO2YzpMU yYGKaEZ5yYRINY200eeHN3/98OYf2oc3f3//6p/vX/3r/c8/v3/1tyuDmKYPJdcMrhvEsGypLi0h hyjaiN2c8mPw7wQ0CSRLMrAy/L0duD5W7KG9ObSIZw2ts4LWsogjTGSFrR2ILH6P7c2xRUBrbEkD W+hbbJnssf0MbBHQGlt3hS10ChHuHtvPwxYBrbH1Gti6FhFQ7sR2mmdVX2SoE1qy7ViXRTTAMwVR OoFgfz1tWHvdn4pgsq1h/XrP3oo9pKxmz2+wF/qWSIb27H3V7CFlNXvBij0HQp3r1+M9e3fNHlJW sxc22AsC7/oVf8/eXbOHlG3f2VxL2KxNbmTKXe/F1gmqxHTjfIBlxg9PdY2m1XHzu9i+FWHL9pMD cY5d3jbMeN4gpawOjjJIjpP5NxtHER8rPipumuBNizuci/aIXmo2ubWpYCJ0h9OpZr8EUr7RbNPy rzvp+trsYyVg+8GBeKgrMWprT5Tq3c/BIPTsYTAwBhYZG2QU+kZ/7LnG2HUIGQ6C/tA5xN3PwiLd iDNxnecoVheBbrrpWeTnjBd5Iq4Vre/HE9OD5cbz6t1tIZt6qo1IdUMoSvkjWmiTU6unpxWeYl1A KX6Op1anNtbZWGdjHZRoFMGCBi3qgqqxVc2yjaNqHFVDVA1RNa6qcVWNp2o88LmgxOB9xQNXy/R7 WaFK9XZomcbH9DJfVEdxTUWjRl7lsYhPAsfDewi8izX8KFaXd1obO43G6uZFa2PSaFxfs9km2Wyq zWIuV/9KPuOl/qGmiVWoFGW8FdRyFijOC2H5eUYnT1/Ig0XPEieLoq/mwiUW7LZMWG0d3zDGmCwe 51l9/6FxEEmEpT5nHLeRb/dQ8g/qUHIjRMA3jKobX01PgG+icudB5jq2hdi2vQL0Mgz3Q68Rx6kK yUP6xVmw1w4oGkyMIXi86gAFHpPFEByb8G49/d3LP9fVDcYcEZx+EcaWx8hXGMtaGcuuYWzLPrBv k/V9YOHt7hErf7rKii3S9XvASusWsu3hWVAz6XEdXCLutbHYX8693S4tLbvPbhj6eNB9n2nZZi2i 03tAS+vGtedjjHF/afnff+8xK61b3k6AqcEvzYfdF1pa97LNAC8R7Gm5G1paN6n90N3Tcme0tO4+ u6a1p+XOaKm3ldcyy6KbVzPGl3km/OJEklfPcMu91VWb9awUbw7fOpPNm8X3JRHZnh4qIPYYtSdr eDHd3mO0O3NyfMsKcPtyD1JrHmMFdmDjf1m4B2lHWoHrr7kHaXeQ7xPb8fYg7Q65rTAkuPe5B2lH AOy5HgnwTGkPUjMcbUag4lxTnTbJsyr5v0c4+D8AAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAA ADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHOMz70K wjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtg ne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHN HXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIB qm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA4txdvRgGAADiHgAAIQAAAHBwdC9ub3Rlc01hc3Rl cnMvbm90ZXNNYXN0ZXIxLnhtbOxZ3W7bNhS+H7B3ILSLXQyurV/LRp3CduyuQNpmSfYAtETZQiRK JSnXyVCgj7PuDbbbvEmfZId/tfPTwO68AV2NAObh4dHh4cePR0fM02erskBLwnhe0YHjPuk4iNCk SnM6Hzi/XkxbsYO4wDTFRUXJwLki3Hl29P13T+s+rQThLzEXhCHwQnkfD5yFEHW/3ebJgpSYP6lq QmEsq1iJBXTZvJ0y/Ba8l0Xb63Sidolz6pjn2TbPV1mWJ+S4SpqSUKGdMFJgASvgi7zm1lu9jbea EQ5u1NO3QjqCFSbnRSrb2Vz/npEM5ekKcOp0XLDAfeWZjAuGlrgYOLO566D20dO2sTaSfJrXF4wQ KdHlc1af16dMTfFqecrAKfh0EMUlQKw8qBFjp/tUGmrftzzMrYj7q4yVsgWIEEQJe3mlfttSSVYC JVqbbKiTxeuHrJPF5CH7tp2kvTGxXJyO8P6qPLuqCa9xQhC7+cAJW958QClBxY+EtsTNH4IgjZt6 0q6G1ydVcskRrWC1Ch+9+k8mGhPZ1gskrmqYZZEy4Ov1wHnTYAbEtM9oQyWsY94BNK/XdeOOgSII u56UN/HA/Zpx8ZxUJZLCwGEkEYoieHnChbG1NioUHUDdF6tRlV5J0xm0gBscR3CwqNi1g4oXlA+c nhsEMKFQHTW9g9jmyOzWiCjGVbFeRMHFubgqiJKXhSsphYs5nPdCRZiS7AxUEjZ3Y2HGVMsbLmoF DE1PMcPyuQLLXJGx1vTMPlqrBdqFqbU+ThP/UZpglGLgiLcfjqTCMad4d3b4cRxErv8tcYR9MUey IlWb+9soiMOJG4St0agzbvU6QdQajqDrd91RbxgNJ+Nu9M6x2wNbLfKSTPN5w8jrRiPE7hKNl2Jc EEzXSxBHnW4b0rfXcbsyHqGiymQK3ztfg8fTWl7iOQGRozTHdcVzkS+h429DYFqdVcJI4wXESoa8 BqJsyW5epC/KuWG4PjE7MhxebjoJRnGo+HyL5VGnFykDyXI/8Hqq809ojqGSmOZFYYhI0VvJsS64 VQBVRZ7KYet4/bItcHJpp94wk1Sk/9npwTQBPwMnEfplsz4HuvdvZMvwEfZxlFSlrIxwDqUNCvaT MyVud16simCa0TsRzLJKJkkf/u4xLAziSGlVHnXdwJLwq0qkG7svcykkyrWNgmWrjDYu8jcNuUZ1 1TBUQlme5VBtF7CxXE4C+aVBAoAjUoASF4zXqU+nZR3CrTj0lu8SxzFpVvnN7yVBFDIZbraYROee XSa5YFXOd5xFE3CXWX5psGA7zqJP0U4bl9M3zWdn2XtGiD6fERpU5ySV76VavpTC/SSETKa7+/lA A/UFBXcMacGThdX/oqSyL4XZ11OBdx9jEG3Kmw+skiTaKGhQtB8uQcnyqikfopMm6xdX6N8qqfZQ skfxcTQJw7g1ifxJyz2Wxft0ErQ8P/aDMBoOj6fdTyU7h9qLAEe2r9Q/vv/zh4/v/9pHma4ae7cC eww7ZCTUsFx+fYx6kTeOR62RG0xbwXGv2xpOo7A1Df0gGI/i4difvJP3PW7QTxhRV0EvUnuJ5Ab3 rpHKPGEVrzLxBEotcx/Vrqu3hNVVrq6k3I6511KFqht0vdD13Uifl7YKzrYqXHlAzF1TUrCXuEaz uQvJQcD5ESuQ0kuQZnNP6jyp86QOJJwkUOuBhRGsxrOaTza+1fhWE1hNYDWh1YRWE1kNxL4ocnoJ aMjGQVlV/KwVVjLZYJGhRcrUbsNbQrWpsJtvrg3vEbfE7ESz3KRFyDXZBZ6dX6uj0IlcdRaUCcEn dMQuVXaR937UdGFIfi/ldH7aUP3B9OA5uCRM3nVK+d4Xxp0LPQD/gS8MCFtOq9ifQbIcOD+VtFUI m2jwnRGC7a0avzOScOteR3n7hCrRW8NjgThgZIExGPlrjCCJut4BI4ORBMZgFKwxcv2u68YyDxxA MsgYkMINkGIv9oIDSAYkiYwBKVqD5Hlx6HcOIBmQJDIGpO4GSN3A86MDSAYkiYwBKV6D5Lu9XuDJ SuQAkkHGgNTbACkKoyCWxdkBJIOM/ircqCltV/9n+uhvAAAA//8DAFBLAwQUAAYACAAAACEAtM9Y GbkAAAAkAQAALAAAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxz jM/BCsIwDAbgu+A7lNxttx1EZO0uIuwq8wFKl3XFrS1tFff2FnZx4MFLIAn/F1I373kiLwzROMuh pAUQtMr1xmoO9+56OAGJSdpeTs4ihwUjNGK/q284yZRDcTQ+kqzYyGFMyZ8Zi2rEWUbqPNq8GVyY Zcpt0MxL9ZAaWVUURxa+DRAbk7Q9h9D2JZBu8fiP7YbBKLw49ZzRph8nWMpZzKAMGhMHStfJWiua PWCiZpvfxAcAAP//AwBQSwMECgAAAAAAAAAhAE+dfMTEIAAAxCAAABcAAABkb2NQcm9wcy90aHVt Ym5haWwuanBlZ//Y/+AAEEpGSUYAAQEAAEgASAAA/+EAgEV4aWYAAE1NACoAAAAIAAQBGgAFAAAA AQAAAD4BGwAFAAAAAQAAAEYBKAADAAAAAQACAACHaQAEAAAAAQAAAE4AAAAAAAAASAAAAAEAAABI AAAAAQADoAEAAwAAAAEAAQAAoAIABAAAAAEAAAEAoAMABAAAAAEAAACQAAAAAP/tADhQaG90b3No b3AgMy4wADhCSU0EBAAAAAAAADhCSU0EJQAAAAAAENQdjNmPALIE6YAJmOz4Qn7/wAARCACQAQAD ASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0 NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKj pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QA HwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEE BSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZH SElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0 tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9sAQwACAgICAgIDAgID BQMDAwUGBQUFBQYIBgYGBgYICggICAgICAoKCgoKCgoKDAwMDAwMDg4ODg4PDw8PDw8PDw8P/9sA QwECAgIEBAQHBAQHEAsJCxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQ/90ABAAQ/9oADAMBAAIRAxEAPwD9/KKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKAON1jV7mDW1t4pCkFhaSXkyjrJjKqh9B3qG+8YWPhXw zp2ueLJyovp7S23Rxlh51/KsUK7VyQNzqpPbqasaxpFzca0lzFHvt761ks5yMZjByyvjuM8VleIf ANl478E2/hLxW01uIntpRJZzGKVJrOVZIZI5AMghkVulaStyqxy0+b2jvt/w39fecJrn7TXwk8Ne K73wdruoT2d/YXK2srPbSeR5rCMnEuNpCCVCx6AGq2g/tUfBXxHPpFvpetM7a3PBbWxaCRVaa4Rp ERiRhSAuGz90soP3hV+T9m74XXfh/wASaFqtnNqcniwBdQv7qTzdQlASJQBcld4H7pWwDjdk4ya5 6f8AZD+B899f6gdKnjlvXlmQR3MiLbTzGMmW3CkBHHlJtPOMVmdR3XhT4yeDfidpeoS/DvUvtVxZ WcN6xaJgFWZ5UVGDYw+6B1Zeq8HuK6zTdZuJtbtQ8ha21a0WeND/AMs5FA3AH0I5+tcX4Q+CXg74 X2mqyfD2yaC91WytLKUyylhILRXSORsj/WbZCXbGWwM8122naLcQ63bM8e210q0W3ickfvHYDcwH YAcfWtI2s7nLV5udcvl/X3X/AAP/0P38ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooA//R/fyiiigAooooAKKrXd7Z6fbveX88dtBH jdJKwRFycDLNgDmuR8I/EPwt4y8LaT4u026W3s9ZtVvIEuWSKURMu/LLuOMLyeSAOc1008HVlTdW MW4ppX83dpfcn9wnJXsdvRXmPiD4ueDPDfijR/Ct9dBptWtJtQNwJIVtbWyhKJ588skiAI8kiRps DFmPTaCR3F5rVjZx2MpLzx6hNHDE0KmVSZAWViVyAmB948dPWtauWYiEYSnBpTV15pNr9GJTT6mt XyD+2H8S/jf8MPCGgax8HdIlvLafURHrt9aaY2tXmm6eELGeHT1mgM3zYDHfhBzjkEfUd14m8N2M Sz3uq2kEbz/ZVaSeNVNxz+6BJAMnB+Xr7V82/Ee5+C/xo8AeIfF3jHTtUuND+HdzqDR39jdzWFw8 tgrx3bWc1lcxTFcq8ZDlA5GQCu1jeHyjFVVzU6bault1bsl6t9N9+wnUS3Z856T+078Wvi/r3w3+ EXwR8X+HZdU8UeHLzxJf+LbnS7hbaW2trx7NYLPS5J1dbkOp89JJSE2sRxXTePv2ivjD8A/ib8Hv AXxQki8Xx+JbfxG+sv4Y0S5uLm5NgImsmgtEeaWMqJMzgF14JGB09n1r9lP9lzxX4M8PeBLjw1aW +m+B9y6WbK8ns7zTjcNukC3VvMlwplckvukO9jlsnmus8M/s9fArwDqHhTWtA0lLC68CjU4tLmkv biRoG1VQ18ZGmlYyvKF3M0u5hjIIridGadmmVc+GR+3V8TtS8O+MJ/Dul29vqmp/Eiz8DeGf7ds5 tOj02O+tlmWfU4WKy5jw3ynaSSo9q++vhDonx30F9UtPjR4t0bxajrC9jNpmmSaZNEx3+cs0bTzo 6fc8tgVP3tw6Viar8Af2eNf0XxV4e1zRLHUtN+JeoLq2pw3Fw8i3t6yqqTwkyZjfEY2GErjGV5zU /wAMvgt8G/2ebueDwNpt1Y3HiFMXN5d3l5qDGKxVmRZLi7ll8tEDtsXKrknjNVHD1G+VRd9fw3C6 Pm74P/FL9qL9o46n8VfAviHwz4T8F6drt3plvod7p017ez22nz+VM95dLcR/Z5pACyosbBQVJyOT 6hP+2r8MLbWLq0l0rWBpMd5rWmWmr+RD9ivtR0CCS4vbWD995wYLFII3kjSN2UhX6E6eqfsi/sv+ IvGs/wAS5/DsQ1PUphqVz9l1G6trK8niYN9pntIJ0tpWDYLM0ZyeWyTVXSvgr+zd4p+JnimLSvDc 97qFkbuXUJVnujpNvf65AUvPIj837PHez27hpnhQOFkBZgz83TwVWanKMXaKu/JXS1+bS9XYHJHE H9vrwLHpNxrM/gLxZDDb+HLbxhhrayy3h64yGvxi8KhYyCDGSJTwVRhkjsbr9s74d2njy58HNoWt vp9jqujaPc64kEB02C71+3iuNPD/AL/7RtlEyKWEJCMRuwCDXXav8Bv2eLDSr7Tdbsbe0sofCCeE blZr+WPy/DcRO2By0oKqCT++JD/7deVeFv2WfhZpfxb8Z/FbxjqVrqmny3uja3pFn9vuEtdOj0fT 4rWG4uoPOFvM0bRGSKaRG2dQcipWGqNJqLt6f13C6II/2/8A4XP4WXxjN4Z8RWmk3epDRrC5ure2 t4L/AFMTzQvbwTS3Kx/uhA8kkjssapxv3goOj0/9t74U6trvgzQNN03VpJ/GtlPe2zSRQQKi208l tNCPNnQ3E6SRNmK1EzFMOoZWUnsoPg9+z5f/AA6h+GsGniHwr4cvk1eyuFvLiEW17dTSXS3VpqCy iRZBLK53Ry/LuKdDtrU1v9nT4M6g+ga34ohvb2Lwm63Vo99rWoSwpOjvKl1KJbgpJMjyMyyyZdcg AgKoBUw1SD5ZRaf9f5gmjwnTf22/B3jSHwB4u0C4uNA8N61q+qWd+l5bWt3K8On6VNfyCU2147WT RhNzq6NLlShjAIatuf8Abx+F2n+FtQ8U614e1/TUttF07xJZ2s1vbm51LRtVvI7K3u7ZY7hl5lkX dHK0cigg7ea9J0D9mH9n3Q7+xu7PSPtuoC+n1hJr3Ubq+uLm4ubM2Eksr3E0jTobVjFtcsgU5Azz XPj9mb9lfSPC+saVdWFuNHvYNP0y4e61a5lFvZ2lylzY2MM01wzW1uk4Vo4Y2RScDBGBShh6knaM W36BdHq3wi+MmifF+DxGunaXf6HqPhPVZdH1Kx1JIknguY445hzBLNGyvHKjAq56kHBFev1514U8 KfDzwTq3ifVPDIhtL7xTfJq2qn7SXMt1NFHAkpV3YIHSNFUKApxwMk56258Q6BZXsGmXmpW0F5dO YoYZJkWSSRVDFUQkFmCkEgDOCD3ojh6jdlF/cF0bFFcdL468P2/jf/hALiRodUaxjv0L7VieOWV4 VRWLZMm5D8oHTmumjv7Ga7lsIriN7mAKZIlcGRA33Syg5APbPWrq4OrTs5xaur/J9fQFJMt0V4hZ /HrwpqPivUvCGnadqdzdWY1BLWZYEFvqVzpRUXltZyNIN80LNtIcIpIbaxCMR2fw8+IOlfEbR7vV NNtLvTptOvZ9PvLO+RY7i2urYgSRv5byIeCCGR2UgjBrvxnD+Nw9P2tak1HT8b2/FNeTTT10IjVi 3ZM7yiiivHNAooooA//S/fyiiigAooooA8C+PHhXWPE0Hhi60fRk8QyaHqLXzafdRxy2FyPs8sAW 4DupBQzeZEwSTDoMr0I+aPDHwP8AEPh/wjqVnceDY9S8QvoWj6XYXF5p9ldQWsumwyRzFVmnbEco chcKeMb0YDaf0Uor7nKOPsXgsIsHTinFW3vraXMk7NK1737p2d1ouaphYylzM/MiX9nTxLfeGU0r UfCQmvLHTtQsrNpbW0njXz9aTVrZGJmQiNEVoGCKMBiUXB217Trvgvxnr8WjTvYa/ZPaX1lePYR/ YDp1gtrbywsmmqrxyJzICpkJHHRelfZ1Fehi/E/HV2nUhF2cmt9HPWVrvrZf8NcmODitj8zPD3wC 8YaF4d0u0l8Ew6hqWhahpd3H9oSOW0v1063uLZnnjeYiCWRbjflFkJZAHdgFK+hN8I/EUXw28Q+C 9L0/XdLk1lPES/ZLOLTotKkfWbi5lhkuIvMMzPCkyJlZAP3YABAGfvGitcZ4q5hXkp1Ixb5lLq9V e27eiu7evkrKOCgtEfmj4Y+FGu+LfEXia/8AEvga70zSrnVPFETz21vBHqmoRalKyRid3mjXyoDi aEgyZdI2QqFJaxo3wE8e6RFqWpXkOpeINX1HTZ5pE1Ozsp7GTxNffu7zUmha6ZQj26JBHFtZUUMd pyQf0morer4t5g21CEVF2VtXoru1276317qy2SSSwMOp+Z9h+z74uGkXVpqPhqQ3cFpPbaXKsNtI bJpNak1VHRvOj8soriIeWq8qCAF4HTfH7wR411zwlrmq2GmeJtceOw17ba6illcFTqdsIY4LZbV1 byUI5VlkcjoSa/Qqis4+K2NeKhiqlOLcZOVtftW5ra6Xt09Q+pR5XFM/O28+BviPWdMnWXw9eeGp 9Q1lrm4stFhtVsY9Gu7eG01HTYd1yhH2xIRJI4RAJcMFyCzXfDPwc8X+G/iTrnifS9N1fRNM1WfV 7lrjS/Ij1O4OqusiRTrNdSWoWzIIhdY2JAUYX59/6C0VlLxUzB05UnGPK01bVqz9Xr8766/FqNYK F7n52eMvgp4w8Tav4ueLQbuWz8S6D/ZstzqMFneX15exJAttcXB81Fi2eSRJ5DBJRsJiV03GnrXw b+IXijxFqWp6l4OtdHsdV0TU9FeDTbO0URQ6hYw26AjzIzP5E8IdTI4GwqESMp836P0VpQ8V8fTj GMacfdXKt9E0l33tFJdkklZaCeBiz85B8IPiA0sGsz+BrOaS2ubC4GhvbwNosy2ljPZFXHm5DAze dG3lMFcEFckMPSPHvgfxf4psbWa20fV797W9sL4aFqqWEnh8/ZI2jNukcUiyrES/mIXMu10Q7MDF fadFctfxKxdSrCrKlG8dFvtppv5b/F57WpYOKTVz4Cm+F3jS68YW2vf8IbHZxPfaNqJuoLWD+0NL GlRwo2naa/2lVWzl8kqM7NqzSgxtuFcnF+z3rtj4Ut9FsvCHmzw6Zo8M0c1na/Zb2/0nVf7R82cC 4JKypuhLkM4DtwRwf0poropeKuYQUYwjFJcvf7Hw9en/AAd7tp4GDPzft/gp44i1TxVqFz4NS9k8 QRaiIpJwpWL+1PL3W8sCXCrLBalB5GXB2xxBViILDT8O/Bvxj4XuPB06+G5tfuvCeo6jKdQ1KC2O oXkGprGWu5pftEmdQheP5X+44CnMeNo/Q2inV8VsfOPJKEbWtb3v5XHvp7spKystb2ulZLAwPgbx f8HfEXiO7u72XTtb1m9Gk29lZX+sx6fNfW9zDqH23zRJBLEqgKAqlFDAjkmug8M+BfGOjz+IrJ/D +o6Umq313fR6/o8djD4gnF3dtdeRdyXDzRskYbywQTlVTCpjFfbNFcVTxHxc6P1edOLjulro9Ol7 dNvh8r6lrCRve58JaN4E+J/h/wAVJqljo1xcaZ4duNe1LQY54YfPa/15mkcXzLdhTFC0koUxfM4c EhSmG9n/AGbfBWs+AfBeo6HrWnHSZLrVLvUEs4wBZ2q3jbzBakyyyMisC7M+0l3bChcAfQ1FcWcc cYnG4eWGqQilK12r30cn3tdynJt2veT6OxVPDKLugooor4o6AooooA//0/38ooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA//U/fyi iigAooooAKKKKACiiigAooooAKKKKACiiigAorwH4x/EPx74R1vw5aeB9CuNYtIZTqGvPFAJfK0q NhE6puePMzb2lQR+Y5ELLs+cEedaz+0N461O7h0jwh4Ta1mkaONp7w3AAuhdWyPbKotSD+6lkZ3J G1UZgGKkEA+w6K+V7P8AaG8W6lqFrpNn8P7pby7NrHsmmmjEL3DW6mWZvspVbYGZgkilnYxPmNMH Hqfwy+It/wCPor86jpI0eawuLi3aIySyMxhlaMOrPBEjI6gEMrHBypAKmgD1WiiigAooooAKKKKA CiiigAooooAKKKKACiiigD//1f38ooooAKKKKACiiigAooryfxj8UtN8E+L7fQ9be3t7GXRdR1Xz JZ44ZHksZbdBFH5rJGdyzMeWGCBkgZNAHrFFfNNh+1N8P9WttObSrLULq91R4ooLNVtxcGSY2qKp DzqoAe7RCxbblX54GaEH7WXge7SWS10LWWWEzbi0MCACKWOBT804P7yaVIwACynJcKBmgD6lr5W1 /wDaE1zQPiZqvh8eGp77w1EbfTLC9SNo1udcaWMSwee/7rZsmwOMq1vNknKip/E/xx8QaNqHg3XI IbOPw14osDetBIglv1cTWkKwrOl0toPMa7UeYzeXHtJZiDxOv7Vfw9uksP7MtLy5lvrhYDGzWsBh B+y7pZGlnVBGDdoAwYhyG2EjBYAzR+0kfEnhDx5eeEtLNnrnhbQk1W3S8PnRNNNDIyxSpEVf93Ig DhTyrKQwJwM2L49fE/QvGN74a8ceEbeK4kNhHY2ljP5pL3Uoti0105WMK0h8xcJlYiA3z5FbGjft X+BdauYvsWm30kMxRWZFgYwAXL2sjykTFWQOFKmIuWVsgGup1H4/eHvDvi7UvCfiO3kjltrt4IJI TGymNLeGbdKGdXXPmP8ANt2YQ85yK9LLcoxOMlKOGhzOKu0uxE6ijueUr+1/Y3+uaZBpOhO1lJJG tzHJLGLphcxq0SwLkBp1cOrQDLNj5W6iutt/2o9I1FLmfSPD1zc2tjb2013O1xBHFbtcrbYSRmbC +VJchJ2OBEEkZvu4PQj9o7wc7QS2+kanPbXV+NPiuI4oXjecRLM5GJtxVI3Vs7fmBIXcQcW9D+P/ AIc167Syt9HvrfzLGa//ANINrHuRIbeeNFUTks80d1GVC5wTh9telLhDMopylRaS16f5/wBPTcj2 8O5ieJv2l9A8M+HfDHiO40a5mj8S299PHCskfmp9iiZ/l52yJIyhUdWwQ6MMhuON8VftXx6WuoaH baFLZ67bQTnbIy3CRTWt39llQohQvn70OGAkOAdnU+hWH7SPga7ksIru0urNr1bfDObZ445LhIH2 u0czbQi3MeZCPLJJVWLDFc1qP7Rnw88Rac+larok0tvqYmSOK7FrKkyRRC4BkhSZ5EV1BKFkGSvX kGtY8FZo72oP8P8APXZ7B9Yh3OK8LftQ6lpUs9p4yjg1uH+1YNMjudOkViHlleFyDsjWYAqJF2qh 8s5OcoX1f+GodR1C7EOmaRHFHf2mmXVo7SLPFGbi7eG4hmljbb9pEQVhAvzR7ZCxISq8nxl8KeGb VU+HOgR6NdXime5m1NUy1vHbC5ibeJ8FTEzFQ8o2EbNm5xXY6B+0jZy2Fsdb0S4mvJYY5iNPEbRl XlkjMimWVRtyoBCs+G3AFgNx3lwHmipKq6W/S6v6+mhP1qF7XNvSv2gdK1Dxvb+C106Wc3l7JbQ3 MbRhZE3TLHLFGXZ54wISZZEG2MMhIw3H0PXgmn/tBeFL3TNW1WbTb20TSmWMJIsO6VzAk7LuWRki 27wgaZ0V3GI2auUk/am8LxzDUX024j0QW7S+az24uHJSymRki87IURXRLK2HJQ7FYA4wo8FZpUk4 xoO69O19Ndd+n6O1PEQXU+pqK+cp/wBpDw99sWxt9HvoyyySebP9nVPKSaKBXVVmZ38xpDtVVLgK Sygc1v6B8d/C3iHWtL0O2sb2GTV7T7bFLIIDCkDCQxGV0mYIZBE3yn5kO1ZApYA5VeEcyhB1JUXZ XfTp8wVeDdrnt1FeQfCD4mX/AMStDN/qGjzabcQrE0zHy/IV7iJLmOFCJXdmSGaPe20KWzjHQev1 5OY5dVwlaWHrK0o76p/ijSE1JXQUUUVwlBRRRQAUUUUAf//W/fyiiigAooooAKKKKACsvUND0XV3 ik1bT7e9e3z5ZniSQpu67SwOM45xWpRQBkQ6BoNo6zW2m20TxqFVkhRWCq28AEDIAbkD1561886H 8YNGtvDtj8RPFGh6dpXh/wAUT25sXs5hdXxe6kAV7yEQoqMCFMmx5DGw2nJXdX07XCS/C34ZT3Vz ez+EtIkuLyXz55GsLcvLLyd7sUyzfM3J55PqaAPF7b9oL4ZzXtn4eu9CuYNN1S1sv7NQ2DO09tf+ buf7OqEpbhY0JJ6hvu4U1qan8TfC+p6B4b1bwd4ftLyfxfJPbQDUk+ypEmmxySuk4jiml8xPJwkA QvuHIXY2PaLrwR4MvVtlvNAsJ1s/J8gPaxMIvs4YQ7Mr8vlhmCY+6CcYyaZL4F8Ez6AnhWfw/p8m ixtvWxa1iNsrli+4RFdgbcS2cZySetAHhGlfH74OpplpNZ2Qma8SPyv7Nsnkt7mdhA0kds7xxFzG Z4ixdE4bOMhguNqHxs/Z91a6nv73RLi+vRay3lwX01jJFb+U0gaVnwqCaBGZcsAyja2GKqfo218A eBLK4+12XhzTYJ/Lii8yO0hVvLgwIlyFB2xhRtHRcDHQVBf/AA3+HeqqE1Pwvpd2oRogJrKCQCNl VCuGQ/KVVQR0wAOgFbUMTUpO9OTT8nYTSe55VrOv/CPRrS1gvfC8pX+zo9be2+xhTZwkbYWmV2VY 5WZTGg+8GUg4AzXnt78ZvgZHLpup2/huS50mRGaK8+xsHNx/oiww20ZG53f7RGpPyhMAE8Hb9PXv gHwNqUNnb6j4d066i0+E29sstpE4ghYAGOMMp2IQBlRgcD0pT4C8DHTBop8O6d/Z6qyC3+yQ+SFf buATbtwdiZGOdq+gro/tPE/8/Zfexci7HzVd/Fr9mzTXNpdaG0CyF7d1bTHQiC3hS7Z5I2AcQokg YAr6sq4BNcx40+Kvw60+6mXwl4Ltrm/0yCa41EXtuIrm2+zZRothZMsAFGRIeHjVFk3EL9F6t8DP hpq3iPS/FH9kpY3mlu7qtmFt4594QMJ0QAOCI1VgfvJ8jZQlTH4i+A3ws8RwWttNoVvYx2cbQxpZ xpDH5TFmKGIL5ZGXYglcgsxBG45f9q4r/n7L/wACf+Yckex4Jf8AxC/Z78TWaWXiLwxdHUrERCSO whnby7h9hMMN3AY942mOQYZVePawB2kKo+LfwD8PeG5E8M+F7iR4LbUJbSOW2kCTR2DSL5jz5kZI 5ZI3VHk5yDuAyM/Uum/DfwHpK2/2TQbNpbaGO3SaWFZp/Ki+4rTSBpGC9sscU/8A4Vx8PfOFx/wj Gl+aDIwb7FBuBlQRyHOz+NFCt6gAHgVo86xjgqTrS5V05nb7ri9nG97Hj/ijxt8EPCuo3Wh3ujtd X0kz2ctvbWZmaZoI7eZlIGA6ql3G3Pq2OQRVF/GHwBfwRc/ECLw+LjQBcQ2dvMlhu+3yNKLeNbaP 7zqJBsG4KARxxgn1bX/g78MPEslvLq3hnT5Ht5YZci2iBk+z/wCrjl+X54xgfI2V+VeOBW5N8PvA Vwl5HP4b02RNQYvchrOEiZjtyZAV+YnavJz0HoKzWaYpbVZfex8kex83H4tfA5vEc+n3Hh8x6ZZ2 Ut7BfyWrKJJLUXJuEijYB1MK28gJIU7sqB3P0WPhx4CDBxoFmGUuQfJXIMpy5B/2zy3r3zSXHw0+ HN3JNNdeFdKme4MRlZ7GBi5hBWMsSnOwMQuegJA6121CzTE/8/Zfe/8AMOSPYx9L8P6LohdtJs47 TzAA3ljGcDAyPYAD6cVsUUVyVKspvmm7vzGkFFFFZjCiiigAooooA//X/fyiuO8d+Frrxh4efRbH U5dHnMsMqXMIJkQwuHG3DKQTjrnivH1+B3jFdUupx8RdUGn3Tbmtt0pJAKjBkMxY5RQpPBwPVn3A H0jRXjHhv4ZeJtBiurW88W3WswahayW0wuzI4QtEFEkKmRlQh8naMDDY7Ljze1+AHj/w1Bv8J/EK 6SeOMKiSIypI0FsLW180+Y4ZIkSMsChLlWJILkgA+r6K8C8R/BXUPEWvLqj+JZbOGNdOTEMP7+4W xkSR1upWc+aJGQEYVdh6Zy+/c134Vi+8Gp4E0W5jsdMhmheNplluJlRSTKFfzEKOc/I4OU5KjdtK gHsNFfP1p8B7P+yxpmran9tSSI28ymJvLeI3EEzbUeRwjssThnHzb5WcEYAr6AAAAA4AoAWiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKy9Is7yxtZIb26N5I9xcyq 7cFY5Znkjj6niNGCD2FalAH/2VBLAwQUAAYACAAAACEAk6p9mLkAAAAkAQAAMAAAAHBwdC9oYW5k b3V0TWFzdGVycy9fcmVscy9oYW5kb3V0TWFzdGVyMS54bWwucmVsc4zPwQrCMAwG4LvgO5TcbTcF EVm3iwi7ynyA0mZdcWtLW8W9vYVdHHjwEkjC/4VUzXsayQtDNM5yKGkBBK10yljN4d5ddycgMQmr xOgscpgxQlNvN9UNR5FyKA7GR5IVGzkMKfkzY1EOOIlInUebN70Lk0i5DZp5IR9CI9sXxZGFbwPq lUlaxSG0qgTSzR7/sV3fG4kXJ58T2vTjBEs5ixkUQWPiQOkyWeqBZg9YXbHVb/UHAAD//wMAUEsD BBQABgAIAAAAIQA0FZTOawYAADweAAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWUtvE0ccv1fq dxjtHfyIHZIIB8WOTSgJRLGh4lSNvWPvxLM7q5lxEh8LlXqoWqlS1V6QemglkCqo1CK1ErSXfpQU VEQqvkLnsbvesQfiQuhDxAd7Zvb3fz9mZn3+wkFIwB5iHNOo5pXOFj2Aoh71cTSoedc6rTNLHuAC Rj4kNEI1b4y4d2H13XfOwxURoBABSR/xFVjzAiHilUKB9+Qy5GdpjCL5rE9ZCIWcskHBZ3Bf8g1J oVwsLhZCiCMPRDCUbMsfdILf7kp2V/t93EPeasq/SeRXJLha6BHWVtxRQlQfMQRHGusPS+qHj3mD MLAHSc2Tony630EHwgMEciEf1Lyi/niF1fOFjIiIF9Dm6Fr6k9AlBP6wrOnYoJsRllqV5XPrGX8N IGIW12w2G81Sxk8DYK8nLTW65LGV1lKpnvLMgcxwlnejWC1WbHyO/8IMfrler1eXLbwGmWFlBr9U XKyslS28BplhdVb/+lqjsWjhNcgMF2fwrXPLixUbr0EBwdFwBq3imUUmg/Qp2XDClyR8KU2ACaqQ yy5DHwkr19qUcJFmZgh3KWtJiA4vFDgCYhyjPuxJ5EVMCGjDiIOtjpIDVxDMPTZLPT6zpEQC3mM4 FpIJQ0MvB2lQ1kXEAWyMGZkL+F4Mozzw+aN7zx/9CA5vPji8+dPhrVuHN793UG3AaJCn+vP2g2d3 Hz278+3RnQ+PfnjgpuB5iseffvbky49///ne4/ufuOHCgv96/4+HXz+5983Th58//e4LB8Uag908 xRbchYRAcO2Siz3qsjx4jWHo8k4ngHjKjT6G4Arad4CbIrDAV8aQQAeujmznXWeyrbiAF0e7lpbt gI0EdgAvB6EFXIejaBtFgQuqROWgnVE0cMtmozxuB8I9l+jGVFybo1iWB3axbATI0nKbyCDDAYqQ AOoZHSLkILuBseXWLdxjlNO+ADcwqEPs9EgHd638mRBt4FCGZexSUEbb8s3WdVCnxMV+He3ZSFkP 7gRCxHLjRTgSMHRqDEOrYjehCFxKtsesZzmcCyalI0JB00ecu2iusrGl7mUo25sz7FtkHNpIJvDQ hdyElFo5R4eNAIaxU2csczGHvcSHlMra3KbCqQS1C0TNZRxg9MJwX8fICncHBjR0sb6GB5Ymk7xQ T0Ys2QGsTh7i6C1t6xs3jr765eij25unDf20oZ829NOG/v9t6JMerg/46TFe8wvtM33u/tiX3b0t xgRtct39udTab8lFPdFE2RUiDuQwEWfhBgzqMWBUvI9F0A5gLMWUtIQBT1gPOIgplxcXvezkrW+/ WBqv16rplVWiodiivlleyF9lMzZ6NtDX5VTQgmIwr7CFc68nrGSAc0oradVmpWUmO6Xpn8SbshwA VO8qSotlI1pmDCTIV343DNKwvMEQJVYbQwLoI8dyzr6SdueJezOfKMcrcTJOThlMnKzKbqqaSGTP wH7NW66Wqx7owbjm9eVZSw7DWPLjqoFAMohqXk8YA4+vxSmLl91ZVSqm6zMGWyJixsU65IGh0o/S FzXRRP9ytaL8cDIGOJrJfFosLJX+RS30Tz60qN9HPfGClck0eUZHArF24O+DLhmxHSj1rpjs8jGX LV/nmpowmdv6iZzZhZvUxvQLoaRmIIkDmGS7evGTWmjgepzpoGc59bLZlO6vaIqq+JMyJZ/Gb5kp KnPlsXPB17ctuYszCFSO1jzKREBlF4oD3Gsxue9rWVIvIMtCqQSIesOtdEV7k75leJgmNwjEDh4A hmWnEwFDaFskdh7DrJR0xaQyEkZJn8nU5bH57aI9RDqqeheV/R4I0m6SOELjpoNmzxNndAeqUP+r BxeTNn9345kIMvTzCss1/dxWsPx6KsyzAefEmY41I65cfeHOM73VxvLyANSXbNyY9Yh54aw21A7d kdEH2T4PZCKeUV1NZWG22JU6m0UjTbH6p05Bmdw3eHbMOTs7RE05++XiXt3ZycjydT6PHK4uzJao Oh6l9xA9m/mbi3Z3pex1ec8ZEbPCYzkzg22mDe5Sf5wMCTctwTgibekk2kF9gP2DNKxTHk3+R8o2 8x0jQNmeES4cT5jgJ5tIRlw+njijSC97GbG+xbkYkIlkgzdRzlpk5ikSvY7L5lDe7TJn9s7rsjkC 9QouEwcvd1niKbXrziQeOhAMNtI/xmT+GkY6ZVf/AgAA//8DAFBLAwQUAAYACAAAACEAMhYGEQgE AAABDgAAJQAAAHBwdC9oYW5kb3V0TWFzdGVycy9oYW5kb3V0TWFzdGVyMS54bWzkV81y2zYQvnem 74BhDz3R/BEpUhpLGf0mmcmPx04fACJBkWOQQAFIkdLJTF7HfYP26jfJk3QBErbsuB7Ho0ubC7H8 uFjsLj4sF6cvdjVFWyJkxZqRE5z4DiJNxvKqWY+c3z4s3dRBUuEmx5Q1ZOTsiXRejH/+6ZQPS0DZ Rr3FUhGBwE4jh3jklErxoefJrCQ1lieMkwa+FUzUWMGrWHu5wB/Bfk290Pf7Xo2rxunmi6fMZ0VR ZWTOsk1NGtUaEYRiBTHIsuLSWuNPscYFkWDGzL7j0hhizC5orsfVun2ekwJV+Q4y5fsBaOChsUxm VKAtpiNntQ4c5I1PvU67k/RsyT8IQrTUbF8KfsHPhFni3fZMgFGw6aAG15BkY8F86fTa90Yrtrbv WFhbEQ93haj1CClC4CXs5t48PQ2SnUJZi2YHcFa+f0g7KxcP6Xt2Ee9gYR1c6+G3UYU2qoXkOCNI XF9JIrbXVygniP5KGldd/6kIavNmZtpoJH/DskuJGgbRmvy00d+otDnRIy+R2nNYpcwFMPbTyPl9 gwUQ085pFY1w6/N3JC0cJEHqd6mI4iTU8mE+8JALqV4SViMtjBxBMmUogrdvpOp0rY5xpXWAD9Vu yvK9Vl3BCHmDAwkGSiY+OYi+buTIGQRRBAsq82KWd5A4/LK680XRGaO3QVCpLtSeEiNvaaApheka Tjw1HuakOAdIpy04CKxTbeUDE9wkpsnPsMB6HsW6WhTCXZ7bqdwEaAMzsT5Ok96jNMEox8CR8Dgc ydU9irRH+vup0kvTqB/0fiTCiGcTpqC52ek/gmWQTmbp3E2DOHQHvWjiDmbzyE2TMI0DP577y+Cz Y/cK9l1VNVlW640g7zdthsR91slazSjBzW0IauwnHtTy0A8S7Y8yXhW6nh+dvNG/k3eDeEVyTWKO 1wT1jsPgQt2vcobC7fl4RrVL+2kcaiL/LyiMmwzswM/4v1P+4scY1Gzq6yvBNInyCnMmK1VtCYqO wyVJ83eb+iE6tXx4dkX8UUl1hBIZRot+Ok0WbhIvpu4iiGJ3kiRzN0zCMJ5Pk8lknt6USEmrnABH nl4Zv37565evX/4+Rlk0g21sYY9hhzoJbUQFoUyng344S6fuNIiWbjQfJO5k2Y/dZdyLotkU/gS9 xWfdbAfRMBPE9OGvc9vBB9E3PXxdZYJJVqiTjNXdZcDj7CMRnFXmPhD43aXCtORRGPf9XhikiaUz OGdH464+IF2jn1HxFnMEbTwUBwXnR+1Ayi9BWq1DjYUaCzUGEs4yuDuARidYJLTIjU7PIj2LRBaJ LBJbJLZI3yJ9B5W0ai4hG3pwUMHoqxawUlcNygJBD2x2G/4SZszVTfd+79o2/gcAAP//AwBQSwME CgAAAAAAAAAhAO/5TlQpTQAAKU0AABQAAABwcHQvbWVkaWEvaW1hZ2UxLnBuZ4lQTkcNChoKAAAA DUlIRFIAAALtAAAA5wgDAAAB6mOojAAAAAFzUkdCAK7OHOkAAAAEZ0FNQQAAsY8L/GEFAAACoFBM VEUAAACfn58sLCx5eXnGxsYAAAAGBgZTU1MAAACOqqyw09YtLS0AAAAHBwdUVFQICAiioqKJpKYA AACy1dcvLy8AAACKn6oJCQmRrbEwMDB9fX0KCgqJpKYAAAALCwuIo6cAAACXtbi53uEAAAAyMjJ/ f3+JoqXMzMwMDAxZWVmmpqYAAAAzMzOJpKYNDQ1aWlqnp6eZt7oAAAC74OOIo6YAAAAODg4AAACo qKgAAAA1NTUPDw8AAACbubwAAACIo6WJpKYAAAAQEBBdXV0AAAAAAAA3NzcAAAARERFeXl4AAAAS EhKiwsVfX1+srKyJpaYAAAAAAAA5OTmGhoYAAAAAAAATExOHo6dgYGAAAAA6Ojqoys0BAQEUFBQG BgYAAAA7OzuIiIgAAACpy86IpKeJpKcVFRUAAAA8PDwWFhYAAABjY2MAAACKpKQAAACIpKeJpKer zdAXFxdkZGQAAAABAQEAAABlZWWysrKPrK4/Pz+MjIyLpqkAAACtz9IAAAAZGRlmZmZAQECNjY0A AAAaGhpnZ2ez19kAAAAbGxtoaGgAAACSr7MAAABpaWl/n58AAAC12dwAAAAdHR0AAABERESIoqWU sbS22t4eHh4AAABFRUWSkpIfHx9sbGy5ubkAAAAAAABGRkaWs7a43N8gICBtbW0AAACKoqYAAAAh ISEAAABubm6cu72IpKYAAAAiIiKJpKidvMBJSUkAAACJo6eIpKeXl5ckJCSJpKejxMafvsKYmJgA AACIo6clJSVycnK/v79MTEyZmZkAAAAmJiZzc3OlxsihwMQAAABNTU0AAAABAQGIo6iJo6enyMoC AgIAAAAAAAAAAACPn5+FpaUDAwOJpKednZ2Hp6cqKip3d3eMqKuu0dSHpKcFBQUqJ4meAAAA33RS TlMA/////8P//7D///8I/////79k//8QGP//////xxj/z9v//4f//1D/////IP9o/////4//cL3/ KP/+//+X/9h43zD//3Gy/5///zj/////n/tm//+n6P9A/0D//+j//q////D/r/f/SP//dv+3MPi3 /////1D4v////////+3/WP/////H////YP//jv/P/who/+r/1/9Y////cP//////30r//////3hI uf/n///ngP+H///v1+///4/////3l///////0f///////+z/OID///RfoBAo/6f/IP////9g+IK6 8AAAAAlwSFlzAAAXEQAAFxEByibzPwAASSdJREFUeF7tfY+/Fcd133VMUcHELVVR1EaECFncVugH 6FELNVJA/RG1thLaWkbGpKU1vKhphFm1+CFiKgXVIJKCERG2ZEWxaMCVWlUQOQgjqQgpVEWrVsht IIpqkP+Vnu+ZMzNndmf27t4feg/ufj/77tudMzM7e/bsmTMzZ2Y6Bufk/9DwmvwHvjsxIWdDQzaR yVmnM2Gzv+DD+kNmM8gmXP7X2+wpjP/3D5cDnUxM8tnkxMQRPvFP0Tco1/vc2dV8st0+B4Ws5pMB QHkIU85OTKzBf1dmz64BMDHxsDmRG7n70ckSPhkIlIucmWLr7Pn/YHjA8cBkT7+m0BMTy/n/gHDZ X+SzBOvPdHNzkufdbt6d3ckRcG+e0y+fHuRTInM8G1vlZ9hiL5cUsjfJOK/8P9Mf50D32kl5rTSn z4GMW+MfRybcHWT/kc3evQODfJkk6J4+hKsb6W9PZ1n3NAWffop+cPoFotC/u+hql4mtXiGdvNyZ n8heMQfZ0xXxiJ4AZ3m309llTolMzNPM0dkf6KxW2euPSjHn5vxHYM5sygmZmWwRYrOnU88cnf1E Z1GKOTYBFRoZnOoszb+5mzPCYzyb5ws5Du5FT5NHmTPReS2VvX1cylpuBQlCXqa0fNvf5XhriRDN /pKXnKNVvGd08203dzpvI3fKlbhHcR7kW+fbbOww+8NpuaeyrTSltdmDSZ3OIcOSdzhkmXmyG/iW BqTKzIlhRyJ7fnpwueuyP9bdjUxwExAIj4FBONvteT8x8Yw5MdnPnZh4ky+tghZMGdD/ByWETknQ QaC/DRJyP13xCV8TXCmX85m5CcExbSCccNkbtrjsr3OEQeALKVxXzB+CynRltMXW3Bm0+Jvum5jY bE6p1PvxfzOdXOAQJ1N9w5eQzua4M8n20uDZ+9wnPjKnnSOu1PPlf7940WYZMDobtNQlaCOw02GL ZJjQNnF4q6FgYsLZyOp1D3obl4EVyw7XVyZ0+8BP4QpKeYqx+bANC952f3Al7TwhZysmJuZygL91 /9g/MbHYnFHtdDf+uzLTCf8fCJTJUXNGD6L+4eRaczIQHAuk2Cr7gXlDoNaCOTHZ0+/T9vIWPhkM lI05uYbLLc+gwg3y7jr+fyuqU9SneX4QoWSR0Sldi3Fg6loOYbj8DFvcJVWN/F+wTLLfRSlvpjuY fGDckD01q9OZR2eniM7mrNwE8JYwZ3+tvXTvwOA7ucn+x2zKkp2ak/F6/DQsW85r1tq8+7+Jcvqp 7veYzrEJOvvvkoqPZ6+YgysqNJ6A7Q48AVlOhiEUABqfM3T2qzsHfPYH+L9AMefmq0yuzKB8mbkX /nDn7sovGwLHJujsM519UPquMOdWY0wiI/q3k+9Arxch95vQQ89TSCr79YnsT0v2yC7PYSTRP8qE XgHnyiYcvdz85CGKQ6ccm6Czny8NLMIzVbwHtppMuKSf7uZ/CisUTS5kD14JdPbvJ+V+GSVBRsR7 CQF3yNwEwbxdhHS6K9F44SdikEHvs09/Vib3/NCtPvs8RyPtxjyf91Ke7zEhlC8sXBTEgLLROo0q k7N8ReEn+MTAGLBTe5RxKqf4tYFTU/eyhSuGLMGV8hajm90rdU81EK622QlbyMg5z9frbU0wEFwh JXv5xyeL+GQQON44rijuDMweV9ag1IWT/uGKCm2/gs+o+nX5D579Fnvi8lKlHjR71653FgNhFEZg Kccsu2/odxk2qIiRMi4h/g8uNyOHKWWhw5sDw8JnQ/gIBgSV4GxYhEg5JWx9ZnqUgVc4aPoLXyjE 0eyHxbBypIxqXWrzTnfhywUrFTZR9memuejAeS5bRelXvYyLs6ql/zFZtMUk04T95dK/cjeCXt/E FxHGFwOmEVyWJ/zHSFAF/hjjSRNHVFmPko0yYwof4eR1jyLoXXRWNGQ8rPB75Zzx82fyM3Tk+c48 P4aA23DFpA4TzCmd2NP36PRfmFOEn8m/IucdIqyVUwcuzUYxDAx8kZsW/jRZy8bgN4D5DCMaBDaP p+jqJi4nQunYaqKdzPPbcfa4SYFTAkU46a6IsMsSLDYxn4PiVBR+PrUQ04U/g1vrwlOLC28D4Kd4 Fi0UUxouOj9Q5xQ/CALz7jac2vJyMnuFUwn3KPPSFPni+c6Kd/lMEUtPE+DMMrqDLjy1iEyrxBak 8xKV93EqgxSLWU+/K/P7Kc79NtSXd6W7MukLSBV+/Rrhc/3CI/uQ8ygeF/4gyoSbc5zOUr56DwXq HEPxTPm6+e78Wfrtci8EXRPhKsSch1fVLYlNsvDUzF9NDXFCsfAHUkPBvWQe92YGTvHVuseIkG/9 DOKgPXeTxKEmpnmB9P9kfghXsw5GZT5d+Kwx5888RW9ZF/6X8pUn851f/OzOzxO78+McdpLi5D8h QaGS/Eb3KfpPcfixiPBTxKMi0ylCTuaz6MUdpCsfLUCq8MTfF7m+ql94MDUhNh4oXL6bYpIoLEAK iWNOiUAs5lME0QmR5gmhPufvI8u4VNZV/AknCx8Tm2LhIbxcPJx7efoCyuvAgiZig3hf4milwm9+ ulQcX+Qyo8uPqsCqkorAB9jJqrJYeNC2WQkwKejz5BSucLh67uv8FCZ5zjq0WPhy+XoXfo4ZWCqB meZxyAQUCy/RwnP734Iv4R1gk7/EIebcwZRGRr4MfJGN3aZL/8DeQsC0gosXFMYUeDs/T6nwkfjT By7LxffliqELbFi/eGaWPnu4VJTJJxC0Q8Q6W8wRrjFXwDUzpfQZV6FBQYpiLpcfyyXBNL+mu/im EGEpNpdKZmPpILyOmVD4bJVcAdIkDwuWvREJy9ZPd+GfybJQY5uyl8qVoe03zYXtDRQ+2qvxYjbw ePXIQUX8rpwW8H7QUJyRmP+AnIS4Ltsx4/neyS5mkXZG5gZOZzJI4g+XSnl5fKzRrzVbT4GFstOH MXSv72agEqgqH2A1OTcop+nLLmj4h7mZMp2gUqkOd8CUc4fpojQwQUHZETQDyj5xMdJBqQs6yTZb aBYgYCaUPWoXXO1LagIy1UrJuP06I8oeSvJHhbBFr+PyYR1HYkx32XnoJtQrk8zVuVaSyo8ndr1c TR+yi+VyhKWNlL0YMF3gggQtu052hAtnlGeZyauh7cMU04UIFzWrZzDbpSiHA8+3y6bs53h8LyiL Ku+a+3D6uvKYfRWdrTNDZGJ8vGU5gh6GS02C7Tusz/E0w5Td+BgJfIkTZZ8hbDeFWZwYuZzhZX+l 3ENdUfZIbI+pYr/nUh61xKCkEO7FKZM6OQj2nE7lDKfzzDkPVZ45KOcgLJVzhzInXYlXlDo4Sg+j MdXt5jfqwi91Xdvowf4WhfAp0wyBz/fQ/7d1KJ8ScPU8kuFcEyzKZT/BtdMHH3ZOcM10STkZcOSz em6owhSVrFh2HjOlA6X/XyiBlLdjCHwOsjl7EtH8QA2u7AWlPGnDHcplP8f2F4UZLi9X8w455HDQ A+sx5UojWEoBKyEvINCxxxTzLiJ9qzgcKWd0akaezKWLg5TsjByAi/OuNoQ/2o4gV3b9XOUHVUjJ DIPHgTv7UBZEYQIdGOrmODy+z3ymQwb7zdUf3cPnOOVQBS7OEXErNbBlblr2ZXn394KyLzvdxUxB YNnaLrywTy/Lv4OQ73Wf+uNufvoqnHcpGsei4lEWT8mVECgFznOflUe5gH2XHXzS+RuZMedMe7Dz CIrHTukkTOYdkHri/xIHMmPTUADF6WLgWGXlMcSyx2XGnLPMwMOAwpYaCUDJiMqniHUP0T6V3+UT gfBrIvGcgkMVhlh2LoVcAMR3G/COjK+yJ8Qp8wh/GdG3dv4GHgEz8cwDGRonMlw3hfahCsMsO2Vf KHu+8ub85ptNAUBbAJlhR/1v89zEt9h73HAUrhX8XHn3cf5aOdFspHgSoaOVmWr9zs/FI8DrzBWX bZ3l6CEi4Nu9A6GcDScyKRA3od+HU3Yui1wALDOm1N38VwyJ49APYppTCBNI5opOvs9FJnDiIEUB Qyw7aQiSBI+lK0/ms74I14ib6eZ3chjpQPFyWNq5Bx4QP4WXxD6oHvhVGHRPmkkxxhni+0yAlwTn oDDEshOfIjIjWGjCviDuBO9x4UjgSWsyl3MhWCmjIFzR/ydBwAPpvBlDLDu/XbkAlJ7xMCUz4bNx CplBuBDMkcOziU+ZZAjFrIZZdso+qd8dSOlw2eBbcwqnZvbR/Thlc5kOKTSicfJZnKKUVe+yb1d9 xRwyJ2hleSRkRi4sRDRMMJ928Rz0exqiJeAITEO0X+doCZlZb2Z2C8Ky36fsNA55IzGhjvU7H7jT MpaZslLew2pc3GIkBZ0hhTwQByPU0lC10WlCv1+rW88vsosqld14YGk7jSMf0fN+FCAz1m2QTtnD jU6F6mBYbYIRk91qKKINA8wVopmwhThNyEwgMpu423rxic5mdmfWxOvKXgge/K1qD6rot9q5DTT2 dTOvCssvmGL6qF9FnA2clQmg60hW5bJzyMTy79ozRYx4RHvcgNsrdOaZfwVwoA3l81PEV+AlCex0 NvA1Q0L0ucWSIbpfPSkTxwT0qs2/AoRoIOf36DDCDXytA/W5INIl3XfZP2lwYQ6buVSCYtkvKrcD Dlk/+DS0oSDCSF/2zdw/r53izbjIzGB8xBdpEeuSw+zy4x/DYgaVnYuyMdrSLp4bcMjrM0JoImzU 5f2Q+/Cu151JkRTTg+xsqSS3cO/M+lfNVYLxH0x/4S8YJiZcPNWVrC4BGK+y7VncW+UTQ41JW+Zb LjN+powNK6basB3Ofclcv1wq/Iwo++sB2zM2ERSfzeTQiUdVrNcQNBPKriseCpEuYFXPmrIHUrOI wmZA2QsKI1JQCQuCXsyyaS/72aLrYKScnVs4sBBx82TwlXzyyLSPD8MUszCusQWhhbLPQHApS556 383mXhZlP5C9Iucal4Ffao0ynn+V4lwGTzLTwVw8WnA1TOEjigvLsuX7wGB77APiZ2LQVOFcZkzm lu9DgJ0psTEr11QBNmeZmWRJqOT7hdX0FoewBu/li03EgEU9VIjl+wTVSqlJB8CkWMeMNN/B8w8m 7ptuz8/pBXj6OjHiOrmOwfMdraMkPzPjNilIxcuyHUxv+c4g1ktIGZrviBk1y68JYh3ZEc9vUrje 8t1xa0cWdNsp0Dvh6ZOCqGYO2L4+CzzmHc5nZrUdoOW7xZGEJBM+zmTCISPC+P2a7Tuy+Jq0S3Sk lu8eFTYGcV4iEbJST2NIDTovHc5lxkGOsJg+oenuRZheYOqmVblYbivhk1mQ6KLyVvojyfYV2RyJ MbE3SwwdjxdMA5MxR3czhgg0eMj4NzN272f8MPtQQkOo5DvSNxkvLMp4HgFQnKCtsEqZ5x9kejH0 qk/Bwsc5nP6oxg2LvMRX2pPeQNdTQyfNIgyMHQktM+lMormFeZljDc/SZyoZL5EIPppWQGQTSWiI F32dWpH/GMLz7um47Q2s9t0vavQ0Mz4qjO0JcffZ35cwMscU881Ud6CpwMe/ggArdAUiYS0Ynntv pOs9zeKLmXE6XGSWB2J8kDBmfLqHsxni0DRTcIKXpWCkRXKFrLwLHJD6sYa4XzATp4EsnNM4BMA5 L8Dtx47pReQ6eyTc74kE3C+BU1OYS+XgguWasVXCprAsZAjndyjXDhJcCi/igm/WHE43W8tMvsan S/L91TrvNIopbI3W7eY37uP1VSOwExdOsp8rH5xi1ntmC4BO5x5LMNO8DJbeqlKY/agYNivtJbpw tr3Hc/kvS5gFJbcpJEQgBLX7QQKepdSKl7ASNN+v59ezRdW1ixMmok91dSaOWjVhfP2ZD4EMexAD DVPMIdFx7M7fkfUCLUHxQKWYpYL3fcqGBnF32+iP80xDBUvo5p+x0yYMJLQ33094syTNd83lZ7gD U7+J1+N9XeqTeFkvo1YDU2fMY91YwXfDUzksF+jYBu5haus6uMZzUM5zFm2QTTEb82AMbChhgQRB cpGVOWa7LAwooqPlL0gg4Ai9+H4u49n6wNPJkdQlmVlwlMGvR/N9u1S1BZwTVydC0/WknJ5J811Y 6ibrAI879vNjCwe6f+6YwCkkFAkk+Pa3LMGzi4pgcwsJDErus9IrYgqht7x/hKWqDB5Oj6NqNhu+ +1611Hcy6dOkv6Q4ps7kvE8MPVOK77xaMnZDVE/9bP6WCTV82ip8+6uWCXse5xRdXsGXDivwLitM CzOgtByKqRCUAjkKhWFTSD6eZgk9+a5ZmmaP5vthaiS96C3zZLJaGcfRSM/o9VfpWpQD1C6dCF8M g20KAghWw2/F6xACBxA4BqssR+MFogUuFEc3X6vS2egSkERjvt9HLds3sw/kijACvrvS96xXC3yX ypBe2JMk/7zMtuPCsdvM2yR1bUJFw9O5ZOW0uEm3G0F0JmS1qL0EdVlB8Q3EWhVCbz3TnO+XsvnU zvUV7Sj43p+e6RxSegYJ6YyYgKywJL5Lkd/5tiEwdxbwguF599tEQCaEr2H/Lz4oKHfqBFuiGhgy ayZD+1H+UIHAlxVozPcD2erOatUXWYfvDfsip/60u3Zbd/e2Cj0zG4K9O/9Jnr+0jnHseP7Wbkr0 OQr9NXnuY5+Dsli7bScu733LpiBekgohAgv88b9usiLIzW74K7h5d/f3OJs939udb6ODGGrIhNxk xYlMVrIsthDU9mIpNOY7ojXjO95UIwxmv3efo3Q3cDQbirYTnZi4ZGXyKvhMMKwiwjf5ApDpjUzG 7V8ytQ2uTQRKY7KikENfc3FBFcIo9MwnwfcGekY4YNSJJJJ9RLAkjxCI2cRYIROBTgxh3wafSO6V u5tzO8Bz+TlXt5qsoE4OdW63WX2Vl7WwBImZRF98H7V+r2+/Gw7h4BSk4Alfl1hgkBBwwilM/8DU lwwBwUzA6kk2iUnxGRcyD5FwPM47eBBMItycapelNsVzOb0DJoxC3iG9a0bNd3nQ3nomgjskDrAB /OXjJlYnbxOdCRKKOpUJBNON478LQ3AHgmZLeWyo1OouBR1MGBXfb/EjhCPhexP7XerVRERhxCNc /yG62e3HaCA6KAiEm+z72GpWSeBDUshhostbs6FiTX3DpqD7CIHDK9CY7+uzNdTK5S0aDEbAd/lw a+gZ++Qp7JOszOHYyzKqCATTj8lsUwQ6Al1m0tOFEOTuVEvoFKOQd+7k0gGJZJv8yEhjvvdpv8fg aknJ8FkJP/aeIpCYiiAz30AowhF4fSpOZ+pVA7MTjBy16lXX03Ig3Vur2bwdPgU64Pr4jNUHssMS YeJwwzmtVs+Qco4AMRL9BBEcsr0x0BqSmkFpNYHfxykJonZTLupL8Nd22eiol4lsbq7ubrMSgoSm 8LF3Pkr31pZHOTTfH030p/k4GxMDgSlM5cu+A9la1l27rHuajqfw6Z/Ol9HxHX7WpT8WQk++d3Kf FbHDj4E89v8cwda2t3/F3UOqAY/7/zETkMmDxGNTquDu+Y9ccXvrmeuyucKcCm2gOosl2iuhx6qJ VoB6Nw0Vjdczcmgz3fC9tp7pHP8Ll4+wV6DuYQx+ZyRhyy4TRyGfZfQMHRE9A1Bd4gkSlkIt5hxV zaSNRrq1wCcS9u9OYPVMwqQA32vrGWwS5rIKhi/usYRZwiZ7j+/H2SbR6QDMzcO7P/bzJhQECUrB 8+9sFiytpKGZvMO4beugvYkBEx/njabu1/xoKfCzHpOLnnzvdB6UmAQJETwroVarUOUoCIeXLISI hpmcFO/+pAT34vuHdiJelUyejwj3CjUE9UzC0Xd+/xbNlQ7P0auTEz86W5SvzFnr+BV5FyX4ONvT zgrjiHoqOMriTd7VbOLdhM/Tpjpf0zjCc7TCo+tjb4hPXPIqpZnAvxxdIWBMsaWWPCYY/JryInsj 4Xb6kW+VpadRjR0e8FzZkW5RfqwmHqzXEw/qCPwa3yxrNY1AebC/UTEVPslePfcp6Ww2qW2aGbIL xfRihWfbwxWymAXTOgJD/ZXMrEEKPJwaQ828l+T2iuk844I31dzUqyvYvkh1CLwRTG8iHFUG5rsp xk+qToZL076L3PQiyw772Rr3VQz3v6oclCJzcZQwTzyRcrZe5P2x23nDwgfCxYo5AZky0qOTmDTj J5ZnWRbbFZQqEqurWr4LDiSnBHxIXFSjSom5Y5N6xC9ptGyxM9havjOI68n5Xvqb4NV/JLyATdpF NW0sUn2CPvyW72T77ciqplAHfN+e7r0hc9LrmiTfCST0hDHnO1A9gVrxnXRMlem9xs+prOJ7i1rw fM+K9mMJm+xiBy3fB4bw/WxWaw7k/kn6gJaTfS7XLfpFll16Gdqo5gqSwLn56WqgRU2szuY3rQNf PDc/PmG+RW1cM/9coyGiVfg2WjUzKAwX645VvI/Iy+9r2T4osuz1u8HLWiK/KMt2YMWrlu2Dgm2Z IxezOiuCkSHzKFs+LdsHhZiQT5DAS0gSFIXjtmwfHI6VieVPPTK95IaEtegTju0Te6uZeUJ1iVXG fAVVhZyPJ8CAHssJerZjYE4CI1ijIlaxfT7u2bKdULnUl+bmjvSC2Rf0+mJptm+m2z19ZNyVEPH0 wLXEiYqmv2Y7sSvl3aEHotJsX5GZBfVathPIOkyvoh+wPTnevUXPQ0iy9TUstF9BHxcIT9/IssT2 tAW2T1wfn+8brBlMiLP1Yzeo2rKdMTfLXpSgIkoMjY12hCOq75LaEoIGqX87j6Rlu8GjSf1OLPSO SAlvpmCdZuJp/ONx+9u0bHfsKm0BZ4HFyUOmlntnlNsdc12CQ6xW6r9lu8Wc9CoNJzTfI7VqIOzX JtydyHSUGISW7Q6pFfIJq7VPRlncj3rtkbZ1bC8Zo2W7A1WrElqGtsrLjA1fXryHeJV6c9jrTILH E/T8fkOIHenBjECNFP3I1ihPyQrnX9eIvZ7uOt5TPI4SB9y3X7EqKkX0FuLZghdBHU2l9vKgyrt1 dj+nfNj720NFzQxJL9HvhZ1ebsv1YIZBlbhPqhrx2sAsP5qkeCzxr+ZiegbyWOGoV81z0iv1pmU6 /R14eCfJqi0rxgueb1U8SXH3fTVtYG5qwNUnrtiTaMywSU8OTk5mnK+WQH1a6ZLVSsfsTfRkbvJT Klthd/Cy+G50OgbjgtIyBxTz6ukYiTBxX+XOouMFVSk21jJ1pkqqOO3cYI/3vSBXDDSpfT7IHLHm +WtqMl9qJ6APvdFf8VrHD14aX08rgRVqCQI/JzvcqSxukevsk0psDKE2vWqqZaKBBfg4O9qmksID fkpehfKNcfgaVdGm2K5W6qh4qeMIz9GX0zO69A6He8WF4JxS7ak1UnylUNUMHkd4th9JT8rWted6 WSDihNpbe3miZ8BnfrZiWYlxxPxso3CmQg98pNqjNlqoeOL6yceZ03BZzisdS7T6baLcI0FFLPGr 0rQ6pgDPvpfTnSZl0VZ7xyWZWutLGlN4jlaslafZfj13v6xS6j5VK/hUw69Rb5etBT2OHVtn91Vi SHC4++A8CSNICMMFB+vOStjUlNuezEEIU0/KtYXdCrGwY1wZiqNp3lynFtD/gGtHtXAtGTLxppDP emPDxpIsalmxrCXRzrjjvfzMmXznTuw9cMjtg4cYTNBMu/0qm+IqzeFjJjTPj0sAsPUdG6r3ZDIQ wpl8ngQIbIpe66B2FtVb+NeP7BnZ1vL/RkI7+TgvJ0ydFLDIK1ZNz4/Z5cCLMOu8lhdg/5LjHJE5 9CuaB/lJG13vd9g5Llndlss+P8A33D3yInfxTk0Ku0OIwKdQu1jGsEp3m6Tq1PfVkm3m7Wi2740P o272O8vNadhG5dLzkRIbyz0+gsWBbxTx3nCjITwfsF2lUEte26zwoiXIx6XD74wocDS/AxmDspAU PVbFVRxdnnb/1VwusT3xlbzSfz+YfaoKtjOL5Shsr2H4jm1VZUMOx997VAq1y6TPTW0zee9bEpcP CbTwhPwlCWK40J6LEXsGpjZhJvTD9kW+47Ix24lbrGQq2I7nKysZc3DdaglKcTx0o0rh815ns9L3 k6yEUKg7KaLc/Da1N5kkIkITtle0UzWXt2cXSIGMdNMO+8gVbDesM0dxBfLHWRfThRBcJnThU/hg u+PGThV2z1rOyhyBogIULSC5GzRgewV3NNux1cEtyn4cBdvpsSI7aiqY58PS9ga78nyWWnAfydQG QyYN8g2W6LfKx2Y1W+1c8LXnJSuT4s6wUvWE/JFgD2hLGD7bP8je7KzxLaGRsJ0KX0/JELs93jah 2AyMDOetN7uXIAp7q9UMfHjlTklFl3jVbrMyhO8XKlWXgo4fKDvHphgS208otj+RvdoZ8c5v9pHp 6SSkCHnkbsB2k4hCH+F0fhMmMU8OBRsj8PaHADYY41CCCel0brBZ2SMsiKJRVmrDMxd9KGy/TvU3 IpqW/gOJbl8fJ7WTShJgYG0lIyGdztL/4Z8aOxAwy3FubXm6QIriZlXPuqx8ZpIPBYoucRsKMWwK ocme9HzLmkpGGRzXJpeF/bCgVDTbH40bQB+ZqXlAYiPzNKjkvCWN4kMBxA7eLuY3ghj/EF84CNxc OXST2S7m79k4lIg3mPkts4+MVe6H/oPZeeZWv1XtwtmkKSj0d/M/MZvYFCrV3KQAi3nbGwmmghtC b7av8a7UdyfnMRX3p9FsXx9nqtqN6eWK+YBRiBRBaiSkCCuN4f47D36VxY0OBO9xSsbEYakG7VZL MAqbzmwi26sj234iyNLudGqfYEPpQFa+lnBZ9WK7aqa+m2zDqz2bSmxPLPCokjTdBIueqh8lQ3BM 4mBmHR+8h9mpRySFDZW0nMgQ+JrAQSYf2VMorFRtCndIVxCn46x6sV2x54Ok93k126NdMuoDOdx0 /JpLb55aQooginneIMYXOBGHMttt89XYeJLicbI1mSDdMmjOqkSA+y4InzHk3cGNJMWnmMARJdxl 1YvtShlcSjZTX9ST9gpsT2xZppTX9sZsN4X3j1OC8KWgZPZhP05hGF0e/1WTyTt8tWC2ozntA+V+ 76ddVtYCV/d/SRJt26UrVXub2UbJ0GGMJTozhCZsP5D0lVGRImyPam61y+329LhVHPS4/SiZpf6p OfiF2wz3vs1XbotfAkKh46E4VFayAdM82ZUcW2Pdceg5G13dqZTVbEOk85pK5oLvKEzb18UuSM32 hOZWbKcEzcClp4MgIUW451UxHqT2EhJxKIKVQU4tGp8iF+3zFseiS0vgbKh9+02XLud9gekgJaMq VUlxMxMQd5bpEjNxka4X25WhdyTJdhWpLttVi6o52+lhfrI73+Y5UQS+bWzHTprBbPz4wlT+s3YD d6TjCpCZwnvBk4IgdiAFaZyDx3/GEAzbTVa/7W+W88151/eHOBPeb/5XVKUKNbV2G/TSWmxET8dn +FORexDje7Fd7xmZ5E8V2xOaeyC2k8jUVTIkceYwKXBgm0i2XZAPE4gL9+yyKfKtT1K1CgKU+54/ MlnR65CBvq2SFTZXpa/kXhtXFcZlxf35INM9EO4IvdiuWZjmj+bzJ8F2Kj0dBAkpgih4WHOY79we ikOszul4j64fstFBoxMTd19n302OIFvlYv9IkH8g2TCZ7qEqVUlBL3uhzeomtLVcVpcn2+kxBulv t+2XBbcaAnHWpeA8JcU/53BH4DTMU8kqv4GvZ0l0XxokopsT2zv7vuJuPs+8jlpdYTOS7VT4ukrG H1bJADaaEMhIkRS3si7Z5wj2DfxPl+h+m5UNedLeIL/TDpBzVhLDZtXNT+H8k1Iyh+M7ec6vMzae AJdePXgZRGFG8KGVDIw+vxWnDc3zvwPtzweI64SQ5/90lwklstSYdMm02c5lgKKZe+QHTYCRak7U 6Ty21tyDrrdyKB292X6Nry2fSXrK7C94I4VsH74BSc/Qn5KhipHgegTvvVFlhRQn6T8IdAHCrfnv kxUJAoWbjjFu6UqKxzikY5tMFGgC+EWIkpF9tdU9aikZZaSk7fYqS2Z5fLGBNZ7tc5qsRg5Qc+Xk LPMkElIEfdUnuyuf6v73fOdn83/52fyLn81/gfU2YGUdDf+TnBUpcYpOx+eJDAJdM4FgCBJOTPyv 5uawYyxuW5n/hEIpklSqSPSUTYTWlS2uKRURerPdtYSq2O7aVCW2JzoHXhukc0DEyzxWDESBYCFG Ed7ThUBRkBXx10Xnzt0Nb1n5xW0MgRPYFHxIIhysZFz3r4QaaScTU1LQt2YIvdke9Mmk9oOo7hyI sn2F7wpL9+MngGeQr1ZCijDPVxjUA0pD/JIV2ZDCEW5rmi3IQTAHGfJGtd/+lZBQUGTS1UjZeCVD l0bWfYo6bHe9XOuTC0NWsT3R8btkkI5f9wxJtgsjXCt1ndcsGlM2H/ql6NAchmBvgIYTESjcVAiI 6A5zDz6kx0sqVUuT3Fwn5iM2ek+2v+jZk94aSUWqy/bN/k0lvoc0/FOlpV0eNBnDYN1nJCvkxtGt dWKM8U95Agcv9NGFIIe1lkw0CbXS3nnp02GK3mxf5ZVBmj1V/e2Jb+S8r4XP9thuqAQ8QG0lIyEJ 2KwsO+xwNjdgAwIHH7qJuZdUMj81lSpF10qGApoqmTV+lbW0MlDvpsT2uYnuYh8nXWckYB/AMqMM y4gabHfsoOiUoXhXzAsIpGoMn3woXHfP+EOUjFSqnIgOd/cXfmDSmVLRWS+2v+pbk3NSu+zpMQtm +2q19tLixDIPnu3PNHbYoAeo20rtwXa0R23ztatdoN09cNAF18XPSs0L0zDElxwBlaq7ucpOsqrZ SlWCS/xMQDU5OdqmcCFCiRWiVsZxoPBDUjJ7Hg91ifMUPU7VnyZwIJ0z534TISEM4eT3maG4DpQM VQo2q3pKphZ3Vqsp1weyV8k6HK0znjwAP28R7OopXOitZJhD5uDsXAPWd/4aAsLmOYOFql6xkAQ2 ronJiTgdkjGMzWRKRWdDYbuKNLGRqtCyw3sZg7CdHsApAPPVuuNm05PuCL3ZHugSCSUoAqkW9mD6 lr9N/iBHcnjWEFbS9/UCbl9UMrZIljB0tv8Qbh06IJFsi96IXMJqgkrO7kl0iL8PHsY4G/2ciFvM PSmG44+4rP5tgU2OQOHGQJF7/KMgogFF5FL9MUjinqSUDMYUfXGbsB3OjQloLu9Fm7MG22/J7pYI zdluJA6HFSE6nALgGCa0t5IRMeWsXC8jIJ2/QoCB89jN/h62r9FBPJZAWxhTMugSk1AQerD9vF87 4PX0Io0lLuuAa+NdLmpVgsQ0myTocdJKRthuCb3YTlFtVgQZQAJIXSsCQuifuQfBTT2zgFsCp0Cl 6m4e3F1yq6Nklvi+gafjHedAJdtZ60Tg47ybrZKweqDn4wegQxiBwzQUhe02tA7bbVaFyJrAbVd7 j68WIhqo6DjHESiZTucuujaEnmx/M3tdeFOhCtTsL4n2qlraZ2PCq8mzfW6t3T89pPA47LPS0Z+S QXe4yUpP1gBMKB2zTdt1w6f9Pe43UTSoXWtTvEC/fP/C3fPnbVl7sf1EnbE3PfnXRFPzwag1FG8v TXqrM511FOBtBSgGaVoLkyQN4pFDMG3xmAQSeLLGcbkATIwQQgohNIM7JJDQg+1KW6R5s0Utgmcm /75fkv8yan1ICUjh4whj8FUlJCIhmKetCfHrAr4lRNL8e+SkGFFCG7D94XTPid7j526jybVyTzB1 s+8Ma8x2mUQeB8e4Xy6CWexxPCsxp4IREIKdq24nvW+Qy6k7zHUBfur8UncqJIulEjxVMPsLOO/Z dzi9V2TIY+64qcF2Fedw067fKxznaq2PGeGxUtwT1ydemE+WWl9pXKEWG0yzXdn2Ltprqit4Y0I9 zff9lhXvdBzhBfJSunf2nBrkeFh61+ssKPP+AMr9yoZWv8kJRnr9TaelI4qnBB9ne7riGEOc04sr S1gZUQ6HgfHxEb8TxaN19hgeG/ilS6sWOIqyfY1S7m8kBktX+Z6HiuzHD56hd6f7wZaodR28SfKR qmePpJjq87+YnHw5fljlRysqpHGRGsHb67kX/QYK8Fpmbnr5jrGD1zFJeSUk+DupFhC7mPA5WKEX s5WwsYfaVGlv0jNJN2SDt/Nd5Y66MWV9+rQ/bFtMgslaOztuUXXn9frt1NEyi/wOExXLe44V1B6D G9NrQKa5O6mW3ZiTsMvVp/LD1oZkZHqMOemB/pFie1gDLFEN1atTNaba2jNLr0U2RjjqF0yu2szw qHIIOxxameF3EH9x6pOilzb2WxZQdeqZVrF1Z5UG36KGmM6m1JT6pg7QPdPvdxwABggz0AZKM2NL sEtkgbXhK4nPHQh2qd079mz3G8wSx5KTXAo7GRY4q3egTb47tYdc6XsZN2huLq8wYybV4HV5B7hA knekbXfvHtyy3aJqP70tIV9L6/X4nQoJWYLvq1QmLdstsvRy+cR1P3Yd66Ncol8LRciiHk5H2+EO gWfX9pSK+WiSuOjVA7WIIq8n00vmocaMsjVzXW4t2w3StgWx8KKX9cTO7roxBcRzo4pZ5o+1bGdU WHQlhkY7zFdrOyXJ1vP0Cqvo4wLh6Y6a289gACnR+s/0gqhJtpK8c2u3ZTtmlFZxIWA7NewT7yeo VSvYupputvzS2LP9Euq/qq1jC+xM9se/GtkMKwaqBgC5Gk8YFqTmQzI02/dWddpmaryjmq2vzG86 Q/UKw+psftJaFyi2X1/Nzax1EBgePNtf7jEwRPWl7Xlv2T4oHNupEuixDA/sFDMY3rJ9UFi2k5HZ e/EjatFyQ7Rl+6AwbF9OgiwBlXgFVfR6vSF/i75AeuNhkvTk0j5FXAfGt2wfFIaLTdbG2Pzhq+2s jUHxYnZ0yxD8Fi+8dtS8wNY9qcU0Y5NI4ok1DVdRq4WPraAbSGiLFtMDkUODyVVD9FI8v0ZyvX49 WlI4E0qLFtMDCCFaRRvvholO2NJwXdgE3j/BuS1XCxq00t5imgEhFHmcOPIGrrLJwVs85ziju9UA eCvtLaYfEEKRRwaGV7Ns00AWzS3I4qKfZsZAmNBbtJgeQAhFHgVXz0FY3W7HMl6EM9lF5RppgEwl RnO8//G51+b3HIVsccXiGnr9584tabgNQAkQQpFHhyPbEdpsLTuL/XCH2eG93h2QpcRphCWLkNIg 6TPS4gqHCACwJbl8Y28gvcijwtUXKXiyjy/pY+Snlnr3AEEi1cb515AKuPu+w/TbSvu4AjLw+n1P 4x/hRL99h0gs8hhgIwgNt3bo7Mdw6kXXDRMA+Um0mnjRdOscNp6taFC00j6ugCCwGExcuhbn2dFm qxcLfDYFLEauRxvtDrYZFrvaOiUAbiTxauFNJMjecN06rbSPMyALIghkacOJqC9TO8gmxFnQGiys tgTxCz0xHiBKxBrgLsyLfr2aVtrHGxAHEQTGeh4datxVXsxG4xlkWVvCVlHkHXo+jcaB13EjidkT LyJyoVunlfZxBgRCBEFwCcI52dDdBdncV+ouFCxGZ+QmidkDaFDO0cNJHo9ynybZRRK1B/ZzL0yx W6eV9nEGJEIEwWE9AptNDrL9e26B+xDoCanlughh96tFarBWz1afe6BmG+ABRA/mujJaaR9nQCZE EBRgv0826pA8/8AKI/Hx5iUyrCHuSWF/giucBo7D7EumDXZBK+3jDAiFCILGJYQ37TnsXMCYULBW hkMtcYfNrpZz92DPmyaNCfRh7o0ZRK20jzMgRiIIITCnvflU5/fRexjVzjXEHY4xUZv9eiKsbjAS sB/+8GUrhloQr2N8t5X2cQW9/Oz16EAOxPNo88EmzOuIiizyq1yudDNF2KGWWXLAh9dkwc1r8MlF RmJfpmAguYtFiysc0rwsu19hv0YylRuNCzHQx50U2gqPrPOQ0YhnDKer2aPDYM2ulqcU4GvLTqxq /kAtrhxQ85LnwUVcsDAu1Ie4r6BkMe1+BC3NdNMX312sSwdSOriwz8XNF1UufNNiTMBeWE+XJBTi fqK5MYPlGmKNTTR9J1PZYYg/Zmqj57FqTawSosLedEC3xRUNmNtl+wNC0oftju4/t127ArJLtHzR Pa5X6bSYS+GTTVQyHkTtQWyAPp0TrQ3TwoLVe8l6R4ddH4vQoSfSbR2jgFGm+PbuSBEz2tGH0mR9 DrQa3N5bFniKJn06La54oEukLO6wmhv3u/OOHX4reA/eVSOmY2H8xMalIKdN5j/BNWZHsYr4gAKT FlSL8QQ7URX9sdjHpbnBi3EiWfM7AKzwSF2BLy1mx+DraGLHcL9O8YvlT2zQyVktrjTA17bUukyq 42q8Sqn8/lYemDdStmXmJ2KjZmkyjfRDil/qaIeHfbviW4si0C9Sal3CDmhuunOrU3LQuJrCS6ta I3JsABadOE1WMvwuxb9W0jo0NYZajAugkUtuLmhaNp/ggb6RWPc5BjSLQ/foao/N38CdG2jl/ZiT N1fSWrAx1BrtLcp4n0SjZD+zLdN46a8LlKjUXiREpA/dQaV+FMKjFN5EtcOD0u9FKUh3A7UYd8CW KfVWJ5qWPYBO99iyAej7DpU7eh8jzrlNrXbslVL6vpoaQy3GCPvRqVEaZEKnd+O1e9HPEhtRPULh wR4daBzHrPZnKLyJDRL9vBoaQy3GChidKXV8YzJTc+WOjpaYNQ7lrtsBW+g61iGD5uWbEqcGuBdT kjq0qr1FBVi5l8aF4IbYuNMdOjvW545uGTW3FAZ+rPeGa5QGy32gWVzyj2nahdlivICmXslyh4ps viUGukhirr+wLvy3gxvG7Ht4yLwqcWogarW3HTItKsFSI8LiAeXe2HJHk7fsZz4x8TCFe7dGVCZm R7cQP6TwBh2f8D0ofaVw0W/u99BifACLoNTnjiGmJk7mDLgixHoWJ+CNYG0U2Dtuv04NrCHZYAwX FUlpGRoMow6wumWLKx4YkCyLHyZDNO5zT5kyaKe+InEw2B9zl4R138CQQZ99qdSFFsKw8WRexB6h 1MdSSVkLBzccu0fSaewTssdBoZSwVSKE2CrUIh4UusJSIRXxktAV7hJSBU5JVI8HhZJAKUGqPLUR NS0goI1tAvQJxnpbYJLbZgC+iJghA1/4Bj0y0RoJvTojNGSmwO5ut+t+83uFUh9L81sLmbjf3aWg R+g3z0/dsEASC/bk75lIPsW/WXeHEEMcys+U7nEm/8V164Qe4iGi+ri4+Evr4lE35J8uFvfx/D+u myfkFMIU3e6sPP+zeMEFhXvsyh9LFL02otq2LzWJaiI2q4NNGeOVCGsnasigN6V+NxC2c85KI7dw QRvFHn+CKRId/a5upN88/4JQ64GkPXzh/ndbivA7pDcDOTqePxKk+Cb9RL+8PSDorCQFofAFAXeE cbvddzjmlJAVXqDgSHHz/EmJkADHCdLRd/v1WP0loBiFFHl+SGj9IS6jMIGbLv8LN/do56LvckdL NmbIsNle39cXZS7N81tMgZMSYRQgaSdmL+t2Vyre5810zdJ8l39zQVb6N0L4ZSXvz+bvFVMQIvJ7 PJoVniK/XaIo3JW/BbJLwR9RzNhYx2SfoaSYTX8VkksopjAXFd8IqEEKwmDSfp6EpDwIiu6Nxgux wN0rtoKpN2XghxaL8QSFNzDbUR+VDBn0/TRZmaMpypYM0FTaG1gyivDIrvz3vTiTFIcpgGNC9Hg2 mlW3ezOilz6OBflssiyCFMA+IXss+Hr+fKy4z+X5nacqjZliCvzeRB9J0iIsxN1FfwNKe1xGta1d GynDnRu96AePf1kEDN828NNFW6NkyMBs72N17tqYyv+UXvLafNtPurt359u2GUumqbTPJhOAJAW/ Piv8fq4HIc9/0UrosfxnghSz/pyox4XoMO9U/kgqq4hyF/PEpfgDE6/cpN2XP6dv7lP8XYpe/jgU 8jzygP8OqRIfCYm5TgFNMai0w7ooyyhs7aazOrD6V6kTHMAAEyxqmO2xlQa4t72+6yK8Bsp9nTD9 h7DnfBLTasl0u8/T7waTC8lxgQwUe4iOITCaVVS529aATcGRItJ7e74TZJWhu8fj9FvVNVNOwZl8 lZriCyVKCKKGKQgDSjt688oyejeFNl1lCx7EMecBVruwi+CWE10XGJ9D/WZC/KuC68FwNimOYzSW TBQwgV0kKGMb9yUjFTcUCNx7UxDMBQhzmZhfnVVBuT+WPx7EZes+otofQ2iQlf4lVLRUYynoF1nF u0ULcYdhyWAqUVlG0SXYuDuP0pQHZglwXYdJDc+x4vwLBmqS+kP+sJhKZjsaqaVpUsMESTsx/XSe nzS878+SUe8PWfELjOIHN9GPi4vfL9GPUYKwsRWh2/1b9K9QlNuZ4IurfyPKfR/XXEEKQkm0eMCg kKFP8Tw+03QvFcUupjC/uPUNEkkDdJViGNIeN6bRB9nYcIfremyVSbj9QhLR2y5BAUBv4LuItm7p Nmhp9LE6SH2MypIhk/tYgKmpKbRD83dCiUaQ1eAkygHhb4Ikdo4B1SJodIY2Q5BVoNy/4AjeZiAU raN5X85/TWf1CL6bkCV3nio1gC1cpEipol2dCA5SEAaU9oSM2pZlE0B3xyZqiJWBLsrtEhIAbmj1 JRW97eVsGjZ0m2N0lkz8Bf5fkCiStxlgMOcvgMb99tqY4L5xPdJ4b/6WIsuvtmRC5b6hEBcmeKRg G/IbdVaz1poL//t9+km2VAtx7S9nRQ/wUukzKcQdhm5nj/OyjNqWZRMkO2WwSPUDCZuJ0ExS0Ugt Z4M+05F6+47Okkm8wCfDdy094C8xrSDMlBVBaet7cC33MLECs5ytchV9Ib4eQ+YUsKIIRdX+Qn6V yoR/87Wz/D0kKNWjSBFMpGIKSVcygkAxZE4xFGmHP2G57Yj5002nAaEVWpoqCqDP5WNuD0c384AX Wv3efXiWlbMxH9QIQZbMypX5Uye7s6hOpZf1bfC+sbT/UpcyOXkSv8jqNype4MJ8Le70E5+CwXek z0YTnjqJOkP1dj+U/6a7B6X7KacsZuV16e35Z3Wp5E7Fcq3Lf8BP7kpl4FmC31+ikGclQQFECe6h szp5EtqjkDDPy6UaVNrjQmj7UZogKc5o857jjyHm297wXlirqZwN6qKROkB+0pYMSTtH8uaH6Scx CpdsCm3JmKycsKzL31GELuqB/OZSVl65o0szzAooyN6Cr6tIyErwaZ+Ofv8+guItVRVL//pS5fn9 EtXAEczvUHR73HegHzs4Ke0Y51yTNnRghdSvR+LZwNdhlB2Qn7wlsyd81102iu2gqTVVzC9lBbiM vpXD6pF7dM2wjO10Mb8/hxCr3PWoK1LA7aw8XrWPmti6PKTogf9Df8IS85tsqVIEE8mU6qsuhfzO Im4c1ANNoKgUQ5H2uDndrOVokDTM4RkwP92IbWY1xbMZdXc7LBn9asQrrLFuD95v1Qvcmq/lSNt0 CsJjhrwh/4MgK5ZQ6bXeyn2MhXSEYlZWuR/Mb1IEcb4sqva78p0q0rbubRwpv+ELLp0Qki1VRA/i Un1DP2GpTimvSAp0BCGPSNox7a3pjOaktJvMktKOoaz6Nnc8G/QhSYTR4JO1ZBYczD9DJIqkK3pA el7W5cUOEcK3DO1QSEAvODVv8y9p24d7XYwK3so2QiGromrfkwe62FoyJNY8aFskxFqqKhZ+udf/ bf2ApvqSz5mgCPgdim7HbL1yj14/0h7PiWAyw9Z30cGlZv0/cWmnwJFLOzHdVMLg/QgtmXV0r3fe 1nHxC+lXQmjKY8jICsJonBD3+A4YEEQJ/yf86BQEo9zh2F4gEELVfkf+5+7Jza8BRrum8t/UBFNj FWoGgEgmEkolDgz5p0yQIxBcewJhjjAkSyYhoxQ6NGlHZkeTg0/smV5/Wd5oNliOZrSLa4zOkinj K2/7SLai59525YjyINqdIMgv909yK+84GSaegK+GcDvZPv/axsWvU+7UBAiMCfN1hO6M837dkc3v 7yCO6GH4n9G5IUhWsZYqB+tMCP+kcPPu81RlWTuILj1BUgwq7Yl9JREqEeoC4z5R1wGTWVLam9nc 0Wz6qYqaYZq9wkzLUb9snrIXpCCQ+D5rJzfRLxF+m8OJgE+NTiyB+9ShRu/N31J3WiZfR+hBvKFQ Kvn0xF7hOX6GYH7Z+7fk6eXIvrj5ofupIqL/IeFrJi1OiylmjrSn92PlzCCmsYmr7CbTTNpL2aAd PGppB+dNJYwXMBRLxl30Jhio+RJb868GKbif8Qb2kHTpiGAA4b03JPwCwhfA6cYEOQIQqvZj+VVB qWB+EMxIF+GGyLBTeboskQzZZMWWzCF0CM1SNycCKhfmK8IUYSiWzCcq7Ze1blcvc0iWjP8N6/OQ AI8XxqlgctDBvOg5BrMe3u8qyPgAsPAWnMlEuaORGdycEaj2B/N3VDofyXeffIuuDEGywm3DznOj qouZkPDek88uPwd7SNClC7KEcZN2NHZL2cBuH+GCA4Rps2TEtCAUZj1g3mmQAvgH+Wxl9C8THwDT ZoQzWTHFguP+Tvj9Ew7N9Z0WfgPav/jkQUN0wSlMaKIwnVWxpeoIqrgQ3nkvFQjdR+iGG8znUUwx DGmPWNsUOmRpR2dKZF/iy6dPZtmy7ndO508R66lm/T1mflNp/zEyOX06zAq/a+OE50z3IaO0oseh /BGdAhM+8n+ff1FnxaNItiOHjJy/UPf4VyD9F7Kb1c1n/ZgT+GFWAjUQ3D1Qqt/iKPlDQmZshT2k n+NH8FYIuUOiq4srlgzwUP55RcA9yGp5aR5yVClG2Ccz1B5I4/Kb7G9vJu1YXmNapP2TtmTMpH/B 1yJrr5DJG6YwKNsl9js5phqwlSn0WOhdYQo7+FTCV5jssiq3VDlW4U4ivGROOePd/cJToRB0WUi7 yQxD/lFpbzaWGp3M8YmMpRKzSfME9fnglkxv3Em6ttTBwShMrzONRy0df8ghXkKc2RLcXKdgaNVu e++DJ9e/SQIhaKk6grq5Ldo6bisHWRkUUwwq7XEP2n7mYWMB34qx1LiYEppJe3y+3ycg7YTCy+xD t1OaUibVmErf49n8Np+V+d2lBydllQw/Ovlk6PnLTVg69ymAO7VqvyNfW5pVEqRIE4ot1UJcZckQ Fn6tQDataB00FEsmPt4PR66ma0EmPQfw6Vw3LB9I+J79UFJ69OOP3wgjsWQSo0ukFKemjh17sHp9 FjbEXVb4xWS+sl2inVYOOYKQuQ/epeApf3rYn4eVghTmN7hHkkBQLVW+LpCV8KJfJyD/6lpVE9oU w5D2sucifM6bTkxFTtHVwjYS4cO0i2QzacddyguOwb+9+U6vDTA6S2aAF3jMKHdXqj/iX38Php7h /JiMwEqKx0srCABqEpT3KgieXP+mCTxP1XPIE0wKQD/77fkf9rgHYVBpj+tKSGDTuUBJccZeTufS qr/ZlG+0Dko7R/blj98Io7NkBniB805BoHSG9BvaJYUJn/sw0FmdQql2dMYX4prfOpYM/6rVMwpx Q0sG2JqjbnGRilkNxZLBBgLl5epgSzfVlfHvhmDmLiUbsfAubrDMF8Uu95h+AvNSR7B60sAv8Pb8 c0Gp8GtXNuLB1WIR1/mbl1L8M5PAq/YH4XWsilu+Rw8C3BZcS7WwelLk2Reeyv92+h7spj+otMc7 BuGp1XQlSBjmsQ0L7DQ6rPElIQEa9v9EfSnhOtB4kYQmmJGWjIz7R40JGYENliIgTLHPQzSFaUV4 1b7wG7O9J6Y3Jqqgm7Q2hS1BiUAoPPs85fyjf32KQaX9KMlJaZXpvpZnifeEE2RiEcQ0OrzUzDkd lVH5o6LAkXa4z0hLprzYBv2SPlS5F1u64awn82tSmNpKJTiY6J6vwlP0p1PgC+J1EmpYMsBd3vvH P4fPalBpj9sXDY0Lg+hCLwCFY/nduJgSmrn8xqcWYvuc+nk0R9wr7M9kEZgq+DHQRjP16oG7eXyp 9C+jPK1iA3we0yl8XXAvLh2ZUvw8AnpCpzjZ5ZaqGRmjQEVISHtnT2maik0xDGmPL87YV6OP0kQt FTvrL7nCe7MO9/j3iTyaruXXBBFLZudO9GiY36t27vxsIUgIu3wFMHxLxshkUCr5lUkc5e0s8MnF UhRVe2GFj2UyL7bk7BUi6odsWqp0UiTEnv2erwf++YUUA0p7egp/0+5rDFPFNv6VLhkjpsk1fhts zQHbq7Qssb3JqFCyZOi3WNdGCazDzCSMEVgysEx0hvTLN5fx/cDhRaA9f80vpzCOCk613yMtVBdL HMycm28cwcoE/IuPhB+xQEjodjLeZVCgyN1h6PboYuh9WcHJDki3/G7KC7LhOnywiEqjqWYEa3Qo WjKF3yoCwbykEVgyvNhG/OaAdnixgOdvOYWMu1rVPu/L+SNBhuY5yu2AIrx7sL+H+YgoUBOS0o5H CtdgNSmGwSwoytLkiH5GUmvsvJHaZKxhMxUd9+VKpNn+Ho1Blkxq4Z/kikBMYDdEK+0NVk+qC1Lu kZsblPcwAKhlm0rhOucfyv9b+Bw8+cO1OCtwjNKFLIGYUjr6DQhA4tnh7xbhbjpBTcD8KI/VYBWA +guqC1KzrL3mhuEe3XcJXZQNFl+PbiDZzyLcDTCYJWOlffiWDEr2zdLN1SSOMuadypUPvKQwsE0M GVbyzyFWfWRt0hIeyr8U5M4JqaUaBlXpdnzCs28qcncIun0FyUh5RKgfPZmclYrFkcwWkvHtwQgw uu0ukzWAWqRkysDX4UOJMALMWEumsy7/2eLN0aAmpBTxsfzzxRThnmKYaRqQ2Xc++fmEmPc1pNAs wfDt1xdSoCZUSntnAXapdEXgFENgFhTywyIvDlhwvbENnNz5F32DMlAV3fqR0NDoxr4IpV4ZONGP cJsx1u19w0t7GYNKe7Jopd1pHHjJ7AhEtaOpGUWPDU4F3KVfAtqeJVQ8O+9oWcJAzIpvhIdmZf0e QUFq63c9QRrbakT3ooHh3qAywWZRj0pSh5E7hsHy7BP+JcFGCDGwtBPKuRIqd3SMfSKy+pJBeRvi aA9PHDGBp5Yqb2qpUfnsC78ssRQGYhb6H0uGDEbym2vJaL8gAVaK9fnC1ghRU6ZhQwHdP6WvBv2Y jZvWjVDanLk2/EvCdl4hkntZNwBvPFNAtWDE5FF7S94gYQpNClreOhxTqHgjG40eWbIXcICBmIU+ wdJgf19bYcO6KDd3CTBk3Oq7MGViFUBT2ym6qTZaGyOd0dHisgZs7VJf3mKYFY2lBp3gsbkaGEj1 e6Gi8zD6TUBSGwz8Y9H50k5jaA43/kpbjA2wL0dpdWiYHs0tgpQhgzaAcpSPWtwE1CcNemX2w5+y OFCFZTZG2eXe4rIGOttLbdT+VHu0liBAAifVBk5Ri5uAtmwTp0t4F5cGbuEr0yr3FnFErWg4hDWf FxGtJQgl6wIWd8x7AD0qTfqBkE/RfRjN61a5t4giqtqPNOwMNMByA+WeTKkoAnscw1kx5Q5nhSbT MZBPad4fJkmNdAZTi8sWGFkq6WNYAw0MaEGqjRqpKNANFHMwQN9Nk+5ylL7odLMYjd2RLj3Q4jIF hnpK2hFdgc2XD+V+9FKPoFQUhTYALPfYZOymyh3+wzuK98TqBqNdD7LFZQkMo5YsaLY8mitHqPZS hyAh2nOPbpmSswKhqXLHyFjJVaG1ZVrEgHl1JfdbjGk2mFchSKn2YoeMAbpvYpM60DPfSC/Dlik1 sjEHdqTbBLe4DIH+mFJrEX6EfRgC6JCJWe3oZ1klcRTg5h7bRbhpk+E8Ot2LTYBnUDuN1l2mxeUG 2B6lQU14omfXSIz6gCUeGyCF44ofRvXgoaFIQ5XNqCbLesBbYUfR7YYfooGzfIsrHhD2OUU54R6N 5moxqmIJ3ESNegNgVkfs80BD9WjJ8qkAuiFLY1os7q0x08ICKyZtL/kiopnYx0RmZJayYxLZpWwZ tGobOS3gqy2JOxsz1zX5alpcuYBrVmSEB8Leh8csxvBjPYqwY1J9mfvhVRPrl8HKMo3G/tH8eFoS e8A5p+2aadHpbMaYe0TUICF9CDt6WEq2MwGOL2mvRnSWxxwIFmN/vUZWCMS9PGXqaqznnmXz17RD TWOLjz6EiU2IrE0Ku6MPYcfiS0mxrZgUzd2QkY+E2w6NxnLRIRTJ6Rk8EGGUa8y0mMkw739OxIRY DF3Yp2aPru0IWas0SWAAxZwm+TNptCgfbPcd0Y1YR77MdYsZDHr58T3vuF3Xh68s+kSiwo7mJhbD q0C0wx/AOmWTTZZ0hAtEdHJ3K+3jDEiFCEIA9Pw1n3bdOQ8HrzmRMVQW9p5diUlxR/s2W9Sg3/99 GGiRlnIr7eMMSJEIggYr06aLtXf2oxsxvjsBNtuo0W8Oizsq7ovRNUOVTX0Fj17QHaWpU620jzMg QiIIHnNhxTQ12a85x+3d7bF5GXWF3fiHlbsPGfDuAmJjsTFwA2JvoZ5ppX2cAYkQQbA4wF11zfrp YIIAT8eMmJpmjAFyivXMMNajzqm/PCQ2qMyuDzJrpX2cAXkQQTA4ghGlxpM3kObwu3FRNwNEi+oO ZKJnZke0ggBwI4lYA/tRVWTblT3TSvs4A9IgggDMRd928y044gaRgDsQG9hFbIHEJrQCoEm8WjgP 8z3L3rAfYivt4wyIggjCxAEz+rKmrhZW0NkUAB/1ZnXFNRja3Ru3ZpCZRKsL7hOlDD+AxLfSPs6A HECKDpw1A+sn+vMDt9mUgckgjac+YQHJqNNMX3smdPabBrRFK+3jChEAg6PNO9gFSC3yGOAJ9j2U SA1wAeIZ697BjSROM1x4BUMBjMbL0Le4QsDNOGDRikHWS0QOIo8Ki7kLpb/aAgvdlfoPB5D2Fi2G BQihyKMHptn10eK1wEhTtrfg7YIwobdoMT2AEIo8Chazwb5okGW6znPFsyNwd0GIkFu0mB5ACEUe GVej1zFbPfBi0mzPZHN8fyQuhdaixfQAQijyODFxCUtaZNmHffRklvE+5jQRnv6AbRqcCqVFi+kB hBDCuHg9z4jLshND3MvuI+uXIJDgFi2mByKHguvcxhtDw4VzrgOxXeauxfTCdWQefbO2n3Cn8/8B U6ROIcvDeq8AAAAASUVORK5CYIJQSwMEFAAGAAgAAAAhAHBnQ7NbBgAA6B0AABQAAABwcHQvdGhl bWUvdGhlbWUzLnhtbOxZTW/bNhi+D9h/IHRv/RE7TYI6RezY7damDRK3Q4+0REtsKFEg6SS+De1x wIBh3bDLgN02YNhWoAV26U77Kd06bB3Qv7CXpCRLNtN4bboVaH2wSep5vz9IyhcvHccMHRIhKU86 XuN83UMk8XlAk7Dj3RwOzq15SCqcBJjxhHS8KZHepc3337uIN1REYoKAPpEbuONFSqUbtZr0YRnL 8zwlCTwbcxFjBVMR1gKBj4BvzGrNen21FmOaeCjBMbAdRr9+B8xujMfUJ95mzr3P4CtRUi/4TOxr 3iQj6U4EwRODDQ4a+kdOZY8JdIhZxwNBAT8akmPlIYalggcdr24+Xm3zYq0gYuoE2hLdwHwyuowg OGgaOhGOCsLGoLV+YbvgbwBMLeL6/X6v3yj4GQD2fbDU6lLGtgZrjW7OswSyw0XevXq73qriS/xX FvDr3W63vV7BG5Adthbwa/XV1lazgjcgO2wv6t/d6vVWK3gDssPVBfzgwvpqq4o3oIjR5GABreNZ RKaAjDm74oSvAXwtT4AZqlbKLkufqJNyLcZ3uBgAwAQXK5ogNU3JGPuA62FGR4JqAXiD4NITu+TL hSUtC0lf0FR1vA9TDCUxgzx//MPzxw/R88cPntx99OTuz0/u3Xty9ycH4RWchGXCZ99+9vfXH6O/ Hn7z7P4Xbrws43//8ZPffvncDVRl4NMvH/zx6MHTrz798/v7DviWwKMyfEhjItF1coT2eAy2OQSQ kfh3FMMI0zLFVhJKnGBN40D3VVRBX59ihh24Lql68JaALuACXp7cqSi8H4mJykJeAV6N4gpwh3PW 5cJp01Utq+yFSRK6hYtJGbeH8aFLdm8uvv1JCulMXSx7Eamoucsg5DgkCVFIP+MHhDjIblNa8esO 9QWXfKzQbYq6mDpdMqSjSjbNiK7QGOIydSkI8a74ZucW6nLmYr9NDqtIqArMXCwJq7jxMp4oHDs1 xjErI69hFbmU3J8Kv+JwqSDSIWEc9QMipYvmhphW1L0K3cMd9h02jatIoeiBC3kNc15GbvODXoTj 1KkzTaIy9gN5ACmK0S5XTiV4tUL0HOKAkxPDfYuSSrhPr+2bNKyoNEsQ/WQiXCVBeLUep2yMiWFe m2vXMU3e9e6le/eWoM7ime/YJ+Hm+3SPi4C++W16G0+SXQKV8a5Lv+vSb2OXPqmez743z9qxOY7n h27DJj7xBD6mjO2rKSPXpGnkEswLBrBoJoaoOPCnEQwzcRVcKLAZI8HVR1RF+xFOQUzDSAhlxjqU KOUSrhlm2cnb3FUp2GzW2vkFE9BY7fDALq+UL54FGzMLzeU2F7SiGSwrbOXCqwlrWOCS0hpGtUVp hclOaeYn8ybUDcL6vUJjtWlFQ6JgRgLtd8sgD8trDFFmtTUkwgFxLJfsaxh3nrk3y4lyuhJn4+Sc wczJuuzmqokl1Rk66njr7WbbQz5OO94Yjk0wjFPgJ3WnwSxMOp6vrIGn1+KcxevurGrU8/UFgysi UiHVNpaRpTKP8tcqyUz/Zrul/XA2BjiayXJarKw1/kctzE85tGQ8Jr46YWU2zZ7xiSJiPwqO0IhN xB4GvVs2uwIqodObXNMTAbltnsCsWrhZbcy/vslqBrM0wlm269c0uYUWbsaFDmZWUq+Yzen+kqbo ij8rU8pp/JaZojMXzqcrgbk9wS4uMNI52vG4UBGHLpRG1B8I2PeNLNALQVlolRDTb6O1ruRw1rcs D9vkwkjt0RAJCp1ORYKQXZXZeQqzRtYVs8rIGGV9plBXpvZ3RA4JG+rqXdX2eyjKu0nmCIObD1p1 njljFOpCfVMPLjZt/u3GMxNk6ZcVVmr6pa1g/dVUWGYDLomzHWtBXLN94s4zv9WmcMtA+gsaNxU+ s39c6A11yPcg+qjY5xEk4jnd1XQWFosj0NkuWmma1X91CirkvsazY8nZxSFqztkvFvfyzs5GFV+X 88jh6tpiierjUX4PMbOFP6X46A7I3obrzYTZFZnCzA52hTF4xINpNmTStgTriLyls2SPjBENjvOw znk0+9en2Mz3rABte0G4cjphhp9tIgVx83TigiK/4xXE5hbnYsBmki3eRrlokYWnWPIqLltCebfL nNm7rMuWCNRLuEwdv9hlmaf0rruQeORYCdzL/8aC/LWMTMpu/gMAAP//AwBQSwMEFAAGAAgAAAAh AHBnQ7NbBgAA6B0AABQAAABwcHQvdGhlbWUvdGhlbWUyLnhtbOxZTW/bNhi+D9h/IHRv/RE7TYI6 RezY7damDRK3Q4+0REtsKFEg6SS+De1xwIBh3bDLgN02YNhWoAV26U77Kd06bB3Qv7CXpCRLNtN4 bboVaH2wSep5vz9IyhcvHccMHRIhKU86XuN83UMk8XlAk7Dj3RwOzq15SCqcBJjxhHS8KZHepc33 37uIN1REYoKAPpEbuONFSqUbtZr0YRnL8zwlCTwbcxFjBVMR1gKBj4BvzGrNen21FmOaeCjBMbAd Rr9+B8xujMfUJ95mzr3P4CtRUi/4TOxr3iQj6U4EwRODDQ4a+kdOZY8JdIhZxwNBAT8akmPlIYal ggcdr24+Xm3zYq0gYuoE2hLdwHwyuowgOGgaOhGOCsLGoLV+YbvgbwBMLeL6/X6v3yj4GQD2fbDU 6lLGtgZrjW7OswSyw0XevXq73qriS/xXFvDr3W63vV7BG5Adthbwa/XV1lazgjcgO2wv6t/d6vVW K3gDssPVBfzgwvpqq4o3oIjR5GABreNZRKaAjDm74oSvAXwtT4AZqlbKLkufqJNyLcZ3uBgAwAQX K5ogNU3JGPuA62FGR4JqAXiD4NITu+TLhSUtC0lf0FR1vA9TDCUxgzx//MPzxw/R88cPntx99OTu z0/u3Xty9ycH4RWchGXCZ99+9vfXH6O/Hn7z7P4Xbrws43//8ZPffvncDVRl4NMvH/zx6MHTrz79 8/v7DviWwKMyfEhjItF1coT2eAy2OQSQkfh3FMMI0zLFVhJKnGBN40D3VVRBX59ihh24Lql68JaA LuACXp7cqSi8H4mJykJeAV6N4gpwh3PW5cJp01Utq+yFSRK6hYtJGbeH8aFLdm8uvv1JCulMXSx7 Eamoucsg5DgkCVFIP+MHhDjIblNa8esO9QWXfKzQbYq6mDpdMqSjSjbNiK7QGOIydSkI8a74ZucW 6nLmYr9NDqtIqArMXCwJq7jxMp4oHDs1xjErI69hFbmU3J8Kv+JwqSDSIWEc9QMipYvmhphW1L0K 3cMd9h02jatIoeiBC3kNc15GbvODXoTj1KkzTaIy9gN5ACmK0S5XTiV4tUL0HOKAkxPDfYuSSrhP r+2bNKyoNEsQ/WQiXCVBeLUep2yMiWFem2vXMU3e9e6le/eWoM7ime/YJ+Hm+3SPi4C++W16G0+S XQKV8a5Lv+vSb2OXPqmez743z9qxOY7nh27DJj7xBD6mjO2rKSPXpGnkEswLBrBoJoaoOPCnEQwz cRVcKLAZI8HVR1RF+xFOQUzDSAhlxjqUKOUSrhlm2cnb3FUp2GzW2vkFE9BY7fDALq+UL54FGzML zeU2F7SiGSwrbOXCqwlrWOCS0hpGtUVphclOaeYn8ybUDcL6vUJjtWlFQ6JgRgLtd8sgD8trDFFm tTUkwgFxLJfsaxh3nrk3y4lyuhJn4+ScwczJuuzmqokl1Rk66njr7WbbQz5OO94Yjk0wjFPgJ3Wn wSxMOp6vrIGn1+KcxevurGrU8/UFgysiUiHVNpaRpTKP8tcqyUz/Zrul/XA2BjiayXJarKw1/kct zE85tGQ8Jr46YWU2zZ7xiSJiPwqO0IhNxB4GvVs2uwIqodObXNMTAbltnsCsWrhZbcy/vslqBrM0 wlm269c0uYUWbsaFDmZWUq+Yzen+kqboij8rU8pp/JaZojMXzqcrgbk9wS4uMNI52vG4UBGHLpRG 1B8I2PeNLNALQVlolRDTb6O1ruRw1rcsD9vkwkjt0RAJCp1ORYKQXZXZeQqzRtYVs8rIGGV9plBX pvZ3RA4JG+rqXdX2eyjKu0nmCIObD1p1njljFOpCfVMPLjZt/u3GMxNk6ZcVVmr6pa1g/dVUWGYD LomzHWtBXLN94s4zv9WmcMtA+gsaNxU+s39c6A11yPcg+qjY5xEk4jnd1XQWFosj0NkuWmma1X91 CirkvsazY8nZxSFqztkvFvfyzs5GFV+X88jh6tpiierjUX4PMbOFP6X46A7I3obrzYTZFZnCzA52 hTF4xINpNmTStgTriLyls2SPjBENjvOwznk0+9en2Mz3rABte0G4cjphhp9tIgVx83TigiK/4xXE 5hbnYsBmki3eRrlokYWnWPIqLltCebfLnNm7rMuWCNRLuEwdv9hlmaf0rruQeORYCdzL/8aC/LWM TMpu/gMAAP//AwBQSwMEFAAGAAgAAAAhAEaaOLfFAQAA/AMAABEAAABwcHQvcHJlc1Byb3BzLnht bLyT3WrcMBCF7wt9B6N7rSX536w3SJYWCi2Ekj6Aasu7orZlJG2SUvrudb2btEkcCL3olSQOc/TN HGZ7dT/0wa2yTpuxAniDQKDGxrR6PFTgy80e5iBwXo6t7M2oKvBdOXC1e/9uO5WTVU6NXvq59NoG s9HoSlmBo/dTGYauOapBuo2Z1DhrnbGD9PPTHsLWyrv5g6EPCUJpOEg9gku9fUu96TrdKG6a0zAD nE2s6hcSd9STe3Cb3uL2dx9PkHZzk01vP9nTbitLZw9f694Gt7KvAGNYkBQE4QulRpiTaFXBBBGy pogizTO0phSMsaRYraE85smasuckI3RRwj8NTKW69x+dv9yCk9UV+CGytBZFTGGKohrGOCaQFYLB lOMoQwgjSrKfvweB47LVrpG2/TDIgxKt9lx6+TBnHL+Y9KAba5zp/KYxwyWycDJ3yk5GL6lhdIl+ wT73Hy50TyF5hClKCYVZkVMYR6SAlHEOGaN5kqYEJRg9QqpOnnq/QPJJ/xe+PU/EnlIOkagFjJNI wCKPMIxTRiIm5iOKz3xJ2Ryl9TdWNt/mBfisOiadah8pk3+hJK9Tns8l9fD5wu5+AQAA//8DAFBL AwQUAAYACAAAACEAsSF1Ca4BAACWAwAAEQAAAHBwdC92aWV3UHJvcHMueG1sjFNNT+MwEL0j8R8s 3yFpYEuJmiJWK/aCtEgte/fa09QosS2PW9L++h07bWihB26ej/f83ow9fejahm3Ao7am4qPrnDMw 0ipt6oq/Lp6uJpxhEEaJxhqo+BaQP8wuL6au3Gh4f/GMCAyWouKrEFyZZShX0Aq8tg4M1ZbWtyJQ 6OtMefFOxG2TFXk+zlqhDd/j/XfwdrnUEn5ZuW7BhJ7EQyMCiceVdnhgc99hcx6QaBL6RNKMzJnY 2PztLa6s3/0Ufk69NIJWdLrVO1CpkUiC9aCeYRkY7miGkx/3BWfZcXFhXard39wVI87EOthH9bbG UPE8tWanN0YsNlrBRyjnjdrLQSPcwv72WiV4H/759wYyIN2fZMl974ZkS9HAIY8xmE1FiR2LCx+N OSOaUd7roPz2XD4bkK60XtfasI6q0ei24sXt0LW/N/bVazLwjGE4M0LSwGk3NE/OnI1qx0WPPfSk bDGZDIwfNJF+mEKv6XRGxgbABXThaGxHA/1kPVo7Z/1T/rz1PBn/ajst8ouKmnY1d0LS42eS0Hf0 2Ohjye1w7Gn6LzX7DwAA//8DAFBLAwQUAAYACAAAACEAUsOJFZoGAAC4YgAAEwAAAHBwdC90YWJs ZVN0eWxlcy54bWzsXNtuo0YYvq/Ud0Bcd9YwzMAQxVlxVCuterFN9x5j7KDFEAHZZFX1Xfay+xx5 sXLwKQZsM4CDbW5sY8/8h5n/8P1jfm4/viw85psTRm7gj1n+A8cyjm8HU9efj9m/701AWCaKLX9q eYHvjNnvTsR+vPv1l1vrJp54f8XfPedTFDMJFT+6scbsQxw/3oxGkf3gLKzoQ/Do+MlvsyBcWHFy Gc5H09B6TqgvvBHkOHG0sFyfZabObMz+gzUIMUIKkAxDBEhAEKgcIoBgVddkU+c1QfmXvdvinciW vP4xPXpyPuFPa5HoklNYBN8dn4EMYBTbdvz4yYqTtWD4jM/zQ+A59xMv42nfv2RT0otZ4MefnRnj Tl/G7ML1gzAb/xhGseaFzDfLG7MTz7K/sqO729F6fDomWxtnPWr6lV+OecMgtrc+qtMw/eA5szh7 95nnZLOgxCXbZS8eE/Ujf54JEAWeOzVdL5N4h5MXrzhtjRql5PK3JfXQnT90yGZNPg4eu+OyJD4J 4jhYdMdmQ9/1I3fq/N4dqy0G+ccvXfP6srTKpfXNVqT20LUyF8p9J3b9OP82cfREvCW/1YQS7jmH jOfS+EdvXXCSBCI+W4Jd9xg1kxA1kXAjVfoJVslXMisfm83PdrN3WmVSZZJWyVemVW6ZVhIKg7eR k5mM2cDPpGwvgG5seW8Arb2WZf5RulJbms7cVP6r0Hpb1XQFPgfPvdG6kF4EwrefXmiDYy3DWi5r ttp9W+Ld7Nr2Kq/od77Qm9VNf1hiywqcCXkDKYaCANFNBSCFyIBIhgqQrAlQFKFiGlwNnAkHnDng zAFnUnl47jt9xpm7El4Gzmxfq+vFmfAqcWYNrQecSRscB5x5EpxZ15aPxZk6VlQVioDDRAJIEzhA ZFkGMjQJb+qcwEnaW5ypPNlPfv7Fb4yVXjjMPEzkcKgwZmSH80mqazhmk9WeZ6+T9PXQ1sYvFFAz ffWDdP3yqdVosWJkEfBVDCzBbBUjK2BXxegq5LR3eAX42R5/AK4cNiUkmkTmFBlAwiWmZKgqUAmv AxUqikQMTTIFuaxkSXbYfv1ZrFnw6M2leGLzoqpkBvOqF9Vw77H1roQtYutWUHL78h3Cu5mAh7Hz kTjySGpH4rNSagX8hDmyyezTiXcws29iQdv4qVUHaI6w6MNlNwhe7Aj1EGQgKClA0DEGSOAEoJqE AyLCmBNEg9cNqSxVvf5g4ofX/xYOw5efsCW81PlKxfX65r/thXXL8ek4ZzZz7M3m5H+37J28nrHS PZeh57myjobZ6KpUSkeomGnp6JQkYjpCFXmajlhVGm9CrTmIbP3My/IeH6xeH3r10cKanIO2uuLd HMhVgoCS2HNEaB5iT0ux5/gSokUo2XXOqWVAw77X2vemoP8csEYt+9m377UI9fjI6QyKmKvDsaW2 tVmsPtjVu52gCxo0TQXrgEgqAgiLCpAJ5AGvYw4ikWgmZ9asJZd32NWtJVfbQVVLriZfbi1ZtFZK HywSovPBIh3KvH60H9IRa1JLVlHrVS2Zy3+BteQJLKzJvdvXU0sOsafl2HMmtWS9fa9lQMO+97iW fB9/r2U/lLVknzD/ddaSZ55LLqKW7OiufwFLmJiqBGRFw0ktiSEgChaAJvOEwwZGklnaXbqnllz+ wVy3lsRNasnV5MutJVcaNvbBIiE6HyzSoczrRUIN8nqRWJNasopar2rJ3N8usJY8gYU1uYXmemrJ Ifa0HHvOpJast++1DGjY9x7Xku/j77Xsh7KWPHrfh1pywLEXW0uuVG65lsQy4kQJK0DFkgyQyBlA RjoPMIIQaqJgYn2nlnzT2ZO39DDTJya2Jp5jPZ1Ddw9V9/CGU6eN5AfYtNRIfoBLW43kB9i02Uh+ gFWrjeRH8TpFL5WsSyoU0zMgPu2lMg0NKIauAV7iRRViTuGN0psKbM9yQ8qnip1/J97leUy/egBb OSZJF2KnYG/U9NKD5xV0otLlt2F14qpdYvtKtU4VHaiUqwMaRZnjoaHpAPOmliQfkweKQnTAqxAR QdNFUTDK8o73+nPuhG093/LEmWi4eexsivDjclG/75Oi6Anuo73uV+jACfrZKUR3uH/ZXdH7/gov T8k9OlKbzOv1K9cxrfWf5g0ysQSJIBAOAtNIkjDSJBkQHSeZGGkmbyimTPTSp2lUZWK6JwD2MBMP bXmXnIlP2v16kkzcvb2eOBO/s0JDJq7X4HSVmbjwWI3jMvHWxacovvsfAAD//wMAUEsDBBQABgAI AAAAIQCcA9s2egEAALgCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAB8ktFugjAUhu+X7B2a3mMBFQ3BGrfFq5mQjGXL7rpy1GbQkraKPtKe Yy+2goqamV3C/52P078k011ZoC1oI5Sc4KDnYwSSq1zI1QS/ZnNvjJGxTOasUBImeA8GT+n9XcKr mCsNqVYVaCvAIGeSJubVBK+trWJCDF9DyUzPEdKFS6VLZt2jXpGK8S+2AhL6fkRKsCxnlpFG6FWd ER+VOe+U1UYXrSDnBAooQVpDgl5AzqwFXZqbA21yQZbC7iu4iZ7Cjt4Z0YF1Xffqfou6/QPyvnh+ aY/qCdl0xQHTJOexFbYAmuqfb+P2ZNZVjFJVg06VkDYhHdLAXAOzStNZATtXN2iUQqG2LXXKmtIL ZuzC3c9SQP6wpzPJ0EJI9rnRKiF/82ZEw1Y090vDQT9qoe5Ncuzr8AnIkTtnfGjllLz1H5+yOaah Hww9P/LCcRYG8XAch9FHs93V/FlYHnf43zhqjP4oC/qxk/qDC+NJQNuNr/81+gsAAP//AwBQSwME FAAGAAgAAAAhALkfznh/AgAA0AUAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAnFTNbtNAEL4j8Q4rn+DQOv/QaLNVcRtyaEgku+WItvYkXrHe tXa3acuxfRkuCCSQuPTGo+QB+gqM7SZNwEIKp3wz8+Xb8bc7Qw+vM0kWYKzQauA19xseARXrRKj5 wDuLhnuvPWIdVwmXWsHAuwHrHbLnz+jU6ByME2AJSig78FLn8r7v2ziFjNt9LCuszLTJuMPQzH09 m4kYjnV8mYFyfqvR6Plw7UAlkOzla0GvUuwv3P+KJjou+rPn0U2OeoxG2nEZiQxYq9PrvqL+U4K+ 1yaxrNnBbAXpUZ5LEXOHnrCxiI22eubImMdCOW1TMtVXYKYaI+pvctEUsNhEGQ3LHtlE7dnYACgS pvqKvGj2+gcvqV/DpFNu+NzwPLWs1UPKU0hDKRKwrE39R0TfaYc/DepXgI5EkoB6rGJ6K6bjcSBF XhZWkIYxlxCgTWzGpQWUXifoCHjxBKZcGGQuXH8BsdOGWPEJH0HPIxfcQmHuwFtwI7hyXkWrghLL 3DrDhlo5S84sJNRfJ0u4yd3EosO6JQHBP4mVVoQvA3bQbu6gXdpHIuEk2B2OaNcfUQalj4i3Ha6O mMzwzl2N4Qebhpc9VHZX7QRcigsjNhtco7dCShJyZck4qiU83H95uP9OHu6/LW9/LG9/Lu/ulrdf a6mRgYtLHEQchbCWcIQfKmsrrQ9R+utzBmRSTmst52mqyOZ01HLDYBSQQGc5EovVtTNp6y7+cL/4 C1c3LDo5PQkmY/LGgONzhV2vKvRUqI/2LI/0MXewmp/tJA1TbiDBxbSer3WCjvAmjSz4QcrVHJIV 5+9CsY3OqwXNmt39RqPdKrfOKlfsktXmZL8BAAD//wMAUEsBAi0AFAAGAAgAAAAhAOiEUK3KAQAA 7AoAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA o+yCJgIBAADiAgAACwAAAAAAAAAAAAAAAAADBAAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA NYm6LykBAADAAgAAIAAAAAAAAAAAAAAAAAA2BwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1s LnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAACdCAAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEA5pv3EDgBAAAPBgAAHwAA AAAAAAAAAAAAAACYCQAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVsc1BLAQItABQABgAI AAAAIQBL9T3svQAAADcBAAAgAAAAAAAAAAAAAAAAABUMAABwcHQvc2xpZGVzL19yZWxzL3NsaWRl Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQBELxuPIAMAACgPAAAUAAAAAAAAAAAAAAAAABANAABw cHQvcHJlc2VudGF0aW9uLnhtbFBLAQItABQABgAIAAAAIQDDE4Er4AMAAJwMAAAVAAAAAAAAAAAA AAAAAGIQAABwcHQvc2xpZGVzL3NsaWRlMi54bWxQSwECLQAUAAYACAAAACEAoB37u7IFAADEGAAA FQAAAAAAAAAAAAAAAAB1FAAAcHB0L3NsaWRlcy9zbGlkZTEueG1sUEsBAi0AFAAGAAgAAAAhADd+ MgH0AwAAmwsAABUAAAAAAAAAAAAAAAAAWhoAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQA BgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAAIEeAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAA AAAAAAAAAAAAAIcfAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MS54bWwucmVs c1BLAQItABQABgAIAAAAIQCGzXGx9gAAAHkDAAAsAAAAAAAAAAAAAAAAAI0gAABwcHQvc2xpZGVN YXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBJQYcrlAIA AOMEAAAhAAAAAAAAAAAAAAAAAM0hAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWxQ SwECLQAUAAYACAAAACEAHR7OwRcEAADqDgAAIQAAAAAAAAAAAAAAAACgJAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0AFAAGAAgAAAAhAMc5USA2AwAAWAkAACEAAAAAAAAA AAAAAAAA9igAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbFBLAQItABQABgAIAAAA IQC2fPHUBwoAAGVBAAAhAAAAAAAAAAAAAAAAAGssAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFz dGVyMS54bWxQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAACxNgAAcHB0 L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHNQSwECLQAUAAYACAAAACEA 4txdvRgGAADiHgAAIQAAAAAAAAAAAAAAAAC3NwAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3Rl cjEueG1sUEsBAi0AFAAGAAgAAAAhALTPWBm5AAAAJAEAACwAAAAAAAAAAAAAAAAADj4AAHBwdC9u b3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxzUEsBAi0ACgAAAAAAAAAhAE+d fMTEIAAAxCAAABcAAAAAAAAAAAAAAAAAET8AAGRvY1Byb3BzL3RodW1ibmFpbC5qcGVnUEsBAi0A FAAGAAgAAAAhAJOqfZi5AAAAJAEAADAAAAAAAAAAAAAAAAAACmAAAHBwdC9oYW5kb3V0TWFzdGVy cy9fcmVscy9oYW5kb3V0TWFzdGVyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQA0FZTOawYAADwe AAAUAAAAAAAAAAAAAAAAABFhAABwcHQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAy FgYRCAQAAAEOAAAlAAAAAAAAAAAAAAAAAK5nAABwcHQvaGFuZG91dE1hc3RlcnMvaGFuZG91dE1h c3RlcjEueG1sUEsBAi0ACgAAAAAAAAAhAO/5TlQpTQAAKU0AABQAAAAAAAAAAAAAAAAA+WsAAHBw dC9tZWRpYS9pbWFnZTEucG5nUEsBAi0AFAAGAAgAAAAhAHBnQ7NbBgAA6B0AABQAAAAAAAAAAAAA AAAAVLkAAHBwdC90aGVtZS90aGVtZTMueG1sUEsBAi0AFAAGAAgAAAAhAHBnQ7NbBgAA6B0AABQA AAAAAAAAAAAAAAAA4b8AAHBwdC90aGVtZS90aGVtZTIueG1sUEsBAi0AFAAGAAgAAAAhAEaaOLfF AQAA/AMAABEAAAAAAAAAAAAAAAAAbsYAAHBwdC9wcmVzUHJvcHMueG1sUEsBAi0AFAAGAAgAAAAh ALEhdQmuAQAAlgMAABEAAAAAAAAAAAAAAAAAYsgAAHBwdC92aWV3UHJvcHMueG1sUEsBAi0AFAAG AAgAAAAhAFLDiRWaBgAAuGIAABMAAAAAAAAAAAAAAAAAP8oAAHBwdC90YWJsZVN0eWxlcy54bWxQ SwECLQAUAAYACAAAACEAnAPbNnoBAAC4AgAAEQAAAAAAAAAAAAAAAAAK0QAAZG9jUHJvcHMvY29y ZS54bWxQSwECLQAUAAYACAAAACEAuR/OeH8CAADQBQAAEAAAAAAAAAAAAAAAAAC70wAAZG9jUHJv cHMvYXBwLnhtbFBLBQYAAAAAIAAgAEMJAABw1wAAAAA= --Apple-Mail=_5A6A0425-F6F3-4A7B-B7EB-1E36D7778DED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 31 May 2017, at 19:04, Alexander Pelov wrote: >=20 > Dear all, >=20 > You=E2=80=99ll find the updated agenda at the following address: = https://datatracker.ietf.org/doc/agenda-interim-2017-lpwan-04-lpwan-01/ >=20 > We=E2=80=99re nearing the finalization of the LPWAN Overview and the = IP/UDP SCHC document. >=20 > The CoAP SCHC document is also on track to be completed in the = following month. (thus CCing CORE) >=20 > Best, > The Chairs of LPWAN=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --Apple-Mail=_5A6A0425-F6F3-4A7B-B7EB-1E36D7778DED-- From nobody Wed Jun 7 06:39:37 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2266512EC22 for ; Wed, 7 Jun 2017 06:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rVzjjZA_oznP for ; Wed, 7 Jun 2017 06:39:33 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01B5129413 for ; Wed, 7 Jun 2017 06:39:32 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:c415:7f2c:5673:b9ec] (unknown [IPv6:2001:660:7301:3728:c415:7f2c:5673:b9ec]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 0F3F2172098 for ; Wed, 7 Jun 2017 15:39:30 +0200 (CEST) From: Alexander Pelov Content-Type: multipart/alternative; boundary="Apple-Mail=_91A61FAA-925B-490B-AEEB-0995F34E961E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 7 Jun 2017 15:39:30 +0200 To: lp-wan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Agenda for LPWAN interim meeting *TODAY* (Wednesday, June 7th) X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 13:39:35 -0000 --Apple-Mail=_91A61FAA-925B-490B-AEEB-0995F34E961E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, You=E2=80=99ll find the updated agenda at the following address: = https://www.ietf.org/proceedings/interim-2017-lpwan-04/agenda/agenda-inter= im-2017-lpwan-04-lpwan-01-01=20 The aggregated slides are at the following address: = https://www.ietf.org/proceedings/interim-2017-lpwan-04/slides/slides-inter= im-2017-lpwan-04-sessa-aggregated-slides-for-lpwan-meeting-00.pdf Connection details =C2=B7 IETF link: = https://datatracker.ietf.org/meeting/interim-2017-lpwan-03/session/lpwan = = =C2=B7 Date: June, 7th, 7-8am US Pacific, 4pm CEST: = https://www.worldtimebuddy.com/?qm=3D1&lid=3D100,12,5392171,1850147&h=3D10= 0&date=3D2017-06-07&sln=3D14-15 = =C2=B7 Webex Link: = https://cisco.webex.com/ciscosales/j.php?MTID=3Dme7f536292c568c696a054a7ff= 7ef0746 = =C2=B7 Meeting number (access code): 203 453 401=20 =C2=B7 Meeting password: chicalors (24422567 from phones) Agenda [7:05] Administrivia =20 [7:15] LPWAN Overview (Steve) =20 [7:20] SCHC Fragmentation (Carles) =20 [7:35] SCHC IP/UDP Compression (Laurent, Ana)=20 [7:50] SCHC CoAP (Laurent)=20 [7:55] New items (Ana) =20 [8:00] AOB =20 Best, The Chairs --Apple-Mail=_91A61FAA-925B-490B-AEEB-0995F34E961E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

You=E2=80=99ll find = the updated agenda at the following address: https://www.ietf.org/proceedings/interim-2017-lpwan-04/agenda/a= genda-interim-2017-lpwan-04-lpwan-01-01 

The aggregated slides are at the following address: https://www.ietf.org/proceedings/interim-2017-lpwan-04/slides/s= lides-interim-2017-lpwan-04-sessa-aggregated-slides-for-lpwan-meeting-00.p= df

Connection details

=C2=B7        IETF link: https://datatracker.ietf.org/meeting/interim-2017-lpwan-03/sess= ion/lpwan
=C2=B7        D= ate: June, 7th, 7-8am US Pacific, 4pm CEST: https://www.worldtimebuddy.com/?qm=3D1&lid=3D100,12,5392171= ,1850147&h=3D100&date=3D2017-06-07&sln=3D14-15
=C2=B7        Meeting number = (access code): 203 453 401 
=C2=B7        Meeting password: = chicalors (24422567 from phones)

Agenda

[7:05] Administrivia     =  
[7:15] LPWAN Overview  (Steve) =  
[7:20] SCHC Fragmentation (Carles) =  
[7:35] SCHC IP/UDP Compression (Laurent, = Ana) 
[7:50] SCHC CoAP = (Laurent) 
[7:55] New items (Ana) =  
[8:00] AOB   



Best,
The Chairs

= --Apple-Mail=_91A61FAA-925B-490B-AEEB-0995F34E961E-- From nobody Wed Jun 7 09:47:04 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1391286D6 for ; Wed, 7 Jun 2017 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 qWt2aquTLzqU for ; Wed, 7 Jun 2017 09:47:00 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC44D12947A for ; Wed, 7 Jun 2017 09:46:59 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:c415:7f2c:5673:b9ec] (unknown [IPv6:2001:660:7301:3728:c415:7f2c:5673:b9ec]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 57497A80DF for ; Wed, 7 Jun 2017 18:46:58 +0200 (CEST) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 7 Jun 2017 18:46:51 +0200 To: lp-wan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Minutes from interim meeting on June 7th X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 16:47:03 -0000 Dear all, The minutes of today=E2=80=99s call are now online at the following = address: = https://www.ietf.org/proceedings/interim-2017-lpwan-04/minutes/minutes-int= erim-2017-lpwan-04-201706071600-00 Action points: - WG LC for LPWAN Overview document - ACTION: Submit for WG LC - IP/UDP SCHC has minor points to be cleared out, expected to be ready = for WG LC in 2 weeks - Fragmentation and compression have minor remarks (terminology, = packet abort behavior) - Include parts from "LPWAN Overview" regarding the Architecture and = the used terminology, as the former is not normative - ACTION: Discuss and prepare WG LC version for June 21st - CoAP SCHC is next on list - Confirm reviewers (nota: Michel Veillete has confirmed) - Readability should also be improved - ACTION: Identify additional reviewers / contributors - New items of interest - ICMP - SCHC-over-FOO=20 - YANG data model for compression contexts - Security - More to come - ACTION: Prepare slides for next call for other topics of interest / = prepare drafts =20 Best, The Chairs From nobody Sun Jun 11 23:28:20 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33251289C3 for ; Sun, 11 Jun 2017 23:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.081 X-Spam-Level: X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 drLLIXVH5IBO for ; Sun, 11 Jun 2017 23:28:15 -0700 (PDT) Received: from smtp-6-48.vip.sina.com.cn (r3-68.sinamail.sina.com.cn [202.108.3.68]) by ietfa.amsl.com (Postfix) with SMTP id 512C5126B72 for ; Sun, 11 Jun 2017 23:28:14 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.255.40.2]) by vip.sina.com with ESMTP 12 Jun 2017 14:28:09 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 20771465687 Message-ID: <3ADAF2E456DF452F955B2A91A13E7125@WeiGengyuPC> From: "weigengyu" To: "Alexander Pelov" , "lp-wan" References: In-Reply-To: Date: Mon, 12 Jun 2017 14:28:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] Minutes from interim meeting on June 7th X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 06:28:19 -0000 Hi， After reviewing there some comments: 1. IP/UDP SCHC As the draft ties IPv6 with UDP, i.e UDP/IPv6, a rule is required as a indication of NO UDP. The usage senario is when concerning RFC7212, ICMv6 or ND, these protocol messages are directly over IPv6. Regards Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Alexander Pelov Sent: Thursday, June 08, 2017 12:46 AM To: lp-wan Subject: [lp-wan] Minutes from interim meeting on June 7th Dear all, The minutes of today’s call are now online at the following address: https://www.ietf.org/proceedings/interim-2017-lpwan-04/minutes/minutes-interim-2017-lpwan-04-201706071600-00 Action points: - WG LC for LPWAN Overview document - ACTION: Submit for WG LC - IP/UDP SCHC has minor points to be cleared out, expected to be ready for WG LC in 2 weeks - Fragmentation and compression have minor remarks (terminology, packet abort behavior) - Include parts from "LPWAN Overview" regarding the Architecture and the used terminology, as the former is not normative - ACTION: Discuss and prepare WG LC version for June 21st - CoAP SCHC is next on list - Confirm reviewers (nota: Michel Veillete has confirmed) - Readability should also be improved - ACTION: Identify additional reviewers / contributors - New items of interest - ICMP - SCHC-over-FOO - YANG data model for compression contexts - Security - More to come - ACTION: Prepare slides for next call for other topics of interest / prepare drafts Best, The Chairs _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Tue Jun 13 10:30:49 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C5D1319D1; Tue, 13 Jun 2017 10:30:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149737504180.7644.14829146816429020164@ietfa.amsl.com> Date: Tue, 13 Jun 2017 10:30:41 -0700 Archived-At: Subject: [lp-wan] I-D Action: draft-ietf-lpwan-overview-04.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:30:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low Power Wide-Area Networks of the IETF. Title : LPWAN Overview Author : Stephen Farrell Filename : draft-ietf-lpwan-overview-04.txt Pages : 41 Date : 2017-06-13 Abstract: Low Power Wide Area Networks (LPWAN) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application layer data sizes and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lpwan-overview/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lpwan-overview-04 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-overview-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 14 10:01:03 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308F2127863 for ; Wed, 14 Jun 2017 10:01:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 tF6wHTjlhg2Y for ; Wed, 14 Jun 2017 10:00:58 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDCA12785F for ; Wed, 14 Jun 2017 10:00:57 -0700 (PDT) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1E45141C08F; Wed, 14 Jun 2017 19:00:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Lmd5kV4ca5A4; Wed, 14 Jun 2017 19:00:54 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.157] (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: arun@acklio.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 1658F41C080; Wed, 14 Jun 2017 19:00:52 +0200 (CEST) From: Arun Cc: Carles Gomez Montenegro , Laurent Toutain , Ana Minaburo To: lp-wan Message-ID: Date: Wed, 14 Jun 2017 19:00:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T4JsODfD0wrS63mEq8Cf8oFCGNpTG41nh" Archived-At: Subject: [lp-wan] identifying lost fragment in the last window X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 17:01:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T4JsODfD0wrS63mEq8Cf8oFCGNpTG41nh Content-Type: multipart/mixed; boundary="oWP7RDx6kv1NLW8q6tq0gIOvUqFxx65L4"; protected-headers="v1" From: Arun To: lp-wan Cc: Carles Gomez Montenegro , Laurent Toutain , Ana Minaburo Message-ID: Subject: identifying lost fragment in the last window --oWP7RDx6kv1NLW8q6tq0gIOvUqFxx65L4 Content-Type: multipart/alternative; boundary="------------07582BC66E8068E37B9D289E" This is a multi-part message in MIME format. --------------07582BC66E8068E37B9D289E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All,=20 Reference: doc:draft-ietf-lpwan-ipv6-static-context-hc-03, page:34, figur= e 18; from the receiver point of view,=20 how does he know that CFN=3D4 is lost ? when he receives the CFN=3D7 ? t= o create the bitmap of 11010001.=20 MIC check will fail after CFN=3D7 but I couldn't get to understand how th= e receiver can identify if only CFN=3D4 is lost or CFN=3D3,2,1(if any)...= are also lost. Am I missing something ? Sender Receiver |-----W=3D1, CFN=3D6----->| |-----W=3D1, CFN=3D5----->| |-----W=3D1, CFN=3D4--X-->| |-----W=3D1, CFN=3D3----->| |-----W=3D1, CFN=3D2--X-->| |-----W=3D1, CFN=3D1----->| |-----W=3D1, CFN=3D0----->| |<-------ACK----------|bitmap:11010111 |-----W=3D1, CFN=3D4----->| |-----W=3D1, CFN=3D2----->| |<-------ACK----------|no bitmap |-----W=3D0, CFN=3D6----->| |-----W=3D0, CFN=3D5----->| |-----W=3D0, CFN=3D4--X-->| |-----W=3D0, CFN=3D7----->|MIC checked |<-------ACK----------|bitmap:11010001 |-----W=3D0, CFN=3D4----->|MIC checked =3D> |<-------ACK----------|no bitmap (End) similar question on Figure 16. Ack on Error. thanks, Arun --------------07582BC66E8068E37B9D289E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 

Hi All,=20


Reference: doc:draft-ietf-lpwan-ipv6-static-context-hc-03, page:34, figur=
e 18;

from the receiver point of view,=20
how does he know that CFN=3D4 is lost ? when he receives the CFN=3D7 ?  t=
o create the bitmap of 11010001.=20

MIC check will fail after CFN=3D7 but I couldn't get to understand how th=
e receiver can identify if only CFN=3D4 is lost or CFN=3D3,2,1(if any)...=
 are also lost.

Am I missing something ?

	    Sender     	         Receiver
             |-----W=3D1, CFN=3D6----->|
             |-----W=3D1, CFN=3D5----->|
             |-----W=3D1, CFN=3D4--X-->|
             |-----W=3D1, CFN=3D3----->|
             |-----W=3D1, CFN=3D2--X-->|
             |-----W=3D1, CFN=3D1----->|
             |-----W=3D1, CFN=3D0----->|
             |<-------ACK----------|bitmap:11010111
             |-----W=3D1, CFN=3D4----->|
             |-----W=3D1, CFN=3D2----->|
             |<-------ACK----------|no bitmap
             |-----W=3D0, CFN=3D6----->|
             |-----W=3D0, CFN=3D5----->|
             |-----W=3D0, CFN=3D4--X-->|
             |-----W=3D0, CFN=3D7----->|MIC checked
             |<-------ACK----------|bitmap:11010001
             |-----W=3D0, CFN=3D4----->|MIC checked =3D>
             |<-------ACK----------|no bitmap
           (End)

similar question on Figure 16. Ack on Error.

thanks,
Arun
--------------07582BC66E8068E37B9D289E-- --oWP7RDx6kv1NLW8q6tq0gIOvUqFxx65L4-- --T4JsODfD0wrS63mEq8Cf8oFCGNpTG41nh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZQWu/AAoJENe8HNMjzJQRzTEP/A1dXzUcVbU/r4NzHZOOzfFv WBUjFF25IAuWdgXRdBU107RpyuX3vE4/dM1HZZrtHCUqqPYE7MoOeNkKkou7FKnw 1r1YgoNMEHGDTcldZo9iEx8XECBSGxawxKse8IZ5cQJLx2nS0GlBDoSOUlwhopm5 8NIZRuDhkjRh9JNTxmlUkWlCyQWpEAb51gxx6YXHcjzWJElpcMXZDDAKncZDpquZ e9kVDSGAqmpawjVsVDa7iqibuIByhY/cHm1vkjA67f+oAOEgVaBUHwDg9HWO9ThT ii2Iz+/RQOOZ+7FGyuOS4EDR9ps2PoisU1rtjOwzBfY/zc5rTnD3LjAeMUnZ1GXn vuU7Bj+aInNwszyJZk5l5cJDFec+CVyBdgvKlYkggI2j9t3nTwRZvUVT/iWzNk9D 3sQb5hz6pv5QvK9rC9wYVP+5gupykmMFJkUdXhY5CR6115Ezu0izSyOrGis8I0OV QleCeCL6bjYN2otyJAC2igDF6YO7mrmsgjaRSJAWIAZoaCmmaSvkk1m30sYbBGaI TfivosfMDPKUMg/kTVXYQC5IS2lTgCuBpdD8WcIeNH8/7XLTOeS9yYUd2Yv6k5lq VFqrISxWXt1C2pyahE5uSK03s7HYU8qpx+/j7CCYdd8JGmAiJZ/NTKE9bV36X1Eq ol2uMTyzmmHZuSpqf9NQ =pSzD -----END PGP SIGNATURE----- --T4JsODfD0wrS63mEq8Cf8oFCGNpTG41nh-- From nobody Wed Jun 14 12:17:03 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375AE12EAF9 for ; Wed, 14 Jun 2017 12:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Lxeeva25la_5 for ; Wed, 14 Jun 2017 12:17:00 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F55212EAEE for ; Wed, 14 Jun 2017 12:17:00 -0700 (PDT) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id AE8A541C097 for ; Wed, 14 Jun 2017 21:16:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id COQNqnAy-oUq for ; Wed, 14 Jun 2017 21:16:57 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.11] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 62BD041C091 for ; Wed, 14 Jun 2017 21:16:56 +0200 (CEST) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 14 Jun 2017 21:16:54 +0200 To: lp-wan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Agenda for LPWAN interim meeting next Wednesday, June 26th, 16h-17h CEST (7-8am US Pacific) X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 19:17:02 -0000 Dear all, You=E2=80=99ll find the updated agenda at the following address: = https://datatracker.ietf.org/doc/agenda-interim-2017-lpwan-05-lpwan-01/ We=E2=80=99ll have an update on the last elements of IP/UDP before WGLC, = as well as the progression of the LPWAN Overview document. We=E2=80=99ll also discuss more in length the future work items we = should consider. Best, The chairs= From nobody Thu Jun 15 06:22:51 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C00129BC5 for ; Thu, 15 Jun 2017 06:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 aN_1OEDBuzmg for ; Thu, 15 Jun 2017 06:22:48 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 C7F8E1294F5 for ; Thu, 15 Jun 2017 06:22:47 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5FDMiro001022; Thu, 15 Jun 2017 15:22:44 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 4406A1D53C1; Thu, 15 Jun 2017 15:22:43 +0200 (CEST) Received: from 147.83.113.31 by webmail.entel.upc.edu with HTTP; Thu, 15 Jun 2017 15:22:17 +0200 Message-ID: <412c883ef502143bba8c24a146bd3319.squirrel@webmail.entel.upc.edu> In-Reply-To: References: Date: Thu, 15 Jun 2017 15:22:17 +0200 From: "Carles Gomez Montenegro" To: "Arun" Cc: "lp-wan" , "Laurent Toutain" , "Ana Minaburo" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Thu, 15 Jun 2017 15:22:44 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] identifying lost fragment in the last window X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 13:22:50 -0000 Hi Arun, Thanks for pointing this out! Yes, this kind of ambiguity can be easily removed if in the last window (the one that contains the "all ones CFN", CFN=7 in the example), a receiver only uses the last bit in the bitmap to report about the "all ones CFN". In that case, the last bitmap in the example would be 11000001. We will make sure that the next draft update (the -04 that is coming soon) reflects this behavior correctly. Cheers, Carles > Hi All, > > > Reference: doc:draft-ietf-lpwan-ipv6-static-context-hc-03, page:34, figure > 18; > > from the receiver point of view, > how does he know that CFN=4 is lost ? when he receives the CFN=7 ? to > create the bitmap of 11010001. > > MIC check will fail after CFN=7 but I couldn't get to understand how the > receiver can identify if only CFN=4 is lost or CFN=3,2,1(if any)... are > also lost. > > Am I missing something ? > > Sender Receiver > |-----W=1, CFN=6----->| > |-----W=1, CFN=5----->| > |-----W=1, CFN=4--X-->| > |-----W=1, CFN=3----->| > |-----W=1, CFN=2--X-->| > |-----W=1, CFN=1----->| > |-----W=1, CFN=0----->| > |<-------ACK----------|bitmap:11010111 > |-----W=1, CFN=4----->| > |-----W=1, CFN=2----->| > |<-------ACK----------|no bitmap > |-----W=0, CFN=6----->| > |-----W=0, CFN=5----->| > |-----W=0, CFN=4--X-->| > |-----W=0, CFN=7----->|MIC checked > |<-------ACK----------|bitmap:11010001 > |-----W=0, CFN=4----->|MIC checked => > |<-------ACK----------|no bitmap > (End) > > similar question on Figure 16. Ack on Error. > > thanks, > Arun > From nobody Fri Jun 16 01:20:38 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A80C9131641; Fri, 16 Jun 2017 01:20:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149760122962.24272.5812926435529393667@ietfa.amsl.com> Date: Fri, 16 Jun 2017 01:20:29 -0700 Archived-At: Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-04.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 08:20:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Low Power Wide-Area Networks of the IETF. Title : LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP Authors : Ana Minaburo Laurent Toutain Carles Gomez Filename : draft-ietf-lpwan-ipv6-static-context-hc-04.txt Pages : 36 Date : 2017-06-16 Abstract: This document describes a header compression scheme and fragmentation functionality for very low bandwidth networks. These techniques are especially tailored for LPWAN (Low Power Wide Area Network) networks. The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields and must be used for this kind of networks. A common context stored in a LPWAN device and in the network is used. This context stores information that will not be transmitted in the constrained network. Static context means that information stored in the context which describes field values, does not change during packet transmission, avoiding complex resynchronization mechanisms, incompatible with LPWAN characteristics. In most of the cases, IPv6/UDP headers are reduced to a small identifier called Rule ID. But sometimes the SCHC header compression will not be enough to send the packet in one L2 PDU, so this document also describes a Fragmentation protocol that must be used when needed. This document describes the generic compression/decompression mechanism and applies it to IPv6/UDP headers. Similar mechanisms for other protocols such as CoAP will be described in separate documents. Moreover, this document specifies fragmentation and reassembly mechanims for SCHC compressed packets exceeding the L2 PDU size and for the case where the SCHC compression is not possible then the IPv6/UDP packet is sent using the fragmentation protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-04 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 16 01:25:41 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC79131675 for ; Fri, 16 Jun 2017 01:25:39 -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] 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 pZ3mUO5I1OOW for ; Fri, 16 Jun 2017 01:25:32 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87E1131678 for ; Fri, 16 Jun 2017 01:25:29 -0700 (PDT) Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 22158FB8BC; Fri, 16 Jun 2017 10:25:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3r3-5Fj4Ae4D; Fri, 16 Jun 2017 10:25:21 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from el-meco.rennes.enst-bretagne.fr (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: ana@ackl.io) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 28C88FB8A1; Fri, 16 Jun 2017 10:25:19 +0200 (CEST) From: Ana Minaburo Content-Type: multipart/mixed; boundary="Apple-Mail=_3E5D47C9-4B01-4661-9F00-BA35652A0EF1" Date: Fri, 16 Jun 2017 10:25:24 +0200 Message-Id: Cc: Alexander Pelov , "Pascal Thubert (pthubert)" To: lp-wan Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [lp-wan] New version of draft SCHC compression and fragmentation X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 08:25:40 -0000 --Apple-Mail=_3E5D47C9-4B01-4661-9F00-BA35652A0EF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello LPWANers, I hope you are all fine! I want to announce that we have published a new version of the draft = SCHC compression and fragmentation. We would like to receive your = comments and questions. Thanks Ana --Apple-Mail=_3E5D47C9-4B01-4661-9F00-BA35652A0EF1 Content-Disposition: attachment; filename=draft-ietf-lpwan-ipv6-static-context-hc-04.txt Content-Type: text/plain; name="draft-ietf-lpwan-ipv6-static-context-hc-04.txt" Content-Transfer-Encoding: quoted-printable lpwan Working Group A. Minaburo Internet-Draft Acklio Intended status: Informational L. Toutain Expires: December 18, 2017 IMT-Atlantique C. Gomez Universitat Politecnica de Catalunya June 16, 2017 LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP draft-ietf-lpwan-ipv6-static-context-hc-04 Abstract This document describes a header compression scheme and fragmentation functionality for very low bandwidth networks. These techniques are especially tailored for LPWAN (Low Power Wide Area Network) networks. The Static Context Header Compression (SCHC) offers a great level of flexibility when processing the header fields and must be used for this kind of networks. A common context stored in a LPWAN device and in the network is used. This context stores information that will not be transmitted in the constrained network. Static context means that information stored in the context which describes field values, does not change during packet transmission, avoiding complex resynchronization mechanisms, incompatible with LPWAN characteristics. In most of the cases, IPv6/UDP headers are reduced to a small identifier called Rule ID. But sometimes the SCHC header compression will not be enough to send the packet in one L2 PDU, so this document also describes a Fragmentation protocol that must be used when needed. This document describes the generic compression/decompression mechanism and applies it to IPv6/UDP headers. Similar mechanisms for other protocols such as CoAP will be described in separate documents. Moreover, this document specifies fragmentation and reassembly mechanims for SCHC compressed packets exceeding the L2 PDU size and for the case where the SCHC compression is not possible then the IPv6/UDP packet is sent using the fragmentation protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute Minaburo, et al. Expires December 18, 2017 [Page 1] =0C Internet-Draft LPWAN SCHC June 2017 working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 18, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Static Context Header Compression . . . . . . . . . . . . . . 6 4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Packet processing . . . . . . . . . . . . . . . . . . . . 9 5. Matching operators . . . . . . . . . . . . . . . . . . . . . 10 6. Compression Decompression Actions (CDA) . . . . . . . . . . . 11 6.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . . . 12 6.2. value-sent CDA . . . . . . . . . . . . . . . . . . . . . 12 6.3. mapping-sent . . . . . . . . . . . . . . . . . . . . . . 12 6.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. DEViid, APPiid CDA . . . . . . . . . . . . . . . . . . . 13 6.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Application to IPv6 and UDP headers . . . . . . . . . . . . . 14 7.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 14 7.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 14 7.3. Flow label field . . . . . . . . . . . . . . . . . . . . 14 7.4. Payload Length field . . . . . . . . . . . . . . . . . . 15 7.5. Next Header field . . . . . . . . . . . . . . . . . . . . 15 Minaburo, et al. Expires December 18, 2017 [Page 2] =0C Internet-Draft LPWAN SCHC June 2017 7.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . . 15 7.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . . 16 7.7.1. IPv6 source and destination prefixes . . . . . . . . 16 7.7.2. IPv6 source and destination IID . . . . . . . . . . . 16 7.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . . 17 7.9. UDP source and destination port . . . . . . . . . . . . . 17 7.10. UDP length field . . . . . . . . . . . . . . . . . . . . 17 7.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 18 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. IPv6/UDP compression . . . . . . . . . . . . . . . . . . 18 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Reliability options: definition . . . . . . . . . . . . . 22 9.3. Reliability options: discussion . . . . . . . . . . . . . 23 9.4. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.5. Formats . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.5.1. Fragment format . . . . . . . . . . . . . . . . . . . 24 9.5.2. Fragmentation header formats . . . . . . . . . . . . 24 9.5.3. ACK format . . . . . . . . . . . . . . . . . . . . . 26 9.6. Baseline mechanism . . . . . . . . . . . . . . . . . . . 28 9.7. Supporting multiple window sizes . . . . . . . . . . . . 29 9.8. Aborting fragmented IPv6 datagram transmissions . . . . . 30 9.9. Downlink fragment transmission . . . . . . . . . . . . . 30 10. Security considerations . . . . . . . . . . . . . . . . . . . 30 10.1. Security considerations for header compression . . . . . 30 10.2. Security considerations for fragmentation . . . . . . . 31 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Fragmentation examples . . . . . . . . . . . . . . . 32 Appendix B. Rule IDs for fragmentation . . . . . . . . . . . . . 35 Appendix C. Note . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction Header compression is mandatory to efficiently bring Internet connectivity to the node within a LPWAN network. Some LPWAN networks properties can be exploited for an efficient header compression: o Topology is star-oriented, therefore all the packets follow the same path. For the needs of this draft, the architecture can be summarized to Devices (Dev) exchanging information with LPWAN Application Server (App) through a Network Gateway (NGW). Minaburo, et al. Expires December 18, 2017 [Page 3] =0C Internet-Draft LPWAN SCHC June 2017 o Traffic flows are mostly known in advance, since devices embed built-in applications. Contrary to computers or smartphones, new applications cannot be easily installed. The Static Context Header Compression (SCHC) is defined for this environment. SCHC uses a context where header information is kept in the header format order. This context is static (the values on the header fields do not change over time) avoiding complex resynchronization mechanisms, incompatible with LPWAN characteristics. In most of the cases, IPv6/UDP headers are reduced to a small context identifier. The SCHC header compression mechanism is independent of the specific LPWAN technology over which it will be used. LPWAN technologies are also characterized, among others, by a very reduced data unit and/or payload size [I-D.ietf-lpwan-overview]. However, some of these technologies do not support layer two fragmentation, therefore the only option for these to support the IPv6 MTU requirement of 1280 bytes [RFC2460] is the use of a fragmentation protocol at the adaptation layer below IPv6. This draft defines also a fragmentation functionality to support the IPv6 MTU requirements over LPWAN technologies. Such functionality has been designed under the assumption that data unit reordering will not happen between the entity performing fragmentation and the entity performing reassembly. 2. LPWAN Architecture LPWAN technologies have similar architectures but different terminology. We can identify different types of entities in a typical LPWAN network, see Figure 1: o Devices (Dev) are the end-devices or hosts (e.g. sensors, actuators, etc.). There can be a high density of devices per radio gateway. o The Radio Gateway (RG), which is the end point of the constrained link. o The Network Gateway (NGW) is the interconnection node between the Radio Gateway and the Internet. o LPWAN-AAA Server, which controls the user authentication, the applications. We use the term LPWAN-AAA server because we are not assuming that this entity speaks RADIUS or Diameter as many/most AAA servers do, but equally we don't want to rule that out, as the functionality will be similar. Minaburo, et al. Expires December 18, 2017 [Page 4] =0C Internet-Draft LPWAN SCHC June 2017 o Application Server (App) +------+ () () () | |LPWAN-| () () () () / \ +---------+ | AAA | () () () () () () / \=3D=3D=3D=3D=3D=3D=3D| ^ |=3D=3D=3D=3D|Se= rver| +-----------+ () () () | | <--|--> | +------+ |APPLICATION| () () () () / \=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| v = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| (App) | () () () / \ +---------+ +-----------+ Dev Radio Gateways NGW Figure 1: LPWAN Architecture 3. Terminology This section defines the terminology and acronyms used in this document. o CDA: Compression/Decompression Action. An action that is perfomed for both functionnalities to compress a header field or to recover its original value in the decompression phase. o Context: A set of rules used to compress/decompress headers o Dev: Device. Node connected to the LPWAN. A Dev may implement SCHC. o App: LPWAN Application. An application sending/receiving IPv6 packets to/from the Device. o SCHC C/D: LPWAN Compressor/Decompressor. A process in the network to achieve compression/decompressing headers. SCHC C/D uses SCHC rules to perform compression and decompression. o MO: Matching Operator. An operator used to match a value contained in a header field with a value contained in a Rule. o Rule: A set of header field values. o Rule ID: An identifier for a rule, SCHC C/D and Dev share the same Rule ID for a specific flow. o TV: Target value. A value contained in the Rule that will be matched with the value of a header field. o FID: Field Indentifier is an index to describe the header fields in the Rule Minaburo, et al. Expires December 18, 2017 [Page 5] =0C Internet-Draft LPWAN SCHC June 2017 o FP: Field Position is a list of possible correct values that a field may use o DI: Direction Indicator is a differentiator for matching in order to be able to have different values for both sides. o IID: Interface Identifier. See the IPv6 addressing architecture [RFC7136] o Dev-IID: Device Interface Identifier. Second part of the IPv6 address to identify the device interface o APP-IID: Application Interface Identifier. Second part of the IPv6 address to identify the application interface o Dw: Down Link direction for compression, from SCHC C/D to Dev o Up: Up Link direction for compression, from Dev to SCHC C/D o Bi: Bidirectional, it can be used in both senses 4. Static Context Header Compression Static Context Header Compression (SCHC) avoids context synchronization, which is the most bandwidth-consuming operation in other header compression mechanisms such as RoHC [RFC5795]. Based on the fact that the nature of data flows is highly predictable in LPWAN networks, a static context may be stored on the Device (Dev). The context must be stored in both ends, and it can either be learned by a provisioning protocol or by out of band means or it can be pre- provosioned, etc. The way the context is learned on both sides is out of the scope of this document. Minaburo, et al. Expires December 18, 2017 [Page 6] =0C Internet-Draft LPWAN SCHC June 2017 Dev App +---------------+ +---------------+ | APP1 APP2 APP3| |APP1 APP2 APP3| | | | | | UDP | | UDP | | IPv6 | | IPv6 | | | | | | SCHC C/D | | | | (context) | | | +--------+------+ +-------+-------+ | +--+ +----+ +---------+ . +~~ |RG| =3D=3D=3D |NGW | =3D=3D=3D |SCHC C/D |... Internet = ... +--+ +----+ |(context)| +---------+ Figure 2: Architecture Figure 2 based on [I-D.ietf-lpwan-overview] terminology represents the architecture for compression/decompression. The Device is sending applications flows using IPv6 or IPv6/UDP protocols. These flows are compressed by an Static Context Header Compression Compressor/Decompressor (SCHC C/D) to reduce headers size. Resulting information is sent on a layer two (L2) frame to the LPWAN Radio Network to a Radio Gateway (RG) which forwards the frame to a Network Gateway (NGW). The NGW sends the data to a SCHC C/D for decompression which shares the same rules with the Dev. The SCHC C/D can be located on the Network Gateway (NGW) or in another place as long as a tunnel is established between the NGW and the SCHC C/D. SCHC C/D in both sides must share the same set of Rules. After decompression, the packet can be sent on the Internet to one or several LPWAN Application Servers (App). The SCHC C/D process is bidirectional, so the same principles can be applied in the other direction. 4.1. SCHC Rules The main idea of the SCHC compression scheme is to send the Rule id to the other end that match as much as possible the original packet values instead of sending known field values. When a value is known by both ends, it is not necessary sent through the LPWAN network. The context contains a list of rules (cf. Figure 3). Each Rule contains itself a list of fields descriptions composed of a field identifier (FID), a field position (FP), a direction indicator (DI), a target value (TV), a matching operator (MO) and a Compression/ Decompression Action (CDA). Minaburo, et al. Expires December 18, 2017 [Page 7] =0C Internet-Draft LPWAN SCHC June 2017 /--------------------------------------------------------------\ | Rule N | /--------------------------------------------------------------\| | Rule i || /--------------------------------------------------------------\|| | (FID) Rule 1 ||| |+-------+--+--+------------+-----------------+---------------+||| ||Field 1|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| |+-------+--+--+------------+-----------------+---------------+||| ||Field 2|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| |+-------+--+--+------------+-----------------+---------------+||| ||... |..|..| ... | ... | ... |||| |+-------+--+--+------------+-----------------+---------------+||/ ||Field N|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| |+-------+--+--+------------+-----------------+---------------+|/ | | \--------------------------------------------------------------/ Figure 3: Compression/Decompression Context The Rule does not describe the original packet format which must be known from the compressor/decompressor. The rule just describes the compression/decompression behavior for the header fields. In the rule, the description of the header field must be performed in the format packet order. The Rule describes also the compressed header fields which are transmitted regarding their position in the rule which is used for data serialization on the compressor side and data deserialization on the decompressor side. The Context describes the header fields and its values with the following entries: o A Field ID (FID) is a unique value to define the header field. o A Field Position (FP) indicating if several instances of the field exist in the headers which one is targeted. The default position is 1 o A direction indicator (DI) indicating the packet direction. Three values are possible: * UP LINK (Up) when the field or the value is only present in packets sent by the Dev to the App, * DOWN LINK (Dw) when the field or the value is only present in packet sent from the App to the Dev and Minaburo, et al. Expires December 18, 2017 [Page 8] =0C Internet-Draft LPWAN SCHC June 2017 * BIDIRECTIONAL (Bi) when the field or the value is present either upstream or downstream. o A Target Value (TV) is the value used to make the comparison with the packet header field. The Target Value can be of any type (integer, strings,...). For instance, it can be a single value or a more complex structure (array, list,...), such as a JSON or a CBOR structure. o A Matching Operator (MO) is the operator used to make the comparison between the Field Value and the Target Value. The Matching Operator may require some parameters. MO is only used during the compression phase. o A Compression Decompression Action (CDA) is used to describe the compression and the decompression process. The CDA may require some parameters, CDA are used in both compression and decompression phases. 4.2. Rule ID Rule IDs are sent between both compression/decompression elements. The size of the Rule ID is not specified in this document, it is implementation-specific and can vary regarding the LPWAN technology, the number of flows, among others. Some values in the Rule ID space may be reserved for goals other than header compression as fragmentation. (See Section 9). Rule IDs are specific to a Dev. Two Devs may use the same Rule ID for different header compression. To identify the correct Rule ID, the SCHC C/D needs to combine the Rule ID with the Dev L2 identifier to find the appropriate Rule. 4.3. Packet processing The compression/decompression process follows several steps: o compression Rule selection: The goal is to identify which Rule(s) will be used to compress the packet's headers. When doing compression from Dw to Up the SCHC C/D needs to find the correct Rule to use by identifying its Dev-ID and the Rule-ID. In the Up situation only the Rule-ID is used. The next step is to choose the fields by their direction, using the direction indicator (DI), so the fields that does not correspond to the appropiated DI will be excluded. Next, then fields are identified according to their field identifier (FID) and field position (FP). If the field position does not correspond then the Rule is not use and the SCHC Minaburo, et al. Expires December 18, 2017 [Page 9] =0C Internet-Draft LPWAN SCHC June 2017 take next Rule. Once the DI and the FP correspond to the header information, each field's value is then compared to the corresponding target value (TV) stored in the Rule for that specific field using the matching operator (MO). If all the fields in the packet's header satisfy all the matching operators (MOs) of a Rule (i.e. all results are True), the fields of the header are then processed according to the Compression/ Decompession Actions (CDAs) and a compressed header is obtained. Otherwise the next rule is tested. If no eligible rule is found, then the header must be sent without compression, in which case the fragmentation process must be required. o sending: The Rule ID is sent to the other end followed by information resulting from the compression of header fields. This information is sent in the order expressed in the Rule for the matching fields. The way the Rule ID is sent depends on the specific LPWAN layer two technology and will be specified in a specific document, and is out of the scope of this document. For example, it can be either included in a Layer 2 header or sent in the first byte of the L2 payload. (cf. Figure 4). o decompression: In both directions, The receiver identifies the sender through its device-id (e.g. MAC address) and selects the appropriate Rule through the Rule ID. This Rule gives the compressed header format and associates these values to header fields. It applies the CDA action to reconstruct the original header fields. The CDA application order can be different of the order given by the Rule. For instance Compute-* may be applied at end, after the other CDAs. +--- ... ---+-------------- ... --------------+ | Rule ID |Compressed Hdr Fields information| +--- ... ---+-------------- ... --------------+ Figure 4: LPWAN Compressed Format Packet 5. Matching operators Matching Operators (MOs) are functions used by both SCHC C/D endpoints involved in the header compression/decompression. They are not typed and can be applied indifferently to integer, string or any other data type. The result of the operation can either be True or False. MOs are defined as follows: o equal: A field value in a packet matches with a TV in a Rule if they are equal. Minaburo, et al. Expires December 18, 2017 [Page 10] =0C Internet-Draft LPWAN SCHC June 2017 o ignore: No check is done between a field value in a packet and a TV in the Rule. The result of the matching is always true. o MSB(length): A matching is obtained if the most significant bits of the length field value bits of the header are equal to the TV in the rule. The MSB Matching Operator needs a parameter, indicating the number of bits, to proceed to the matching. o match-mapping: The goal of mapping-sent is to reduce the size of a field by allocating a shorter value. The Target Value contains a list of values. Each value is idenfied by a short ID (or index). This operator matches if a field value is equal to one of those target values. 6. Compression Decompression Actions (CDA) The Compression Decompression Actions (CDA) describes the action taken during the compression of headers fields, and inversely, the action taken by the decompressor to restore the original value. /--------------------+-------------+----------------------------\ | Action | Compression | Decompression | | | | | +--------------------+-------------+----------------------------+ |not-sent |elided |use value stored in ctxt | |value-sent |send |build from received value | |mapping-sent |send index |value from index on a table | |LSB(length) |send LSB |TV OR received value | |compute-length |elided |compute length | |compute-checksum |elided |compute UDP checksum | |Deviid |elided |build IID from L2 Dev addr | |Appiid |elided |build IID from L2 App addr | \--------------------+-------------+----------------------------/ Figure 5: Compression and Decompression Functions Figure 5 sumarizes the basics functions defined to compress and decompress a field. The first column gives the action's name. The second and third columns outlines the compression/decompression behavior. Compression is done in the rule order and compressed values are sent in that order in the compressed message. The receiver must be able to find the size of each compressed field which can be given by the rule or may be sent with the compressed header. Minaburo, et al. Expires December 18, 2017 [Page 11] =0C Internet-Draft LPWAN SCHC June 2017 If the field is identified as variable, then its size must be sent first using the following coding: o If the size is between 0 and 14 bytes it is sent using 4 bits. o For values between 15 and 255, the first 4 bit sent are set to 1 and the size is sent using 8 bits. o For higher value, the first 12 bytes are set to 1 and the size is sent on 2 bytes. 6.1. not-sent CDA Not-sent function is generally used when the field value is specified in the rule and therefore known by the both Compressor and Decompressor. This action is generally used with the "equal" MO. If MO is "ignore", there is a risk to have a decompressed field value different from the compressed field. The compressor does not send any value on the compressed header for the field on which compression is applied. The decompressor restores the field value with the target value stored in the matched rule. 6.2. value-sent CDA The value-sent action is generally used when the field value is not known by both Compressor and Decompressor. The value is sent in the compressed message header. Both Compressor and Decompressor must know the size of the field, either implicitly (the size is known by both sides) or explicitly in the compressed header field by indicating the length. This function is generally used with the "ignore" MO. The compressor sends the Target Value stored on the rule in the compressed header message. The decompressor restores the field value with the one received from the LPWAN 6.3. mapping-sent mapping-sent is used to send a smaller index associated to the list of values in the Target Value. This function is used together with the "match-mapping" MO. The compressor looks in the TV to find the field value and send the corresponding index. The decompressor uses this index to restore the field value. Minaburo, et al. Expires December 18, 2017 [Page 12] =0C Internet-Draft LPWAN SCHC June 2017 The number of bits sent is the minimal size to code all the possible indexes. 6.4. LSB CDA LSB action is used to avoid sendind the known part of the packet field header to the other end. This action is used together with the "MSB" MO. A length can be specified in the rule to indicate how many bits have to be sent. If not length is specified, the number of bits sent are the field length minus the bits length specified in the MSB MO. The compressor sends the "length" Least Significant Bits. The decompressor combines the value received with the Target Value. If this action is made on a variable length field, the remaning size in byte has to be sent before. 6.5. DEViid, APPiid CDA These functions are used to process respectively the Dev and the App Interface Identifiers (Deviid and Appiid) of the IPv6 addresses. Appiid CDA is less common, since current LPWAN technologies frames contain a single address. The IID value can be computed from the Device ID present in the Layer 2 header. The computation is specific for each LPWAN technology and depends on the Device ID size. In the downstream direction, these CDA are used to determine the L2 addresses used by the LPWAN. 6.6. Compute-* Thes classes of functions are used by the decompressor to compute the compressed field value based on received information. Compressed fields are elided during compression and reconstructed during decompression. o compute-length: compute the length assigned to this field. For instance, regarding the field ID, this CDA may be used to compute IPv6 length or UDP length. o compute-checksum: compute a checksum from the information already received by the SCHC C/D. This field may be used to compute UDP checksum. Minaburo, et al. Expires December 18, 2017 [Page 13] =0C Internet-Draft LPWAN SCHC June 2017 7. Application to IPv6 and UDP headers This section lists the different IPv6 and UDP header fields and how they can be compressed. 7.1. IPv6 version field This field always holds the same value, therefore the TV is 6, the MO is "equal" and the "CDA "not-sent"". 7.2. IPv6 Traffic class field If the DiffServ field identified by the rest of the rule do not vary and is known by both sides, the TV should contain this well-known value, the MO should be "equal" and the CDA must be "not-sent. If the DiffServ field identified by the rest of the rule varies over time or is not known by both sides, then there are two possibilities depending on the variability of the value, the first one is to do not compressed the field and sends the original value, or the second where the values can be computed by sending only the LSB bits: o TV is not set to any value, MO is set to "ignore" and CDA is set to "value-sent" o TV contains a stable value, MO is MSB(X) and CDA is set to LSB 7.3. Flow label field If the Flow Label field identified by the rest of the rule does not vary and is known by both sides, the TV should contain this well- known value, the MO should be "equal" and the CDA should be "not- sent". If the Flow Label field identified by the rest of the rule varies during time or is not known by both sides, there are two possibilities depending on the variability of the value, the first one is without compression and then the value is sent and the second where only part of the value is sent and the decompressor needs to compute the original value: o TV is not set, MO is set to "ignore" and CDA is set to "value- sent" o TV contains a stable value, MO is MSB(X) and CDA is set to LSB Minaburo, et al. Expires December 18, 2017 [Page 14] =0C Internet-Draft LPWAN SCHC June 2017 7.4. Payload Length field If the LPWAN technology does not add padding, this field can be elided for the transmission on the LPWAN network. The SCHC C/D recomputes the original payload length value. The TV is not set, the MO is set to "ignore" and the CDA is "compute-IPv6-length". If the payload length needs to be sent and does not need to be coded in 16 bits, the TV can be set to 0x0000, the MO set to "MSB (16-s)" and the CDA to "LSB". The 's' parameter depends on the expected maximum packet length. On other cases, the payload length field must be sent and the CDA is replaced by "value-sent". 7.5. Next Header field If the Next Header field identified by the rest of the rule does not vary and is known by both sides, the TV should contain this Next Header value, the MO should be "equal" and the CDA should be "not- sent". If the Next header field identified by the rest of the rule varies during time or is not known by both sides, then TV is not set, MO is set to "ignore" and CDA is set to "value-sent". A matching-list may also be used. 7.6. Hop Limit field The End System is generally a device and does not forward packets, therefore the Hop Limit value is constant. So the TV is set with a default value, the MO is set to "equal" and the CDA is set to "not- sent". Otherwise the value is sent on the LPWAN: TV is not set, MO is set to ignore and CDA is set to "value-sent". Note that the field behavior differs in upstream and downstream. In upstream, since there is no IP forwarding between the Dev and the SCHC C/D, the value is relatively constant. On the other hand, the downstream value depends of Internet routing and may change more frequently. One solution could be to use the Direction Indicator (DI) to distinguish both directions to elide the field in the upstream direction and send the value in the downstream direction. Minaburo, et al. Expires December 18, 2017 [Page 15] =0C Internet-Draft LPWAN SCHC June 2017 7.7. IPv6 addresses fields As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit long fields; one for the prefix and one for the Interface Identifier (IID). These fields should be compressed. To allow a single rule, these values are identified by their role (DEV or APP) and not by their position in the frame (source or destination). The SCHC C/D must be aware of the traffic direction (upstream, downstream) to select the appropriate field. 7.7.1. IPv6 source and destination prefixes Both ends must be synchronized with the appropriate prefixes. For a specific flow, the source and destination prefix can be unique and stored in the context. It can be either a link-local prefix or a global prefix. In that case, the TV for the source and destination prefixes contains the values, the MO is set to "equal" and the CDA is set to "not-sent". In case the rule allows several prefixes, mapping-list must be used. The different prefixes are listed in the TV associated with a short ID. The MO is set to "match-mapping" and the CDA is set to "mapping- sent". Otherwise the TV contains the prefix, the MO is set to "equal" and the CDA is set to value-sent. 7.7.2. IPv6 source and destination IID If the DEV or APP IID are based on an LPWAN address, then the IID can be reconstructed with information coming from the LPWAN header. In that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "DEViid" or "APPiid". Note that the LPWAN technology is generally carrying a single device identifier corresponding to the DEV. The SCHC C/D may also not be aware of these values. If the DEV address has a static value that is not derivated from the EUI-64, then TV contains the value, the MO operator is set to "equal" and the CDA is set to "not-sent". If several IIDs are possible, then the TV contains the list of possible IIDs, the MO is set to "match-mapping" and the CDA is set to "mapping-sent". Otherwise the value variation of the IID may be reduced to few bytes. In that case, the TV is set to the stable part of the IID, the MO is set to MSB and the CDA is set to LSB. Minaburo, et al. Expires December 18, 2017 [Page 16] =0C Internet-Draft LPWAN SCHC June 2017 Finally, the IID can be sent on the LPWAN. In that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "value- sent". 7.8. IPv6 extensions No extension rules are currently defined. They can be based on the MOs and CDAs described above. 7.9. UDP source and destination port To allow a single rule, the UDP port values are identified by their role (DEV or APP) and not by their position in the frame (source or destination). The SCHC C/D must be aware of the traffic direction (upstream, downstream) to select the appropriate field. The following rules apply for DEV and APP port numbers. If both ends know the port number, it can be elided. The TV contains the port number, the MO is set to "equal" and the CDA is set to "not- sent". If the port variation is on few bits, the TV contains the stable part of the port number, the MO is set to "MSB" and the CDA is set to "LSB". If some well-known values are used, the TV can contain the list of this values, the MO is set to "match-mapping" and the CDA is set to "mapping-sent". Otherwise the port numbers are sent on the LPWAN. The TV is not set, the MO is set to "ignore" and the CDA is set to "value-sent". 7.10. UDP length field If the LPWAN technology does not introduce padding, the UDP length can be computed from the received data. In that case the TV is not set, the MO is set to "ignore" and the CDA is set to "compute-UDP- length". If the payload is small, the TV can be set to 0x0000, the MO set to "MSB" and the CDA to "LSB". On other cases, the length must be sent and the CDA is replaced by "value-sent". Minaburo, et al. Expires December 18, 2017 [Page 17] =0C Internet-Draft LPWAN SCHC June 2017 7.11. UDP Checksum field IPv6 mandates a checksum in the protocol above IP. Nevertheless, if a more efficient mechanism such as L2 CRC or MIC is carried by or over the L2 (such as in the LPWAN fragmentation process (see section Section 9)), the UDP checksum transmission can be avoided. In that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "compute-UDP-checksum". In other cases the checksum must be explicitly sent. The TV is not set, the MO is set to "ignore" and the CDF is set to "value-sent". 8. Examples This section gives some scenarios of the compression mechanism for IPv6/UDP. The goal is to illustrate the SCHC behavior. 8.1. IPv6/UDP compression The most common case using the mechanisms defined in this document will be a LPWAN Dev that embeds some applications running over CoAP. In this example, three flows are considered. The first flow is for the device management based on CoAP using Link Local IPv6 addresses and UDP ports 123 and 124 for Dev and App, respectively. The second flow will be a CoAP server for measurements done by the Device (using ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to beta::1/64. The last flow is for legacy applications using different ports numbers, the destination IPv6 address prefix is gamma::1/64. Figure 6 presents the protocol stack for this Device. IPv6 and UDP are represented with dotted lines since these protocols are compressed on the radio link. Minaburo, et al. Expires December 18, 2017 [Page 18] =0C Internet-Draft LPWAN SCHC June 2017 Managment Data +----------+---------+---------+ | CoAP | CoAP | legacy | +----||----+---||----+---||----+ . UDP . UDP | UDP | ................................ . IPv6 . IPv6 . IPv6 . +------------------------------+ | SCHC Header compression | | and fragmentation | +------------------------------+ | LPWAN L2 technologies | +------------------------------+ DEV or NGW Figure 6: Simplified Protocol Stack for LP-WAN Note that in some LPWAN technologies, only the Devs have a device ID. Therefore, when such technologies are used, it is necessary to define statically an IID for the Link Local address for the SCHC C/D. Rule 0 +----------------+--+--+---------+--------+-------------++------+ | Field |FP|DI| Value | Match | Comp Decomp || Sent | | | | | | Opera. | Action ||[bits]| +----------------+--+--+---------+----------------------++------+ |IPv6 version |1 |Bi|6 | equal | not-sent || | |IPv6 DiffServ |1 |Bi|0 | equal | not-sent || | |IPv6 Flow Label |1 |Bi|0 | equal | not-sent || | |IPv6 Length |1 |Bi| | ignore | comp-length || | |IPv6 Next Header|1 |Bi|17 | equal | not-sent || | |IPv6 Hop Limit |1 |Bi|255 | ignore | not-sent || | |IPv6 DEVprefix |1 |Bi|FE80::/64| equal | not-sent || | |IPv6 DEViid |1 |Bi| | ignore | DEViid || | |IPv6 APPprefix |1 |Bi|FE80::/64| equal | not-sent || | |IPv6 APPiid |1 |Bi|::1 | equal | not-sent || | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D+=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D++=3D=3D=3D=3D=3D=3D+ |UDP DEVport |1 |Bi|123 | equal | not-sent || | |UDP APPport |1 |Bi|124 | equal | not-sent || | |UDP Length |1 |Bi| | ignore | comp-length || | |UDP checksum |1 |Bi| | ignore | comp-chk || | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D+=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D++=3D=3D=3D=3D=3D=3D+ Rule 1 +----------------+--+--+---------+--------+-------------++------+ | Field |FP|DI| Value | Match | Action || Sent | | | | | | Opera. | Action ||[bits]| Minaburo, et al. Expires December 18, 2017 [Page 19] =0C Internet-Draft LPWAN SCHC June 2017 +----------------+--+--+---------+--------+-------------++------+ |IPv6 version |1 |Bi|6 | equal | not-sent || | |IPv6 DiffServ |1 |Bi|0 | equal | not-sent || | |IPv6 Flow Label |1 |Bi|0 | equal | not-sent || | |IPv6 Length |1 |Bi| | ignore | comp-length || | |IPv6 Next Header|1 |Bi|17 | equal | not-sent || | |IPv6 Hop Limit |1 |Bi|255 | ignore | not-sent || | |IPv6 DEVprefix |1 |Bi|[alpha/64, match- | mapping-sent|| [1] | | |1 |Bi|fe80::/64] mapping| || | |IPv6 DEViid |1 |Bi| | ignore | DEViid || | |IPv6 APPprefix |1 |Bi|[beta/64,| match- | mapping-sent|| [2] | | | | |alpha/64,| mapping| || | | | | |fe80::64]| | || | |IPv6 APPiid |1 |Bi|::1000 | equal | not-sent || | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D+=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D++=3D=3D=3D=3D=3D=3D+ |UDP DEVport |1 |Bi|5683 | equal | not-sent || | |UDP APPport |1 |Bi|5683 | equal | not-sent || | |UDP Length |1 |Bi| | ignore | comp-length || | |UDP checksum |1 |Bi| | ignore | comp-chk || | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D+=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D++=3D=3D=3D=3D=3D=3D+ Rule 2 +----------------+--+--+---------+--------+-------------++------+ | Field |FP|DI| Value | Match | Action || Sent | | | | | | Opera. | Action ||[bits]| +----------------+--+--+---------+--------+-------------++------+ |IPv6 version |1 |Bi|6 | equal | not-sent || | |IPv6 DiffServ |1 |Bi|0 | equal | not-sent || | |IPv6 Flow Label |1 |Bi|0 | equal | not-sent || | |IPv6 Length |1 |Bi| | ignore | comp-length || | |IPv6 Next Header|1 |Bi|17 | equal | not-sent || | |IPv6 Hop Limit |1 |Up|255 | ignore | not-sent || | |IPv6 Hop Limit |1 |Dw| | ignore | value-sent || [8] | |IPv6 DEVprefix |1 |Bi|alpha/64 | equal | not-sent || | |IPv6 DEViid |1 |Bi| | ignore | DEViid || | |IPv6 APPprefix |1 |Bi|gamma/64 | equal | not-sent || | |IPv6 APPiid |1 |Bi|::1000 | equal | not-sent || | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D+=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D++=3D=3D=3D=3D=3D=3D+ |UDP DEVport |1 |Bi|8720 | MSB(12)| LSB(4) || [4] | |UDP APPport |1 |Bi|8720 | MSB(12)| LSB(4) || [4] | |UDP Length |1 |Bi| | ignore | comp-length || | |UDP checksum |1 |Bi| | ignore | comp-chk || | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D+=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D++=3D=3D=3D=3D=3D=3D+ Figure 7: Context rules Minaburo, et al. Expires December 18, 2017 [Page 20] =0C Internet-Draft LPWAN SCHC June 2017 All the fields described in the three rules depicted on Figure 7 are present in the IPv6 and UDP headers. The DEViid-DID value is found in the L2 header. The second and third rules use global addresses. The way the Dev learns the prefix is not in the scope of the document. The third rule compresses port numbers to 4 bits. 9. Fragmentation 9.1. Overview Fragmentation support in LPWAN is mandatory when the underlying LPWAN technology is not capable of fulfilling the IPv6 MTU requirement. Fragmentation is used if, after SCHC header compression, the size of the resulting IPv6 packet is larger than the L2 data unit maximum payload. Fragmentation is also used if SCHC header compression has not been able to compress an IPv6 packet that is larger than the L2 data unit maximum payload. In LPWAN technologies, the L2 data unit size typically varies from tens to hundreds of bytes. If the entire IPv6 datagram fits within a single L2 data unit, the fragmentation mechanism is not used and the packet is sent unfragmented. If the datagram does not fit within a single L2 data unit, it SHALL be broken into fragments. Moreover, LPWAN technologies impose some strict limitations on traffic; therefore it is desirable to enable optional fragment retransmission, while a single fragment loss should not lead to retransmitting the full IPv6 datagram. On the other hand, in order to preserve energy, Devices are sleeping most of the time and may receive data during a short period of time after transmission. In order to adapt to the capabilities of various LPWAN technologies, this specification allows for a gradation of fragment delivery reliability. This document does not make any decision with regard to which fragment delivery reliability option is used over a specific LPWAN technology. An important consideration is that LPWAN networks typically follow the star topology, and therefore data unit reordering is not expected in such networks. This specification assumes that reordering will not happen between the entity performing fragmentation and the entity performing reassembly. This assumption allows to reduce complexity and overhead of the fragmentation mechanism. Minaburo, et al. Expires December 18, 2017 [Page 21] =0C Internet-Draft LPWAN SCHC June 2017 9.2. Reliability options: definition This specification defines the following three fragment delivery reliability options: o No ACK o Window mode - ACK "always" o Window mode - ACK on error The same reliability option MUST be used for all fragments of a packet. It is up to implementers and/or representatives of the underlying LPWAN technology to decide which reliability option to use and whether the same reliability option applies to all IPv6 packets or not. Note that the reliability option to be used is not necessarily tied to the particular characteristics of the underlying L2 LPWAN technology (e.g. the No ACK reliability option may be used on top of an L2 LPWAN technology with symmetric characteristics for uplink and downlink). In the No ACK option, the receiver MUST NOT issue acknowledgments (ACK). In Window mode - ACK "always", an ACK is transmitted by the fragment receiver after a window of fragments have been sent. A window of fragments is a subset of the full set of fragments needed to carry an IPv6 packet. In this mode, the ACK informs the sender about received and/or missing fragments from the window of fragments. In Window mode - ACK on error, an ACK is transmitted by the fragment receiver after a window of fragments have been sent, only if at least one of the fragments in the window has been lost. In this mode, the ACK informs the sender about received and/or missing fragments from the window of fragments. In Window mode, upon receipt of an ACK that informs about any lost fragments, the sender retransmits the lost fragments. The maximum number of ACKs to be sent by the receiver for a specific window, denoted MAX_ACKS_PER_WINDOW, is not stated in this document, and it is expected to be defined in other documents (e.g. technology- specific profiles). This document does not make any decision as to which fragment delivery reliability option(s) need to be supported over a specific LPWAN technology. Minaburo, et al. Expires December 18, 2017 [Page 22] =0C Internet-Draft LPWAN SCHC June 2017 Examples of the different reliability options described are provided in Appendix A. 9.3. Reliability options: discussion This section discusses the properties of each fragment delivery reliability option defined in the previous section. No ACK is the most simple fragment delivery reliability option. With this option, the receiver does not generate overhead in the form of ACKs. However, this option does not enhance delivery reliability beyond that offered by the underlying LPWAN technology. The Window mode - ACK on error option is based on the optimistic expectation that the underlying links will offer relatively low L2 data unit loss probability. This option reduces the number of ACKs transmitted by the fragment receiver compared to the Window mode - ACK "always" option. This may be especially beneficial in asymmetric scenarios, e.g. where fragmented data are sent uplink and the underlying LPWAN technology downlink capacity or message rate is lower than the uplink one. However, if an ACK is lost, the sender assumes that all fragments covered by the ACK have been successfully delivered. In contrast, the Window mode - ACK "always" option does not suffer that issue, at the expense of an ACK overhead increase. The Window mode - ACK "always" option provides flow control. In addition, it is able to handle long bursts of lost fragments, since detection of such events can be done before end of the IPv6 packet transmission, as long as the window size is short enough. However, such benefit comes at the expense of higher ACK overhead. 9.4. Tools This subsection describes the different tools that are used to enable the described fragmentation functionality and the different reliability options supported. Each tool has a corresponding header field format that is defined in the next subsection. The list of tools follows: o Rule ID. The Rule ID is used in fragments and in ACKs. The Rule ID in a fragment is set to a value that indicates that the data unit being carried is a fragment. This also allows to interleave non- fragmented IPv6 datagrams with fragments that carry a larger IPv6 datagram. Rule ID may also be used to signal which reliability option is in use for the IPv6 packet being carried. In an ACK, the Rule ID signals that the message this Rule ID is prepended to is an ACK. Minaburo, et al. Expires December 18, 2017 [Page 23] =0C Internet-Draft LPWAN SCHC June 2017 o Compressed Fragment Number (CFN). The CFN is included in all fragments. This field can be understood as a truncated, efficient representation of a larger-sized fragment number, and does not necessarily carry an absolute fragment number. A special CFN value signals the last fragment that carries a fragmented IPv6 packet. In Window mode, the CFN is augmented with the W bit, which has the purpose of avoiding possible ambiguity for the receiver that might arise under certain conditions o Datagram Tag (DTag). The DTag field, if present, is set to the same value for all fragments carrying the same IPv6 datagram, allows to interleave fragments that correspond to different IPv6 datagrams. o Message Integrity Check (MIC). It is computed by the sender over the complete IPv6 packet before fragmentation by using the TBD algorithm. The MIC allows the receiver to check for errors in the reassembled IPv6 packet, while it also enables compressing the UDP checksum by use of SCHC. o Bitmap. The bitmap is a sequence of bits included in the ACK for a given window, that provides feedback on whether each fragment of the current window has been received or not. 9.5. Formats This section defines the fragment format, the fragmentation header formats, and the ACK format. 9.5.1. Fragment format A fragment comprises a fragmentation header and a fragment payload, and conforms to the format shown in Figure 8. The fragment payload carries a subset of either the IPv6 packet after header compression or an IPv6 packet which could not be compressed. A fragment is the payload in the L2 protocol data unit (PDU). +---------------+-----------------------+ | Fragm. Header | Fragment payload | +---------------+-----------------------+ Figure 8: Fragment format. 9.5.2. Fragmentation header formats In the No ACK option, fragments except the last one SHALL contain the fragmentation header as defined in Figure 9. The total size of this fragmentation header is R bits. Minaburo, et al. Expires December 18, 2017 [Page 24] =0C Internet-Draft LPWAN SCHC June 2017 <------------ R ----------> <--T--> <--N--> +-- ... --+- ... -+- ... -+ | Rule ID | DTag | CFN | +-- ... --+- ... -+- ... -+ Figure 9: Fragmentation Header for Fragments except the Last One, No ACK option In any of the Window mode options, fragments except the last one SHALL contain the fragmentation header as defined in Figure 10. The total size of this fragmentation header is R bits. <------------ R ----------> <--T--> 1 <--N--> +-- ... --+- ... -+-+- ... -+ | Rule ID | DTag |W| CFN | +-- ... --+- ... -+-+- ... -+ Figure 10: Fragmentation Header for Fragments except the Last One, Window mode The last fragment of an IPv6 datagram SHALL contain a fragmentation header that conforms to the format shown in Figure 11. The total size of this fragmentation header is R+M bits. <------------- R ------------> <- T -> <- N -> <---- M -----> +---- ... ---+- ... -+- ... -+---- ... ----+ | Rule ID | DTag | 11..1 | MIC | +---- ... ---+- ... -+- ... -+---- ... ----+ Figure 11: Fragmentation Header for the Last Fragment o Rule ID: This field has a size of R - T - N - 1 bits in all fragments that are not the last one, when Window mode is used. In all other fragments, the Rule ID field has a size of R - T - N bits. o DTag: The size of the DTag field is T bits, which may be set to a value greater than or equal to 0 bits. The DTag field in all fragments that carry the same IPv6 datagram MUST be set to the same value. DTag MUST be set sequentially increasing from 0 to 2^T - 1, and MUST wrap back from 2^T - 1 to 0. Minaburo, et al. Expires December 18, 2017 [Page 25] =0C Internet-Draft LPWAN SCHC June 2017 o CFN: This field is an unsigned integer, with a size of N bits, that carries the CFN of the fragment. In the No ACK option, N=3D1. For the rest of options, N equal to or greater than 3 is recommended. The CFN MUST be set sequentially decreasing from the highest CFN in the window (which will be used for the first fragment), and MUST wrap from 0 back to the highest CFN in the window. The highest CFN in the window MUST be a value equal to or smaller than 2^N-2. (Example 1: for N=3D5, the highest CFN value may be configured to be 30, then subsequent CFNs are set sequentially and in decreasing order, and CFN will wrap from 0 back to 30. Example 2: for N=3D5, the highest CFN value may be = set to 23, then subsequent CFNs are set sequentially and in decreasing order, and the CFN will wrap from 0 back to 23). The CFN for the last fragment has all bits set to 1. Note that, by this definition, the CFN value of 2^N - 1 is only used to identify a fragment as the last fragment carrying a subset of the IPv6 packet being transported, and thus the CFN does not strictly correspond to the N least significant bits of the actual absolute fragment number. It is also important to note that, for N=3D1, the last fragment of the packet will carry a CFN equal to 1, while all previous fragments will carry a CFN of 0. o W: W is a 1-bit field. This field carries the same value for all fragments of a window, and it is complemented for the next window. The initial value for this field is 1. o MIC: This field, which has a size of M bits, carries the MIC for the IPv6 packet. The values for R, N, T and M are not specified in this document, and have to be determined in other documents (e.g. technology-specific profile documents). 9.5.3. ACK format The format of an ACK is shown in Figure 12: <-------- R -------> <- T -> 1 +---- ... --+-... -+-+----- ... ---+ | Rule ID | DTag |W| bitmap | +---- ... --+-... -+-+----- ... ---+ Figure 12: Format of an ACK Rule ID: In all ACKs, Rule ID has a size of R - T - 1 bits. Minaburo, et al. Expires December 18, 2017 [Page 26] =0C Internet-Draft LPWAN SCHC June 2017 DTag: DTag has a size of T bits. DTag carries the same value as the DTag field in the fragments carrying the IPv6 datagram for which this ACK is intended. W: This field has a size of 1 bit. In all ACKs, the W bit carries the same value as the W bit carried by the fragments whose reception is being positively or negatively acknowledged by the ACK. bitmap: This field carries the bitmap sent by the receiver to inform the sender about whether fragments in the current window have been received or not. Size of the bitmap field of an ACK can be equal to 0 or Ceiling(Number_of_Fragments/8) octets, where Number_of_Fragments denotes the number of fragments of a window. The bitmap is a sequence of bits, where the n-th bit signals whether the n-th fragment transmitted in the current window has been correctly received (n-th bit set to 1) or not (n-th bit set to 0). Remaining bits with bit order greater than the number of fragments sent (as determined by the receiver) are set to 0, except for the last bit in the bitmap, which is set to 1 if the last fragment of the window has been correctly received, and 0 otherwise. Feedback on reception of the fragment with CFN =3D 2^N - 1 (last fragment carrying an IPv6 packet) is only given by the last bit of the corresponding window. Absence of the bitmap in an ACK confirms correct reception of all fragments to be acknowledged by means of the ACK. Figure 13 shows an example of an ACK (N=3D3), where the bitmap indicates that the second and the fifth fragments have not been correctly received. <------- R -------> <- T -> 0 1 2 3 4 5 6 7 +---- ... --+-... -+-+-+-+-+-+-+-+-+-+ | Rule ID | DTag |W|1|0|1|1|0|1|1|1| +---- ... --+-... -+-+-+-+-+-+-+-+-+-+ Figure 13: Example of the bitmap in an ACK (in Window mode, for N=3D3) Figure 14 illustrates an ACK without a bitmap. <------- R -------> <- T -> +---- ... --+-... -+-+ | Rule ID | DTag |W| +---- ... --+-... -+-+ Figure 14: Example of an ACK without a bitmap Minaburo, et al. Expires December 18, 2017 [Page 27] =0C Internet-Draft LPWAN SCHC June 2017 Note that, in order to exploit the available L2 payload space to the fullest, a bitmap may have a size smaller than 2^N bits. In that case, the window in use will have a size lower than 2^N-1 fragments. For example, if the maximum available space for a bitmap is 56 bits, N can be set to 6, and the window size can be set to a maximum of 56 fragments. 9.6. Baseline mechanism The receiver of link fragments SHALL use (1) the sender's L2 source address (if present), (2) the destination's L2 address (if present), (3) Rule ID and (4) DTag to identify all the fragments that belong to a given IPv6 datagram. The fragment receiver may determine the fragment delivery reliability option in use for the fragment based on the Rule ID field in that fragment. Upon receipt of a link fragment, the receiver starts constructing the original unfragmented packet. It uses the CFN and the order of arrival of each fragment to determine the location of the individual fragments within the original unfragmented packet. For example, it may place the data payload of the fragments within a payload datagram reassembly buffer at the location determined from the CFN and order of arrival of the fragments, and the fragment payload sizes. In Window mode, the fragment receiver also uses the W bit in the received fragments. Note that the size of the original, unfragmented IPv6 packet cannot be determined from fragmentation headers. When Window mode - ACK on error is used, the fragment receiver starts a timer (denoted "ACK on Error Timer") upon reception of the first fragment for an IPv6 datagram. The initial value for this timer is not provided by this specification, and is expected to be defined in additional documents. This timer is reset every time that a new fragment carrying data from the same IPv6 datagram is received. In Window mode - ACK on error, upon timer expiration, if neither the last fragment of the IPv6 datagram nor the last fragment of the current window (i.e. with CFN=3D0) have been received, an ACK MUST be transmitted by the fragment receiver to indicate received and not received fragments for the current window. Note that, in Window mode, the first fragment of the window is the one sent with CFN=3D2^N-2. Also note that, in Window mode, the fragment with CFN=3D0 is considered the last fragment of its window, except for the last fragment of the whole packet (with all CFN bits set to 1), which is also the last fragment of the last window. Upon receipt of the last fragment of a window, if Window mode - ACK "Always" is used, the fragment receiver MUST send an ACK to the fragment sender. The ACK provides feedback on the fragments received and lost that correspond to the last window. Minaburo, et al. Expires December 18, 2017 [Page 28] =0C Internet-Draft LPWAN SCHC June 2017 If the recipient receives the last fragment of an IPv6 datagram, it checks for the integrity of the reassembled IPv6 datagram, based on the MIC received. In No ACK mode, if the integrity check indicates that the reassembled IPv6 datagram does not match the original IPv6 datagram (prior to fragmentation), the reassembled IPv6 datagram MUST be discarded. If Window mode - ACK "Always" is used, the recipient MUST transmit an ACK to the fragment sender. The ACK provides feedback on the fragments that correspond to the last window. If Window mode - ACK on error is used, the recipient MUST NOT transmit an ACK to the sender if no losses have been detected for the last window. If losses have been detected, the recipient MUST then transmit an ACK to the sender to provide feedback on the last window. When Window mode - ACK "Always" is used, the fragment sender starts a timer (denoted "ACK Always Timer") after transmitting the last fragment of a fragmented IPv6 datagram. The fragment sender also starts the ACK Always Timer after transmitting the last fragment of a window. The initial value for this timer is not provided by this specification, and is expected to be defined in additional documents. Upon expiration of the timer, if no ACK has been received for the current window, the sender retransmits the last fragment, and it reinitializes and restarts the timer. Note that retransmitting the last fragment of a window as described serves as an ACK request. The maximum number of requests for a specific ACK, denoted MAX_ACK_REQUESTS, is not stated in this document, and it is expected to be defined in other documents (e.g. technology-specific profiles). In all Window mode options, the fragment sender retransmits any lost fragments reported in an ACK. If a fragment recipient disassociates from its L2 network, the recipient MUST discard all link fragments of all partially reassembled payload datagrams, and fragment senders MUST discard all not yet transmitted link fragments of all partially transmitted payload (e.g., IPv6) datagrams. Similarly, when a node first receives a fragment of a packet, it starts a reassembly timer. When this time expires, if the entire packet has not been reassembled, the existing fragments MUST be discarded and the reassembly state MUST be flushed. The value for this timer is not provided by this specification, and is expected to be defined in technology-specific profile documents. 9.7. Supporting multiple window sizes For Window mode operation, implementers may opt to support a single window size or multiple window sizes. The latter, when feasible, may provide performance optimizations. For example, a large window size may be used for IPv6 packets that need to be carried by a large Minaburo, et al. Expires December 18, 2017 [Page 29] =0C Internet-Draft LPWAN SCHC June 2017 number of fragments. However, when the number of fragments required to carry an IPv6 packet is low, a smaller window size, and thus a shorter bitmap, may be sufficient to provide feedback on all fragments. If multiple window sizes are supported, the Rule ID may be used to signal the window size in use for a specific IPv6 packet transmission. 9.8. Aborting fragmented IPv6 datagram transmissions For several reasons, a fragment sender or a fragment receiver may want to abort the on-going transmission of one or several fragmented IPv6 datagrams. The entity (either the fragment sender or the fragment receiver) that triggers abortion transmits to the other endpoint a format that only comprises a Rule ID (of size R bits), which signals abortion of all on-going fragmented IPv6 packet transmissions. The specific value to be used for the Rule ID of this abortion signal is not defined in this document, and is expected to be defined in future documents. Upon transmission or reception of the abortion signal, both entities MUST release any resources allocated for the fragmented IPv6 datagram transmissions being aborted. 9.9. Downlink fragment transmission In some LPWAN technologies, as part of energy-saving techniques, downlink transmission is only possible immediately after an uplink transmission. In order to avoid potentially high delay for fragmented IPv6 datagram transmission in the downlink, the fragment receiver MAY perform an uplink transmission as soon as possible after reception of a fragment that is not the last one. Such uplink transmission may be triggered by the L2 (e.g. an L2 ACK sent in response to a fragment encapsulated in a L2 frame that requires an L2 ACK) or it may be triggered from an upper layer. 10. Security considerations 10.1. Security considerations for header compression A malicious header compression could cause the reconstruction of a wrong packet that does not match with the original one, such corruption may be detected with end-to-end authentication and integrity mechanisms. Denial of Service may be produced but its arise other security problems that may be solved with or without header compression. Minaburo, et al. Expires December 18, 2017 [Page 30] =0C Internet-Draft LPWAN SCHC June 2017 10.2. Security considerations for fragmentation This subsection describes potential attacks to LPWAN fragmentation and suggests possible countermeasures. A node can perform a buffer reservation attack by sending a first fragment to a target. Then, the receiver will reserve buffer space for the IPv6 packet. Other incoming fragmented packets will be dropped while the reassembly buffer is occupied during the reassembly timeout. Once that timeout expires, the attacker can repeat the same procedure, and iterate, thus creating a denial of service attack. The (low) cost to mount this attack is linear with the number of buffers at the target node. However, the cost for an attacker can be increased if individual fragments of multiple packets can be stored in the reassembly buffer. To further increase the attack cost, the reassembly buffer can be split into fragment-sized buffer slots. Once a packet is complete, it is processed normally. If buffer overload occurs, a receiver can discard packets based on the sender behavior, which may help identify which fragments have been sent by an attacker. In another type of attack, the malicious node is required to have overhearing capabilities. If an attacker can overhear a fragment, it can send a spoofed duplicate (e.g. with random payload) to the destination. A receiver cannot distinguish legitimate from spoofed fragments. Therefore, the original IPv6 packet will be considered corrupt and will be dropped. To protect resource-constrained nodes from this attack, it has been proposed to establish a binding among the fragments to be transmitted by a node, by applying content- chaining to the different fragments, based on cryptographic hash functionality. The aim of this technique is to allow a receiver to identify illegitimate fragments. Further attacks may involve sending overlapped fragments (i.e. comprising some overlapping parts of the original IPv6 datagram). Implementers should make sure that correct operation is not affected by such event. 11. Acknowledgements Thanks to Dominique Barthel, Carsten Bormann, Philippe Clavier, Arunprabhu Kandasamy, Antony Markovski, Alexander Pelov, Pascal Thubert, Juan Carlos Zuniga and Diego Dujovne for useful design consideration and comments. Minaburo, et al. Expires December 18, 2017 [Page 31] =0C Internet-Draft LPWAN SCHC June 2017 12. References 12.1. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, . [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, . 12.2. Informative References [I-D.ietf-lpwan-overview] Farrell, S., "LPWAN Overview", draft-ietf-lpwan- overview-04 (work in progress), June 2017. Appendix A. Fragmentation examples This section provides examples of different fragment delivery reliability options possible on the basis of this specification. Figure 15 illustrates the transmission of an IPv6 packet that needs 11 fragments in the No ACK option. Minaburo, et al. Expires December 18, 2017 [Page 32] =0C Internet-Draft LPWAN SCHC June 2017 Sender Receiver |-------CFN=3D0-------->| |-------CFN=3D0-------->| |-------CFN=3D0-------->| |-------CFN=3D0-------->| |-------CFN=3D0-------->| |-------CFN=3D0-------->| |-------CFN=3D0-------->| |-------CFN=3D0-------->| |-------CFN=3D0-------->| |-------CFN=3D0-------->| |-------CFN=3D1-------->|MIC checked =3D> Figure 15: Transmission of an IPv6 packet carried by 11 fragments in the No ACK option Figure 16 illustrates the transmission of an IPv6 packet that needs 11 fragments in Window mode - ACK on error, for N=3D3, without = losses. Sender Receiver |-----W=3D1, CFN=3D6----->| |-----W=3D1, CFN=3D5----->| |-----W=3D1, CFN=3D4----->| |-----W=3D1, CFN=3D3----->| |-----W=3D1, CFN=3D2----->| |-----W=3D1, CFN=3D1----->| |-----W=3D1, CFN=3D0----->| (no ACK) |-----W=3D0, CFN=3D6----->| |-----W=3D0, CFN=3D5----->| |-----W=3D0, CFN=3D4----->| |-----W=3D0, CFN=3D7----->|MIC checked =3D> (no ACK) Figure 16: Transmission of an IPv6 packet carried by 11 fragments in Window mode - ACK on error, for N=3D3, without losses. Figure 17 illustrates the transmission of an IPv6 packet that needs 11 fragments in Window mode - ACK on error, for N=3D3, with three losses. Minaburo, et al. Expires December 18, 2017 [Page 33] =0C Internet-Draft LPWAN SCHC June 2017 Sender Receiver |-----W=3D1, CFN=3D6----->| |-----W=3D1, CFN=3D5----->| |-----W=3D1, CFN=3D4--X-->| |-----W=3D1, CFN=3D3----->| |-----W=3D1, CFN=3D2--X-->| |-----W=3D1, CFN=3D1----->| |-----W=3D1, CFN=3D0----->| |<-----ACK, W=3D1-------|Bitmap:11010111 |-----W=3D1, CFN=3D4----->| |-----W=3D1, CFN=3D2----->| (no ACK) |-----W=3D0, CFN=3D6----->| |-----W=3D0, CFN=3D5----->| |-----W=3D0, CFN=3D4--X-->| |-----W=3D0, CFN=3D7----->|MIC checked |<-----ACK, W=3D0-------|Bitmap:11000001 |-----W=3D0, CFN=3D4----->|MIC checked =3D> (no ACK) Figure 17: Transmission of an IPv6 packet carried by 11 fragments in Window mode - ACK on error, for N=3D3, three losses. Figure 18 illustrates the transmission of an IPv6 packet that needs 11 fragments in Window mode - ACK "always", for N=3D3, without = losses. Note: in Window mode, an additional bit will be needed to number windows. Sender Receiver |-----W=3D1, CFN=3D6----->| |-----W=3D1, CFN=3D5----->| |-----W=3D1, CFN=3D4----->| |-----W=3D1, CFN=3D3----->| |-----W=3D1, CFN=3D2----->| |-----W=3D1, CFN=3D1----->| |-----W=3D1, CFN=3D0----->| |<-----ACK, W=3D1-------|no bitmap |-----W=3D0, CFN=3D6----->| |-----W=3D0, CFN=3D5----->| |-----W=3D0, CFN=3D4----->| |-----W=3D0, CFN=3D7----->|MIC checked =3D> |<-----ACK, W=3D0-------|no bitmap (End) Figure 18: Transmission of an IPv6 packet carried by 11 fragments in Window mode - ACK "always", for N=3D3, no losses. Minaburo, et al. Expires December 18, 2017 [Page 34] =0C Internet-Draft LPWAN SCHC June 2017 Figure 19 illustrates the transmission of an IPv6 packet that needs 11 fragments in Window mode - ACK "always", for N=3D3, with three losses. Sender Receiver |-----W=3D1, CFN=3D6----->| |-----W=3D1, CFN=3D5----->| |-----W=3D1, CFN=3D4--X-->| |-----W=3D1, CFN=3D3----->| |-----W=3D1, CFN=3D2--X-->| |-----W=3D1, CFN=3D1----->| |-----W=3D1, CFN=3D0----->| |<-----ACK, W=3D1-------|bitmap:11010111 |-----W=3D1, CFN=3D4----->| |-----W=3D1, CFN=3D2----->| |<-----ACK, W=3D1-------|no bitmap |-----W=3D0, CFN=3D6----->| |-----W=3D0, CFN=3D5----->| |-----W=3D0, CFN=3D4--X-->| |-----W=3D0, CFN=3D7----->|MIC checked |<-----ACK, W=3D0-------|bitmap:11000001 |-----W=3D0, CFN=3D4----->|MIC checked =3D> |<-----ACK, W=3D0-------|no bitmap (End) Figure 19: Transmission of an IPv6 packet carried by 11 fragments in Window mode - ACK "Always", for N=3D3, with three losses. Appendix B. Rule IDs for fragmentation Different Rule IDs may be used for different aspects of fragmentation functionality as per this document. A summary of such Rule IDs follows: o A fragment, and the reliability option in use for the IPv6 datagram being carried: i) No ACK, ii) Window mode - ACK on error, iii) Window mode - ACK "always". In Window mode, a specific Rule ID may be used for each supported window size. o An ACK message. o A message to abort all on-going transmissions. Minaburo, et al. Expires December 18, 2017 [Page 35] =0C Internet-Draft LPWAN SCHC June 2017 Appendix C. Note Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose Castillejo grant CAS15/00336, and by the ERDF and the Spanish Government through project TEC2016-79988-P. Part of his contribution to this work has been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge. Authors' Addresses Ana Minaburo Acklio 2bis rue de la Chataigneraie 35510 Cesson-Sevigne Cedex France Email: ana@ackl.io Laurent Toutain IMT-Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@imt-atlantique.fr Carles Gomez Universitat Politecnica de Catalunya C/Esteve Terradas, 7 08860 Castelldefels Spain Email: carlesgo@entel.upc.edu Minaburo, et al. Expires December 18, 2017 [Page 36] --Apple-Mail=_3E5D47C9-4B01-4661-9F00-BA35652A0EF1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_3E5D47C9-4B01-4661-9F00-BA35652A0EF1-- From nobody Fri Jun 16 16:59:50 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B157129540; Fri, 16 Jun 2017 16:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 dr7x46jyR3Xh; Fri, 16 Jun 2017 16:59:22 -0700 (PDT) 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 058C0129536; Fri, 16 Jun 2017 16:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v5GNxHRg007568; Sat, 17 Jun 2017 01:59:17 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wqHQs5BtpzDK05; Sat, 17 Jun 2017 01:59:17 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 519350357.381063-6f048f755c1bea58baaf44d0990e4c50 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 17 Jun 2017 01:59:17 +0200 Message-Id: To: lo <6lo@ietf.org>, 6TiSCH mailing list <6tisch@ietf.org>, lp-wan , lwip@ietf.org, Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Constrained Node/Network Cluster @ IETF99: DRAFT AGENDA X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 23:59:24 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF99. Remember that there is still quite some potential for changes. ACE people are going to miss DISPATCH (ARTAREA) again -- not sure if there would have been be any discussions relevant to Constrained Nodes/Networks in ARTAREA, but it doesn't make sense with this scheduling. CORE people will miss both ANIMA and (in-week) ICNRG. ROLL people will miss SAAG, ouch. And LPWAN is on the second half of QUIC. All no disasters, AFAICS, but not pain-free. All times are CEST (UTC+0200). (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 SATURDAY/SUNDAY -- T2TRG -- ICNRG -- Hackathon (including various interops) MONDAY, July 17, 2017 0930-1200 Morning Session I Congress H III ART dispatch Dispatch WG - 09:30-11:30 Grand Hilton BR INT 6man IPv6 Maintenance WG Congress H I SEC *** ace Authentication and Authorization for = Constrained Environments WG Congress H III SEC curdle CURves, Deprecating and a Little more = Encryption WG - 11:30-12:00 1330-1530 Afternoon Session I Karlin I/II INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Grand Hilton BR INT homenet Home Networking WG 1550-1720 Afternoon Session II Karlin I/II ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Berlin/Brussels SEC tokbind Token Binding WG 1740-1840 Afternoon Session III Athens/Barcel. RTG babel Babel routing protocol WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting TUESDAY, July 18, 2017 0930-1200 Morning Session I Congress H II OPS v6ops IPv6 Operations WG Congress H I TSV taps Transport Services WG 1330-1530 Afternoon Session I Grand Hilton BR IRTF*** t2trg Thing-to-Thing Berlin/Brussels SEC oauth Web Authorization Protocol WG Congress H I TSV tsvwg Transport Area Working Group WG 1550-1750 Afternoon Session II Karlin I/II INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Congress H I IRTF cfrg Crypto Forum WEDNESDAY, July 19, 2017 0930-1200 Morning Session I Congress H I ART *** core Constrained RESTful Environments WG Karlin I/II IRTF icnrg Information-Centric Networking Congress H III OPS anima Autonomic Networking Integrated Model = and Approach WG Congress H II RTG rtgarea Routing Area Open Meeting Grand Hilton BR SEC tls Transport Layer Security WG Karlin III TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1330-1500 Afternoon Session I Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG Congress H III IRTF panrg Proposed Path Aware Networking Congress H II RTG ideas IDentity Enabled Networks BOF 1520-1650 Afternoon Session II Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG THURSDAY, July 20, 2017 0930-1200 Morning Session I Grand Hilton BR INT intarea Internet Area Working Group WG Congress H II IRTF maprg Measurement and Analysis for Protocols Congress H I RTG detnet Deterministic Networking WG 1330-1530 Afternoon Session I Berlin/Brussels ART ice Interactive Connectivity Establishment = WG Grand Hilton BR OPS v6ops IPv6 Operations WG Karlin I/II RTG *** roll Routing Over Low power and Lossy = networks WG Congress H III SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Athens/Barcel. INT ipwave IP Wireless Access in Vehicular = Environments WG Grand Hilton BR TSV quic QUIC WG 1810-1910 Afternoon Session III Berlin/Brussels ART uta Using TLS in Applications WG Athens/Barcel. INT *** lwig Light-Weight Implementation Guidance WG Karlin I/II RTG bier Bit Indexed Explicit Replication WG Congress H III TSV tsvwg Transport Area Working Group WG FRIDAY, July 21, 2017 0930-1130 Morning Session I Berlin/Brussels INT dnssd Extensions for Scalable DNS Service = Discovery WG Karlin I/II INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Karlin III SEC oauth Web Authorization Protocol WG Grand Hilton BR TSV quic QUIC WG 1150-1320 Afternoon Session II Congress H III ART *** core Constrained RESTful Environments WG Grand Hilton BR SEC acme Automated Certificate Management = Environment WG From nobody Mon Jun 19 02:24:09 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7A129449 for ; Mon, 19 Jun 2017 02:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 vzKrObaBtKro for ; Mon, 19 Jun 2017 02:24:05 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E8F129455 for ; Mon, 19 Jun 2017 02:23:56 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:b078:5d8d:2066:8cda] (unknown [IPv6:2001:660:7301:3728:b078:5d8d:2066:8cda]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 9736A1720A3 for ; Mon, 19 Jun 2017 11:23:54 +0200 (CEST) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 19 Jun 2017 11:23:53 +0200 References: To: lp-wan In-Reply-To: Message-Id: <10E1D5F6-CA58-481B-B6EB-C63A32F28342@ackl.io> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Correction: Agenda for LPWAN interim meeting next Wednesday, June 21th, 16h-17h CEST (7-8am US Pacific) X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 09:24:08 -0000 Dear all, In the previous announcement, the subject was pointing out June 26th as = meeting date. This is of course not correct. The meeting is taking place = on June 21st as announced on the Datatracker and as traditionally - on = Wednesday. Thanks to Carles for pointing it out. Best, The Chairs > Le 14 juin 2017 =C3=A0 21:16, Alexander Pelov a =C3=A9crit = : >=20 > Dear all, >=20 > You=E2=80=99ll find the updated agenda at the following address: = https://datatracker.ietf.org/doc/agenda-interim-2017-lpwan-05-lpwan-01/ >=20 > We=E2=80=99ll have an update on the last elements of IP/UDP before = WGLC, as well as the progression of the LPWAN Overview document. >=20 > We=E2=80=99ll also discuss more in length the future work items we = should consider. >=20 > Best, > The chairs > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan From nobody Mon Jun 19 03:38:40 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0682812953F for ; Mon, 19 Jun 2017 03:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 zqHrzLWHBzSj for ; Mon, 19 Jun 2017 03:38:38 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229B412954C for ; Mon, 19 Jun 2017 03:38:22 -0700 (PDT) Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id A8FC5FB8C7; Mon, 19 Jun 2017 12:38:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id y-YHQiGX2xqW; Mon, 19 Jun 2017 12:38:19 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.157] (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: arun@acklio.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 51C59FB8CF; Mon, 19 Jun 2017 12:38:18 +0200 (CEST) From: Arun To: lp-wan Cc: Ana Minaburo , Carles Gomez Montenegro , Laurent Toutain Message-ID: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> Date: Mon, 19 Jun 2017 12:38:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TD9vQpWNNded7GnhgwrgCXvitOVhj4Okc" Archived-At: Subject: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 10:38:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TD9vQpWNNded7GnhgwrgCXvitOVhj4Okc Content-Type: multipart/mixed; boundary="STo8oslfI3qnlcgOaQsVtUvc8q1J8WpM6"; protected-headers="v1" From: Arun To: lp-wan Cc: Ana Minaburo , Carles Gomez Montenegro , Laurent Toutain Message-ID: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> Subject: re-order header field request --STo8oslfI3qnlcgOaQsVtUvc8q1J8WpM6 Content-Type: multipart/alternative; boundary="------------90E3888D5A8C6280F7D86C41" Content-Language: en-US This is a multi-part message in MIME format. --------------90E3888D5A8C6280F7D86C41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Absence of window bit in the last fragment of the packet makes it tricky to unmarshall the header at the receiver. As I see it, the receiver up front shall know the length of the CFN field depending on the Window size configured but doesn't know to anticipate the last fragment unless indicated by CFN. So I think, we need to maintain same order on all fragment headers. existing; <------------ R ----------> <--T--> 1 <--N--> +-- ... --+- ... -+-+- ... -+ | Rule ID | DTag |W| CFN | +-- ... --+- ... -+-+- ... -+ shall be; <------------ R ----------> <--T--> <--N--> 1 +-- ... --+- ... -+- ... -+-+ | Rule ID | DTag | CFN |W| +-- ... --+- ... -+- ... -+-+ and for the last fragment <------------ R ----------> <--T--> <--N-->=20 +-- ... --+- ... -+- ... -+-+ | Rule ID | DTag | CFN |MIC +-- ... --+- ... -+- ... -+-+ what do you think? thanks, Arun --------------90E3888D5A8C6280F7D86C41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,
Absence of window bit in the last fragment of the packet makes it tricky to unmarshall the header at the receiver.
As I see it, the receiver up front shall know the length of the CFN field depending on the Window size configured but doesn't know to anticipate the last fragment unless indicated by CFN.
So I think,=C2=A0 we need to maintain same order on all fragment headers.

existing;
      		<------------ R ---------->
                          <--T--> 1 <--N-->
               +-- ... --+- ... -+-+- ... -+
               | Rule ID | DTag  |W|  CFN  |
               +-- ... --+- ... -+-+- ... -+

shall be;
     		<------------ R ---------->
                          <--T--> <--N--> 1
               +-- ... --+- ... -+- ... -+-+
               | Rule ID | DTag  |  CFN  |W|
               +-- ... --+- ... -+- ... -+-+

and for the last fragment
   		<------------ R ---------->
                          <--T--> <--N-->=20
               +-- ... --+- ... -+- ... -+-+
               | Rule ID | DTag  |  CFN  |MIC
               +-- ... --+- ... -+- ... -+-+


what do you think?


thanks,
Arun
--------------90E3888D5A8C6280F7D86C41-- --STo8oslfI3qnlcgOaQsVtUvc8q1J8WpM6-- --TD9vQpWNNded7GnhgwrgCXvitOVhj4Okc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZR6mXAAoJENe8HNMjzJQR2ZYP/AxgyJ5iQ0IkvtNK0fCbGmeC WV4o75QAByzAVd1secaZX4go/YETcB0nUJas5XA/UtaiHkSJq5UNzsaisxk1VdYg vGCU6aOPNR5ycQYdcDBM+4yG7cdV680lKLLHyqznMYqD7OYFtncmYZ2fhKGKgT/f 1EsFns083qa26yZQw3r4a8fU9oH4Cz6RDKekZ79JdoLm6a+D7srQrWLT2rkRY3Xw KJnSWC1k0MoIRHVpMVkv0gWGuo8umvEC6CIm/YmFUW4SE4ufry6vZUMmG6DcdEow o9wOTJ1YI5pTOlekXz+m9MCGXHq4FWxSUxklfIxJxiHIfh1ktIaZ4YHS20T079wP rqlch6BMb0sg1t9/W+hXrgboTk3s7A2Xpozhdy6DBCk5I9slVuDZJxqJQObGWFlc OjTigtlTNORO8p7lkTFEFWp8FCVRBb/3t1H83UwxpYtJtum5Zcd0L836c5BL0mRj C5Wv4uhGD5JBM94ey3VsztVtQhpZBp6olsYCWCpf7/1YiFvtDYq0MS2sJPr8OhoB AhrMdRiYUs4zGJWWu3fgZSlrHm5DXRGXAapPSOfTTWX3NQ008q/+jkcwiyNwNo/G 10kWsv1RUn7iObsARSPsP9Fwji+9JGnNX78K7zIKpN9UBFCEBmlRE/Hs68N4nZFV a+QNAobFPfL/88XaZAjV =QCqh -----END PGP SIGNATURE----- --TD9vQpWNNded7GnhgwrgCXvitOVhj4Okc-- From nobody Mon Jun 19 12:29:13 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B001316F6 for ; Mon, 19 Jun 2017 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 3j3xoI9-bYNa for ; Mon, 19 Jun 2017 12:29:09 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C1A131801 for ; Mon, 19 Jun 2017 12:29:09 -0700 (PDT) Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id D0C37A80F1 for ; Mon, 19 Jun 2017 21:29:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Df1ERYcWnS4d for ; Mon, 19 Jun 2017 21:29:06 +0200 (CEST) X-Originating-IP: 10.58.1.148 Received: from webmail.gandi.net (webmail8-d.mgt.gandi.net [10.58.1.148]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPA id 0C2B1A80DB for ; Mon, 19 Jun 2017 21:29:05 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 19 Jun 2017 21:29:05 +0200 From: Alexander Pelov To: lp-wan@ietf.org Message-ID: X-Sender: a@ackl.io User-Agent: Roundcube Webmail/1.1.2 Archived-At: Subject: [lp-wan] WGLC on LPWAN Overview draft X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 19:29:12 -0000 Dear all, As discussed during the last interim, we are starting a WGLC on the LPWAN Overview document: https://tools.ietf.org/html/draft-ietf-lpwan-overview-04 There should be no issues with the document at this stage, but please, DO review the document now and DO provide your comments and remarks if you see any issues. The WGCL will end in two weeks, on July 3rd, 2017, 23h55 CEST. Best, Pascal and Alexander From nobody Tue Jun 20 09:02:59 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98344131510 for ; Tue, 20 Jun 2017 09:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Fk188GYJVjpl for ; Tue, 20 Jun 2017 09:02:55 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 05F0E131AAE for ; Tue, 20 Jun 2017 09:02:00 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5KG1wKY037356; Tue, 20 Jun 2017 18:01:58 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 22D8D1D53C1; Tue, 20 Jun 2017 18:01:57 +0200 (CEST) Received: from 83.55.156.17 by webmail.entel.upc.edu with HTTP; Tue, 20 Jun 2017 18:01:27 +0200 Message-ID: In-Reply-To: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> Date: Tue, 20 Jun 2017 18:01:27 +0200 From: "Carles Gomez Montenegro" To: "Arun" Cc: "lp-wan" , "Ana Minaburo" , "Laurent Toutain" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Tue, 20 Jun 2017 18:01:58 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 16:02:59 -0000 Hi Arun, Thanks for pointing this out. Your proposal seems fine to me, except for the (possibly minor) detail that in your proposal "R" would comprise a number of header fields for the last fragment that would be different from the number of fields in previous fragments. Maybe we could also consider another solution: adding the W bit in the header of the last fragment of the packet. I haven't found examples of scenarios where the W bit is actually needed in the last fragment (i.e. fragment with "all ones" CFN). However, I'm wondering if there is an actual benefit or a related use case that may require *not* having a W bit in the last fragment header. (If anyone has any in mind, please chime in!) On the other hand, if we have the W bit also in the last fragment header, header format will be more uniform across all fragments. Thoughts? Cheers, Carles > Hi all, > Absence of window bit in the last fragment of the packet makes it tricky > to unmarshall the header at the receiver. > As I see it, the receiver up front shall know the length of the CFN > field depending on the Window size configured but doesn't know to > anticipate the last fragment unless indicated by CFN. > So I think, we need to maintain same order on all fragment headers. > > existing; > > <------------ R ----------> > <--T--> 1 <--N--> > +-- ... --+- ... -+-+- ... -+ > | Rule ID | DTag |W| CFN | > +-- ... --+- ... -+-+- ... -+ > > shall be; > <------------ R ----------> > <--T--> <--N--> 1 > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |W| > +-- ... --+- ... -+- ... -+-+ > > and for the last fragment > <------------ R ----------> > <--T--> <--N--> > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |MIC > +-- ... --+- ... -+- ... -+-+ > > > what do you think? > > > thanks, > Arun > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > From nobody Tue Jun 20 19:01:18 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508BC1296C9 for ; Tue, 20 Jun 2017 19:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, 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 sQTZ3CLzCuww for ; Tue, 20 Jun 2017 19:01:13 -0700 (PDT) Received: from smtp-6-47.vip.sina.com.cn (r3-67.sinamail.sina.com.cn [202.108.3.67]) by ietfa.amsl.com (Postfix) with SMTP id B22DF127B60 for ; Tue, 20 Jun 2017 19:01:11 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.255.40.41]) by vip.sina.com with ESMTP 21 Jun 2017 10:01:04 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 502201278561 Message-ID: <331F64BD15B741A986014F6C1AA51C75@WeiGengyuPC> From: "weigengyu" To: "Carles Gomez Montenegro" , "Arun" Cc: "lp-wan" , "Laurent Toutain" , "Ana Minaburo" References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> In-Reply-To: Date: Wed, 21 Jun 2017 10:01:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 02:01:16 -0000 Hi, There is a question about Format in draft-ietf-lpwan-ipv6-static-context-hc-04. > So I think, we need to maintain same order on all fragment headers. > existing; > <------------ R ----------> > <--T--> 1 <--N--> > +-- ... --+- ... -+-+- ... -+ > | Rule ID | DTag |W| CFN | > +-- ... --+- ... -+-+- ... -+ > > shall be; > <------------ R ----------> > <--T--> <--N--> 1 > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |W| > +-- ... --+- ... -+- ... -+-+ > > and for the last fragment > <------------ R ----------> > <--T--> <--N--> > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |MIC > +-- ... --+- ... -+- ... -+-+ > > what do you think? > Why each successive fragment must contain a Rule ID? It is known that the DTag is used as an indication of fragments belonged to the same IPv6 packet. A Rule ID in the first fragement can be passed to the receiver how to do HC compression, but the successive fragments containing a Rule ID just send a redundent information to the receiver. Right? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carles Gomez Montenegro Sent: Wednesday, June 21, 2017 12:01 AM To: Arun Cc: lp-wan ; Laurent Toutain ; Ana Minaburo Subject: Re: [lp-wan] re-order header field request Hi Arun, Thanks for pointing this out. Your proposal seems fine to me, except for the (possibly minor) detail that in your proposal "R" would comprise a number of header fields for the last fragment that would be different from the number of fields in previous fragments. Maybe we could also consider another solution: adding the W bit in the header of the last fragment of the packet. I haven't found examples of scenarios where the W bit is actually needed in the last fragment (i.e. fragment with "all ones" CFN). However, I'm wondering if there is an actual benefit or a related use case that may require *not* having a W bit in the last fragment header. (If anyone has any in mind, please chime in!) On the other hand, if we have the W bit also in the last fragment header, header format will be more uniform across all fragments. Thoughts? Cheers, Carles > Hi all, > Absence of window bit in the last fragment of the packet makes it tricky > to unmarshall the header at the receiver. > As I see it, the receiver up front shall know the length of the CFN > field depending on the Window size configured but doesn't know to > anticipate the last fragment unless indicated by CFN. > So I think, we need to maintain same order on all fragment headers. > > existing; > > <------------ R ----------> > <--T--> 1 <--N--> > +-- ... --+- ... -+-+- ... -+ > | Rule ID | DTag |W| CFN | > +-- ... --+- ... -+-+- ... -+ > > shall be; > <------------ R ----------> > <--T--> <--N--> 1 > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |W| > +-- ... --+- ... -+- ... -+-+ > > and for the last fragment > <------------ R ----------> > <--T--> <--N--> > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |MIC > +-- ... --+- ... -+- ... -+-+ > > > what do you think? > > > thanks, > Arun > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Tue Jun 20 19:45:20 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD01293E3 for ; Tue, 20 Jun 2017 19:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1Ldu3dOQHrrr for ; Tue, 20 Jun 2017 19:45:13 -0700 (PDT) Received: from smtp-6-47.vip.sina.com.cn (r3-68.sinamail.sina.com.cn [202.108.3.68]) by ietfa.amsl.com (Postfix) with SMTP id 8744C126B6E for ; Tue, 20 Jun 2017 19:45:12 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.255.40.41]) by vip.sina.com with ESMTP 21 Jun 2017 10:45:06 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 621395278649 Message-ID: From: "weigengyu" To: Date: Wed, 21 Jun 2017 10:45:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 02:45:17 -0000 Hi, There is a question about Format in draft-ietf-lpwan-ipv6-static-context-hc-04. > So I think, we need to maintain same order on all fragment headers. > existing; > <------------ R ----------> > <--T--> 1 <--N--> > +-- ... --+- ... -+-+- ... -+ > | Rule ID | DTag |W| CFN | > +-- ... --+- ... -+-+- ... -+ > > shall be; > <------------ R ----------> > <--T--> <--N--> 1 > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |W| > +-- ... --+- ... -+- ... -+-+ > > and for the last fragment > <------------ R ----------> > <--T--> <--N--> > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |MIC > +-- ... --+- ... -+- ... -+-+ > > what do you think? > Why each successive fragment must contain a Rule ID? It is known that the DTag is used as an indication of fragments belonged to the same IPv6 packet. A Rule ID in the first fragement can be passed to the receiver how to do HC compression, but the successive fragments containing a Rule ID just send a redundent information to the receiver. Right? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carles Gomez Montenegro Sent: Wednesday, June 21, 2017 12:01 AM To: Arun Cc: lp-wan ; Laurent Toutain ; Ana Minaburo Subject: Re: [lp-wan] re-order header field request Hi Arun, Thanks for pointing this out. Your proposal seems fine to me, except for the (possibly minor) detail that in your proposal "R" would comprise a number of header fields for the last fragment that would be different from the number of fields in previous fragments. Maybe we could also consider another solution: adding the W bit in the header of the last fragment of the packet. I haven't found examples of scenarios where the W bit is actually needed in the last fragment (i.e. fragment with "all ones" CFN). However, I'm wondering if there is an actual benefit or a related use case that may require *not* having a W bit in the last fragment header. (If anyone has any in mind, please chime in!) On the other hand, if we have the W bit also in the last fragment header, header format will be more uniform across all fragments. Thoughts? Cheers, Carles > Hi all, > Absence of window bit in the last fragment of the packet makes it tricky > to unmarshall the header at the receiver. > As I see it, the receiver up front shall know the length of the CFN > field depending on the Window size configured but doesn't know to > anticipate the last fragment unless indicated by CFN. > So I think, we need to maintain same order on all fragment headers. > > existing; > > <------------ R ----------> > <--T--> 1 <--N--> > +-- ... --+- ... -+-+- ... -+ > | Rule ID | DTag |W| CFN | > +-- ... --+- ... -+-+- ... -+ > > shall be; > <------------ R ----------> > <--T--> <--N--> 1 > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |W| > +-- ... --+- ... -+- ... -+-+ > > and for the last fragment > <------------ R ----------> > <--T--> <--N--> > +-- ... --+- ... -+- ... -+-+ > | Rule ID | DTag | CFN |MIC > +-- ... --+- ... -+- ... -+-+ > > > what do you think? > > > thanks, > Arun > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Tue Jun 20 23:13:52 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136DB127843 for ; Tue, 20 Jun 2017 23:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 sb7D3w8PW8hW for ; Tue, 20 Jun 2017 23:13:48 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 82A5E1315DE for ; Tue, 20 Jun 2017 23:13:46 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5L6DfCo044427; Wed, 21 Jun 2017 08:13:41 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D735E1D53C1; Wed, 21 Jun 2017 08:13:40 +0200 (CEST) Received: from 83.55.156.17 by webmail.entel.upc.edu with HTTP; Wed, 21 Jun 2017 08:13:11 +0200 Message-ID: In-Reply-To: <331F64BD15B741A986014F6C1AA51C75@WeiGengyuPC> References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> <331F64BD15B741A986014F6C1AA51C75@WeiGengyuPC> Date: Wed, 21 Jun 2017 08:13:11 +0200 From: "Carles Gomez Montenegro" To: "weigengyu" Cc: "Arun" , "lp-wan" , "Laurent Toutain" , "Ana Minaburo" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: Delayed for 14:11:43 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 21 Jun 2017 08:13:42 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 06:13:51 -0000 Hi Gengyu, > Why each successive fragment must contain a Rule ID? > It is known that the DTag is used as an indication of fragments belonged > to > the same IPv6 packet. > A Rule ID in the first fragement can be passed to the receiver how to do > HC > compression, > but the successive fragments containing a Rule ID just send a redundent > information to the receiver. > Right? The Rule ID is needed to provide a receiver with information on what type of content is being carried (and how it has to be handled). Note that not all IPv6 packets will require fragmentation, and then losses may happen, also non-fragmented packets may be interleaved with fragments, etc. Cheers, Carles > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications From nobody Wed Jun 21 00:48:30 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBDA131787 for ; Wed, 21 Jun 2017 00:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 gvAr5SbzoGzp for ; Wed, 21 Jun 2017 00:48:25 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECF41317A5 for ; Wed, 21 Jun 2017 00:47:29 -0700 (PDT) Received: from mfilter6-d.gandi.net (mfilter6-d.gandi.net [217.70.178.135]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 86E321720D1 for ; Wed, 21 Jun 2017 09:47:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter6-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter6-d.gandi.net (mfilter6-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id IRLWcpM0KpOz for ; Wed, 21 Jun 2017 09:47:26 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.157] (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: arun@acklio.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id C6F9C17210C for ; Wed, 21 Jun 2017 09:47:26 +0200 (CEST) To: lp-wan@ietf.org References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> From: Arun Message-ID: Date: Wed, 21 Jun 2017 09:47:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1GqOJGR13VxFSRBXOHbfW0eE35PNtTliC" Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 07:48:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1GqOJGR13VxFSRBXOHbfW0eE35PNtTliC Content-Type: multipart/mixed; boundary="FJT7NtKDqnFOdgC5r3eioHCHOkklQGlKV"; protected-headers="v1" From: Arun To: lp-wan@ietf.org Message-ID: Subject: Re: [lp-wan] re-order header field request References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> In-Reply-To: --FJT7NtKDqnFOdgC5r3eioHCHOkklQGlKV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Carles, Having the uniform header format seems to be an ideal solution but Tx'ing additional bit without any significance seems contentious. Will wait for more feedbacks or comments :) thanks, Arun On 20/06/2017 18:01, Carles Gomez Montenegro wrote: > Hi Arun, > > Thanks for pointing this out. > > Your proposal seems fine to me, except for the (possibly minor) detail > that in your proposal "R" would comprise a number of header fields for = the > last fragment that would be different from the number of fields in > previous fragments. > > Maybe we could also consider another solution: adding the W bit in the > header of the last fragment of the packet. > > I haven't found examples of scenarios where the W bit is actually neede= d > in the last fragment (i.e. fragment with "all ones" CFN). However, I'm > wondering if there is an actual benefit or a related use case that may > require *not* having a W bit in the last fragment header. (If anyone ha= s > any in mind, please chime in!) > > On the other hand, if we have the W bit also in the last fragment heade= r, > header format will be more uniform across all fragments. > > Thoughts? > > Cheers, > > Carles > > > > >> Hi all, >> Absence of window bit in the last fragment of the packet makes it tric= ky >> to unmarshall the header at the receiver. >> As I see it, the receiver up front shall know the length of the CFN >> field depending on the Window size configured but doesn't know to >> anticipate the last fragment unless indicated by CFN. >> So I think, we need to maintain same order on all fragment headers. >> >> existing; >> >> <------------ R ----------> >> <--T--> 1 <--N--> >> +-- ... --+- ... -+-+- ... -+ >> | Rule ID | DTag |W| CFN | >> +-- ... --+- ... -+-+- ... -+ >> >> shall be; >> <------------ R ----------> >> <--T--> <--N--> 1 >> +-- ... --+- ... -+- ... -+-+ >> | Rule ID | DTag | CFN |W| >> +-- ... --+- ... -+- ... -+-+ >> >> and for the last fragment >> <------------ R ----------> >> <--T--> <--N--> >> +-- ... --+- ... -+- ... -+-+ >> | Rule ID | DTag | CFN |MIC >> +-- ... --+- ... -+- ... -+-+ >> >> >> what do you think? >> >> >> thanks, >> Arun >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >> > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --FJT7NtKDqnFOdgC5r3eioHCHOkklQGlKV-- --1GqOJGR13VxFSRBXOHbfW0eE35PNtTliC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZSiSLAAoJENe8HNMjzJQRt1UQAI9cBdxvwbv1vuvA4UHM3Mj3 HrC/sJkN5c5M3DcGj4PfNdvycgG+VTyas8y43d/ZJSyM12VMQqkeVW82N6ccVg1I xAgHtvB1TuRDwsB94oFvvTDBtSwEb4Axwm28gfLBkiQUb7XfLJ/4UTulAAD2sKb9 n2YryDvwZARGNMlg3Mj5XzwON5lQOmNLXrR37MTShaCSmS9rV8N7npeTeWbw57Lf Drs9+pWQGsBn8qJMMms6mm+S2clT0sde3E0xeuvVslo64w9s+tkWLa6EvWDBfvm7 kFxYdvxOZXf2/52rBXQBfd0VLRBX+oZyLEX4Hs/ILpdgxosptFNa1EvL2Fxpo3rc o2B7CShekPOmk1dRt2xGp99sJJpzcsQaejz9TNt7l80aAdmg9mbugvw0Mbb60Qm3 UXJ/wVIQpu5c4OVna56rO7/KQpbCI9R1iuac1QsxsY6MtLuEVRvrCBzwOC0EjUI7 EdMhKT0VVffRkqBoP9CNntoj+i98unx8D3JEhG/3CgM/JYNb+pe4oGLZ17sRYiWE s28XSm2Hfm0u2XeULNzyvw7E1aebQhG7jSC837p15+9Lp2YcTJWxB3+p8whX1eto 2hCV5B6gyB44r4tgUzxvmbt0JdUdp1k8H0dNHg9fa1DcpcfUhvK9rXK8a8v+AmSe jL/cHFP9iAmN2DL2sheN =Sd5E -----END PGP SIGNATURE----- --1GqOJGR13VxFSRBXOHbfW0eE35PNtTliC-- From nobody Wed Jun 21 01:02:54 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7B1317ED for ; Wed, 21 Jun 2017 01:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 NS-rMxCJChaM for ; Wed, 21 Jun 2017 01:02:50 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 55F901317DF for ; Wed, 21 Jun 2017 01:02:50 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5L82liG042813; Wed, 21 Jun 2017 10:02:47 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 850AC1D53C1; Wed, 21 Jun 2017 10:02:46 +0200 (CEST) Received: from 83.55.156.17 by webmail.entel.upc.edu with HTTP; Wed, 21 Jun 2017 10:02:17 +0200 Message-ID: <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> Date: Wed, 21 Jun 2017 10:02:17 +0200 From: "Carles Gomez Montenegro" To: "Arun" Cc: lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 21 Jun 2017 10:02:47 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 08:02:52 -0000 Hi Arun, The point here is that the Rule ID field in fragments except the last one will not use the W bit (or equivalently, have one bit less than the Rule ID field in the last fragment as per current formats). So I'm wondering if this "additional bit" in the Rule ID of the last fragment could have any useful purpose or not, or conversely would just complicate the structure and uniformity of fragmentation headers. Thoughts? Cheers, Carles > Hi Carles, > > Having the uniform header format seems to be an ideal solution but > Tx'ing additional bit without any significance seems contentious. > Will wait for more feedbacks or comments :) > > thanks, > Arun From nobody Wed Jun 21 01:10:01 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC41131811 for ; Wed, 21 Jun 2017 01:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 sEMhul_Pyl7C for ; Wed, 21 Jun 2017 01:09:57 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [IPv6:2001:660:330f:2::c1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0F513180F for ; Wed, 21 Jun 2017 01:09:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 57703100446 for ; Wed, 21 Jun 2017 10:09:55 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id Uuvi49M_2Zt6 for ; Wed, 21 Jun 2017 10:09:54 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id E8B161004A2 for ; Wed, 21 Jun 2017 10:09:53 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy120.enst.fr E8B161004A2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1498032593; bh=sO2BW64xsqKFagJdtCInXsNbYlT/yYoPntFggX1BzKo=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=jJ69jpVaWdT2p/Uc4rhJEwPH4jvurk9geVk5U/bbtSZv5foOGyGTel1MQvFC59wJJ xNdq5UvPU5jVS9/+wfQPqP+BvXfk3N4xjgDZDeefqX0OXiUBQWHNKSwQlWf/JpDCiC MJ0KxCQnvibVdCnY36VHtufGK5yBEcWp/Cosq9fA= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id STtlzKF4pUh5 for ; Wed, 21 Jun 2017 10:09:53 +0200 (CEST) Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 98FF3100446 for ; Wed, 21 Jun 2017 10:09:53 +0200 (CEST) Received: by mail-ua0-f169.google.com with SMTP id j53so90621389uaa.2 for ; Wed, 21 Jun 2017 01:09:53 -0700 (PDT) X-Gm-Message-State: AKS2vOySAc2Ia1Dz+kEjwTFG9O6PUwPSuM6PnMZ+1HKlTyFKBIxvJam/ BSo/2Lamksz0RV2SBmCCkfojZwYSkw== X-Received: by 10.176.91.71 with SMTP id v7mr23076268uae.138.1498032592444; Wed, 21 Jun 2017 01:09:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.61.94 with HTTP; Wed, 21 Jun 2017 01:09:12 -0700 (PDT) In-Reply-To: <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu> References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu> From: Laurent Toutain Date: Wed, 21 Jun 2017 10:09:12 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Carles Gomez Montenegro Cc: Arun , lp-wan Content-Type: multipart/alternative; boundary="f403045f8cda88f30b055273e481" Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 08:10:00 -0000 --f403045f8cda88f30b055273e481 Content-Type: text/plain; charset="UTF-8" Hi, I don't think it is a problem to keep it, in a All 1 Frag, even if we don't use it (MIC is out of window numbering). we have alignment on bytes when we send a message, so the benefit is not obvious if we don't keep it. But in ACK message the W bit must be present. Laurent On Wed, Jun 21, 2017 at 10:02 AM, Carles Gomez Montenegro < carlesgo@entel.upc.edu> wrote: > Hi Arun, > > The point here is that the Rule ID field in fragments except the last one > will not use the W bit (or equivalently, have one bit less than the Rule > ID field in the last fragment as per current formats). > > So I'm wondering if this "additional bit" in the Rule ID of the last > fragment could have any useful purpose or not, or conversely would just > complicate the structure and uniformity of fragmentation headers. > > Thoughts? > > Cheers, > > Carles > > > > > Hi Carles, > > > > Having the uniform header format seems to be an ideal solution but > > Tx'ing additional bit without any significance seems contentious. > > Will wait for more feedbacks or comments :) > > > > thanks, > > Arun > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > --f403045f8cda88f30b055273e481 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I don't think it is a problem to= keep it, in a All 1 Frag, even if we don't use it (MIC is out of windo= w numbering).=C2=A0 we have alignment on bytes when we send a message, so t= he benefit is not obvious if we don't keep it.

But in=C2= =A0 ACK message the W bit must be present.

Laurent

On Wed, Jun 21, 201= 7 at 10:02 AM, Carles Gomez Montenegro <carlesgo@entel.upc.edu>= ; wrote:
Hi Arun,

The point here is that the Rule ID field in fragments except the last one will not use the W bit (or equivalently, have one bit less than the Rule ID field in the last fragment as per current formats).

So I'm wondering if this "additional bit" in the Rule ID of t= he last
fragment could have any useful purpose or not, or conversely would just
complicate the structure and uniformity of fragmentation headers.

Thoughts?

Cheers,

Carles



> Hi Carles,
>
>=C2=A0 Having the uniform header format seems to be an ideal solution b= ut
> Tx'ing additional bit without any significance seems contentious.<= br> > Will wait for more feedbacks or comments :)
>
> thanks,
> Arun


____________________________= ___________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

--f403045f8cda88f30b055273e481-- From nobody Wed Jun 21 01:40:35 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10291317EF for ; Wed, 21 Jun 2017 01:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WZIaSuEXpLd for ; Wed, 21 Jun 2017 01:40:31 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-oln040092009106.outbound.protection.outlook.com [40.92.9.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4441200FC for ; Wed, 21 Jun 2017 01:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l5Uh0OKO06NXSHJomZ52iWj0HuVwY0M1Vfay0JaY17Q=; b=cMaPpRQQMCGCWtcNOkl+eKygY7bjUfS7fmuIjchH+10L1KxLiyyVwOYZ+u1sG2KgJe4koj211NSy/cdMcytGbO7eTvW8Bx433C+RwI/eI9UWjpW5vYyaZi8kO46U0TWu5ROCT69TXtUxo8qAOL6V3D8K5WW3HZR/qyVxMnFdKis16lwk/8QovDEfXkgmmo1fTVWh0G5kxjrPyKf3uHxRcGISlBsMPYwNDDqISALas1yHa5/f1thu2DhWgTXJgU6J0dQ+X1lNR3hPqIHqqyC+yVXButZNKD6rcyq7nc9AR3viTKfM6VQo3OGH9qpVhonR7H/FddzrjqY9dliNPPYW+Q== Received: from SN1NAM04FT019.eop-NAM04.prod.protection.outlook.com (10.152.88.53) by SN1NAM04HT085.eop-NAM04.prod.protection.outlook.com (10.152.88.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1178.14; Wed, 21 Jun 2017 08:40:04 +0000 Received: from BN6PR12MB1524.namprd12.prod.outlook.com (10.152.88.55) by SN1NAM04FT019.mail.protection.outlook.com (10.152.88.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14 via Frontend Transport; Wed, 21 Jun 2017 08:40:04 +0000 Received: from BN6PR12MB1524.namprd12.prod.outlook.com ([10.172.18.9]) by BN6PR12MB1524.namprd12.prod.outlook.com ([10.172.18.9]) with mapi id 15.01.1178.013; Wed, 21 Jun 2017 08:40:04 +0000 From: Philippe Clavier To: "lp-wan@ietf.org" Thread-Topic: Idea for SCHC rules rearrangement Thread-Index: AQHS6me5n08sMX+5K0qQ+sJHUjH+ig== Date: Wed, 21 Jun 2017 08:40:04 +0000 Message-ID: Accept-Language: es-AR, en-US Content-Language: es-AR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:A48A26C3C479253ED302C8929FF5A1E8F3B105E9A6994D3865D2B9889E0848EA; UpperCasedChecksum:7443457A0B4FA69AB74A28DB9C36D474CB0B20705867248874228C0B7A86F6E2; SizeAsReceived:7031; Count:43 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [jnoZO3jh4Ybgazmst0cMlxppDDge8dOO] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM04HT085; 7:BIjls5zwaD2gDEliNe7xvT/6TljQTNGhGCpFFal7qZ9wMPjQXzy0Ks7l8ck/z9P9eBk3ZSyC48n5d6oXn5SSsuuZ903HmX3UdcHMB+VpvdkZVoPN9pBsxtnfrAbPPrY50KVNJ4Fckq9C+ye27K++hkRQ0+sFNfc8dm7BZC8Z0lkuSxrCQzrCEBU7AenJLoCA9CvJ8htZJrtCYHgRX4uQHsm/Nt6mKQ3ywlvfO7lAL/l8ertW788Ylz1ie3jCGLWWtdlXrgTCegAKgcFGo4tZbdWPD70QxCxKjnwJ4xQPZtWYdskIdK7A/BSwYOJkuxn+ilEcyjiv1ZmTWdE3/9O/BRErVW5pxfWQkY74/a2K1eCy3lO8MzFJqh56/AOIx6dXUHKFsDcZbdfxOaVpWvHY2QM2vm3q+Xrb6sD2eBkWspcIXOg6uOAcGAP80v/izbrlMvgqMUbhOvxouztxqptuRaFNqjPKQSvw8zgTvdHIq16UMtKU5WfxvSInB0nZefg7h/9MotyTVI5SP/M1kIPPdRkEgqSk7tq+yQy1Dk9Vaw3Tvt8yK+lyPwxgVrZ49dC1HuAt+A25tvT/hnpSaTXtFxM1ebah9wzUDdlSnO6VFVc1ZQI4sgcfBfVAB+IkHZ2r2vzha1k/a36MHaUrKCwLOV3A5OiwqwGRtJY7j1o9Gg0YYyzZKJj9HSNDPuTHcznmWMVEfKgj6D2Oo0qoefP3cqJnFI1dTQCJG2PuU6dQX+nVvdtXedxsm9fj0KWaop6TDvilSPSSyL19r09B1Y1iHA== x-incomingheadercount: 43 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM04HT085; H:BN6PR12MB1524.namprd12.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: aed4380e-c654-4c02-a277-08d4b8811ced x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1603101448)(1601125374)(1701031045); SRVR:SN1NAM04HT085; x-ms-traffictypediagnostic: SN1NAM04HT085: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:SN1NAM04HT085; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1NAM04HT085; x-forefront-prvs: 0345CFD558 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_BN6PR12MB1524414E42066BDA08D38DE9D9DA0BN6PR12MB1524namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 08:40:04.0772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT085 Archived-At: Subject: [lp-wan] Idea for SCHC rules rearrangement X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 08:40:35 -0000 --_004_BN6PR12MB1524414E42066BDA08D38DE9D9DA0BN6PR12MB1524namp_ Content-Type: multipart/alternative; boundary="_000_BN6PR12MB1524414E42066BDA08D38DE9D9DA0BN6PR12MB1524namp_" --_000_BN6PR12MB1524414E42066BDA08D38DE9D9DA0BN6PR12MB1524namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I have been thinking about some ways to rearrange the format for the compre= ssion rules which might be more efficient. I have attached an example for the arrangement of the rules in a text file. Using the new arrangement uniquely decodable rule IDs can be defined avoidi= ng the need to repeat the same field compression in different rules (and th= e necessity for many rules). For example, in the worst case (in which all p= ossible field compressions are evaluated) the first format would require to= evaluate 42 possibilities. Where in the new format, it would require only = 18 possible field compressions to be evaluated. This difference drastically= grows if it is required to define more field compressions. Also, this new = arrangement allows more compressions to be done. For example, with the new = format a message with DEVport from Rule 0 and APPport from Rule 1 could be = compressed. One way for obtaining a uniquely decodable code for the rule IDs from the F= CIDs could be, for example, by indexing the permutations of possible compre= ssions. If there is only one compression for a given field the FCID will ha= ve no value, and will add no more possibilities of compression. In the example given before the encoding for the rule IDs would be: 0000 ( UDP DEVport 0 - UDP DEVport 0 ) 0001 ( UDP DEVport 0 - UDP DEVport 1 ) 0010 ( UDP DEVport 0 - UDP DEVport 2 ) 0011 ( UDP DEVport 1 - UDP DEVport 0 ) 0100 ( UDP DEVport 1 - UDP DEVport 1 ) 0101 ( UDP DEVport 1 - UDP DEVport 2 ) 0110 ( UDP DEVport 2 - UDP DEVport 0 ) 0111 ( UDP DEVport 2 - UDP DEVport 1 ) 1000 ( UDP DEVport 2 - UDP DEVport 2 ) In this case, there are 3 * 3 =3D 9 possible compressions, so 4 bits would = be required for the Rule ID. In the previous format, there are only 3 possible compressions, so 2 bits w= ould be required for the Rule ID. To conclude, advantages of using the new format are that less memory is req= uired to store the rules, less computational complexity is required to eval= uate the matching of every field and its compression, and furthermore it ma= kes it easier to implement later changes in the rules, as it the previous a= rrangement it will be required to change all the different rules that conta= in that same field compression. The disadvantage of this is that the Rule ID obtained will be larger as it = considers all possible permutations. The new format considers more possibil= ities for compression which may not be required and (if not needed) would a= dd extra unnecessary bits to the representation of the Rule IDs. Neverthele= ss, this problem could be tackled by a later encoding of the rule IDs in an= uniquely decodable optimal code. In such way that most used rules would re= quire less bits than the rules less used. I hope my explanations were clear, I am looking forward to your opinions on= the matter. Regards, Philippe Clavier --_000_BN6PR12MB1524414E42066BDA08D38DE9D9DA0BN6PR12MB1524namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

I have been thinking about some ways = to rearrange the format for the compression rules which might be more effic= ient.
I have attached an example for the arrangement of the ru= les in a text file.

Using the new arrangement uniquely decodable rule IDs can be defined a= voiding the need to repeat the same field compression in different rul= es (and the necessity for many rules). = Where in the new format, it would require only 18 possible field compressio= ns to be evaluated. This difference drastically grows if it is required to define more field compressions. Also, this new arrangement allows more compre= ssions to be done. For example, with the new format a message with DEVport = from Rule 0 and APPport from Rule 1 could be compressed.

One way for obtaining a uniquely decodable code for the rule IDs from = the FCIDs could be, for example, by indexing the permutations of possible c= ompressions. If there is only one com= pression for a given field the FCID will have no value, and will add no more possibilities of compression. 

In the example given before the encod= ing for the rule IDs would be:

    0000 ( UDP DEVport 0 - UDP DEVport 0 )
    0001 ( UDP DEVport 0 - UDP DEVport 1 )
    0010 ( UDP DEVport 0 - UDP DEVport 2 )
    0011 ( UDP DEVport 1 - UDP DEVport 0 )
    0100 ( UDP DEVport 1 - UDP DEVport 1 )
    0101 ( UDP DEVport 1 - UDP DEVport 2 )
    0110 ( UDP DEVport 2 - UDP DEVport 0 )
    0111 ( UDP DEVport 2 - UDP DEVport 1 )
    1000 ( UDP DEVport 2 - UDP DEVport 2 )

In this case, there are 3 * 3 =3D 9 possible compressions, so 4 bits w= ould be required for the Rule ID. 
In the previous format, there are only 3 possible compressions, s= o 2 bits would be required for the Rule ID. 
  
To conclude, advantages of using the new format are that less memory i= s required to store the rules, less computational complexity is required to= evaluate the matching of every field and its compression, and furthermore it makes it easier to implement later changes in the rules, as it the previou= s arrangement it will be required to change all the different rules that contain that s= ame field compression.

The disadvantage of this is that the Rule ID obtained will be larger a= s it considers all possible permutations. The new format considers more pos= sibilities for compression which may = not be required and (if not needed) would add extra unnecessary bits to the representation of the Rule IDs. Nevertheless, this problem could be ta= ckled by a later encoding of the rule IDs in an uniquely decodable optimal = code. In such way that most used rules would require less bits than the rules less used.
    
I hope my explanations were clear, I am looking forward to your opinio= ns on the matter.

Regards,
Philippe Clavier

--_000_BN6PR12MB1524414E42066BDA08D38DE9D9DA0BN6PR12MB1524namp_-- --_004_BN6PR12MB1524414E42066BDA08D38DE9D9DA0BN6PR12MB1524namp_ Content-Type: text/plain; name="Rule rearrangement example.txt" Content-Description: Rule rearrangement example.txt Content-Disposition: attachment; filename="Rule rearrangement example.txt"; size=5935; creation-date="Wed, 21 Jun 2017 08:33:28 GMT"; modification-date="Wed, 21 Jun 2017 08:33:28 GMT" Content-Transfer-Encoding: base64 R2l2ZW4gdGhlc2UgcHJldmlvdXMgcnVsZXMgZXhhbXBsZXMgaW4gd2hpY2ggdGhleSBvbmx5IGRp ZmZlciBpbiB0aGUgVURQIERFVnBvcnQgYW5kIEFQUHBvcnQgY29tcHJlc3Npb24gZmllbGRzOg0K DQpSdWxlIDANCiAgICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0rLS0rLS0tLS0tLS0tKy0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0rDQogICAgIHwgRmllbGQgICAgICAgICAgfEZQfERJfCBWYWx1ZSAgIHwg TWF0Y2ggIHwgQ29tcCBEZWNvbXAgfA0KICAgICB8ICAgICAgICAgICAgICAgIHwgIHwgIHwgICAg ICAgICB8IE9wZXJhLiB8IEFjdGlvbiAgICAgIHwNCiAgICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0r LS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgIHxJUHY2IHZlcnNpb24g ICAgfDEgfEJpfDYgICAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8SVB2NiBE aWZmU2VydiAgIHwxIHxCaXwwICAgICAgICB8IGVxdWFsICB8IG5vdC1zZW50ICAgIHwNCiAgICAg fElQdjYgRmxvdyBMYWJlbCB8MSB8Qml8MCAgICAgICAgfCBlcXVhbCAgfCBub3Qtc2VudCAgICB8 DQogICAgIHxJUHY2IExlbmd0aCAgICAgfDEgfEJpfCAgICAgICAgIHwgaWdub3JlIHwgY29tcC1s ZW5ndGggfA0KICAgICB8SVB2NiBOZXh0IEhlYWRlcnwxIHxCaXwxNyAgICAgICB8IGVxdWFsICB8 IG5vdC1zZW50ICAgIHwNCiAgICAgfElQdjYgSG9wIExpbWl0ICB8MSB8Qml8MjU1ICAgICAgfCBp Z25vcmUgfCBub3Qtc2VudCAgICB8DQogICAgIHxJUHY2IERFVnByZWZpeCAgfDEgfEJpfEZFODA6 Oi82NHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8SVB2NiBERVZpaWQgICAgIHwxIHxC aXwgICAgICAgICB8IGlnbm9yZSB8IERFVmlpZCAgICAgIHwNCiAgICAgfElQdjYgQVBQcHJlZml4 ICB8MSB8Qml8RkU4MDo6LzY0fCBlcXVhbCAgfCBub3Qtc2VudCAgICB8DQogICAgIHxJUHY2IEFQ UGlpZCAgICAgfDEgfEJpfDo6MSAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICAr PT09PT09PT09PT09PT09PSs9PSs9PSs9PT09PT09PT0rPT09PT09PT0rPT09PT09PT09PT09PSsN CiAgICAgfFVEUCBERVZwb3J0ICAgICB8MSB8Qml8MTIzICAgICAgfCBlcXVhbCAgfCBub3Qtc2Vu dCAgICB8DQogICAgIHxVRFAgQVBQcG9ydCAgICAgfDEgfEJpfDEyNCAgICAgIHwgZXF1YWwgIHwg bm90LXNlbnQgICAgfA0KICAgICB8VURQIExlbmd0aCAgICAgIHwxIHxCaXwgICAgICAgICB8IGln bm9yZSB8IGNvbXAtbGVuZ3RoIHwNCiAgICAgfFVEUCBjaGVja3N1bSAgICB8MSB8Qml8ICAgICAg ICAgfCBpZ25vcmUgfCBjb21wLWNoayAgICB8DQogICAgICs9PT09PT09PT09PT09PT09Kz09Kz09 Kz09PT09PT09PSs9PT09PT09PSs9PT09PT09PT09PT09Kw0KICAgICANClJ1bGUgMQ0KICAgICAr LS0tLS0tLS0tLS0tLS0tLSstLSstLSstLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsN CiAgICAgfCBGaWVsZCAgICAgICAgICB8RlB8REl8IFZhbHVlICAgfCBNYXRjaCAgfCBDb21wIERl Y29tcCB8DQogICAgIHwgICAgICAgICAgICAgICAgfCAgfCAgfCAgICAgICAgIHwgT3BlcmEuIHwg QWN0aW9uICAgICAgfA0KICAgICArLS0tLS0tLS0tLS0tLS0tLSstLSstLSstLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgfElQdjYgdmVyc2lvbiAgICB8MSB8Qml8NiAgICAg ICAgfCBlcXVhbCAgfCBub3Qtc2VudCAgICB8DQogICAgIHxJUHY2IERpZmZTZXJ2ICAgfDEgfEJp fDAgICAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8SVB2NiBGbG93IExhYmVs IHwxIHxCaXwwICAgICAgICB8IGVxdWFsICB8IG5vdC1zZW50ICAgIHwNCiAgICAgfElQdjYgTGVu Z3RoICAgICB8MSB8Qml8ICAgICAgICAgfCBpZ25vcmUgfCBjb21wLWxlbmd0aCB8DQogICAgIHxJ UHY2IE5leHQgSGVhZGVyfDEgfEJpfDE3ICAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0K ICAgICB8SVB2NiBIb3AgTGltaXQgIHwxIHxCaXwyNTUgICAgICB8IGlnbm9yZSB8IG5vdC1zZW50 ICAgIHwNCiAgICAgfElQdjYgREVWcHJlZml4ICB8MSB8Qml8RkU4MDo6LzY0fCBlcXVhbCAgfCBu b3Qtc2VudCAgICB8DQogICAgIHxJUHY2IERFVmlpZCAgICAgfDEgfEJpfCAgICAgICAgIHwgaWdu b3JlIHwgREVWaWlkICAgICAgfA0KICAgICB8SVB2NiBBUFBwcmVmaXggIHwxIHxCaXxGRTgwOjov NjR8IGVxdWFsICB8IG5vdC1zZW50ICAgIHwNCiAgICAgfElQdjYgQVBQaWlkICAgICB8MSB8Qml8 OjoxICAgICAgfCBlcXVhbCAgfCBub3Qtc2VudCAgICB8DQogICAgICs9PT09PT09PT09PT09PT09 Kz09Kz09Kz09PT09PT09PSs9PT09PT09PSs9PT09PT09PT09PT09Kw0KICAgICB8VURQIERFVnBv cnQgICAgIHwxIHxCaXw1NjgzICAgICB8IGVxdWFsICB8IG5vdC1zZW50ICAgIHwNCiAgICAgfFVE UCBBUFBwb3J0ICAgICB8MSB8Qml8NTY4MyAgICAgfCBlcXVhbCAgfCBub3Qtc2VudCAgICB8DQog ICAgIHxVRFAgTGVuZ3RoICAgICAgfDEgfEJpfCAgICAgICAgIHwgaWdub3JlIHwgY29tcC1sZW5n dGggfA0KICAgICB8VURQIGNoZWNrc3VtICAgIHwxIHxCaXwgICAgICAgICB8IGlnbm9yZSB8IGNv bXAtY2hrICAgIHwNCiAgICAgKz09PT09PT09PT09PT09PT0rPT0rPT0rPT09PT09PT09Kz09PT09 PT09Kz09PT09PT09PT09PT0rDQogICAgIA0KUnVsZSAyDQogICAgICstLS0tLS0tLS0tLS0tLS0t Ky0tKy0tKy0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0tKw0KICAgICB8IEZpZWxkICAg ICAgICAgIHxGUHxESXwgVmFsdWUgICB8IE1hdGNoICB8IENvbXAgRGVjb21wIHwNCiAgICAgfCAg ICAgICAgICAgICAgICB8ICB8ICB8ICAgICAgICAgfCBPcGVyYS4gfCBBY3Rpb24gICAgICB8DQog ICAgICstLS0tLS0tLS0tLS0tLS0tKy0tKy0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KICAgICB8SVB2NiB2ZXJzaW9uICAgIHwxIHxCaXw2ICAgICAgICB8IGVxdWFsICB8IG5v dC1zZW50ICAgIHwNCiAgICAgfElQdjYgRGlmZlNlcnYgICB8MSB8Qml8MCAgICAgICAgfCBlcXVh bCAgfCBub3Qtc2VudCAgICB8DQogICAgIHxJUHY2IEZsb3cgTGFiZWwgfDEgfEJpfDAgICAgICAg IHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8SVB2NiBMZW5ndGggICAgIHwxIHxCaXwg ICAgICAgICB8IGlnbm9yZSB8IGNvbXAtbGVuZ3RoIHwNCiAgICAgfElQdjYgTmV4dCBIZWFkZXJ8 MSB8Qml8MTcgICAgICAgfCBlcXVhbCAgfCBub3Qtc2VudCAgICB8DQogICAgIHxJUHY2IEhvcCBM aW1pdCAgfDEgfEJpfDI1NSAgICAgIHwgaWdub3JlIHwgbm90LXNlbnQgICAgfA0KICAgICB8SVB2 NiBERVZwcmVmaXggIHwxIHxCaXxGRTgwOjovNjR8IGVxdWFsICB8IG5vdC1zZW50ICAgIHwNCiAg ICAgfElQdjYgREVWaWlkICAgICB8MSB8Qml8ICAgICAgICAgfCBpZ25vcmUgfCBERVZpaWQgICAg ICB8DQogICAgIHxJUHY2IEFQUHByZWZpeCAgfDEgfEJpfEZFODA6Oi82NHwgZXF1YWwgIHwgbm90 LXNlbnQgICAgfA0KICAgICB8SVB2NiBBUFBpaWQgICAgIHwxIHxCaXw6OjEgICAgICB8IGVxdWFs ICB8IG5vdC1zZW50ICAgIHwNCiAgICAgKz09PT09PT09PT09PT09PT0rPT0rPT0rPT09PT09PT09 Kz09PT09PT09Kz09PT09PT09PT09PT0rDQogICAgIHxVRFAgREVWcG9ydCAgICAgfDEgfEJpfDg3 MjAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8VURQIEFQUHBvcnQgICAgIHwx IHxCaXw4NzIwICAgICB8IGVxdWFsICB8IG5vdC1zZW50ICAgIHwNCiAgICAgfFVEUCBMZW5ndGgg ICAgICB8MSB8Qml8ICAgICAgICAgfCBpZ25vcmUgfCBjb21wLWxlbmd0aCB8DQogICAgIHxVRFAg Y2hlY2tzdW0gICAgfDEgfEJpfCAgICAgICAgIHwgaWdub3JlIHwgY29tcC1jaGsgICAgfA0KICAg ICArPT09PT09PT09PT09PT09PSs9PSs9PSs9PT09PT09PT0rPT09PT09PT0rPT09PT09PT09PT09 PSsgICAgIA0KICAgICANCkJ5IGFkZGluZyBhIEZDSUQgKEZpZWxkIENvbXByZXNzaW9uIElEKSB0 byB0aGUgZmllbGRzLCBtb3JlIHRoYW4gb25lIGNvbXByZXNzaW9uIHBlciBmaWVsZCBjYW4gYmUg bG9hZGVkIGFuZCBvbmx5IG9uZSAicnVsZSIgd291bGQgYmUgcmVxdWlyZWQuDQpUbyBiZSBhYmxl IHRvIGNvbXByZXNzIHRoZSBzYW1lIG1lc3NhZ2VzIGFzIHRoZSB0aHJlZSBwcmV2aW91cyBydWxl cyBnaXZlbiwgdGhlIGZvbGxvd2luZyAicnVsZSIgc2hvdWxkIGJlIHVzZWQ6DQogICAgIA0KICAg ICArLS0tLS0tLS0tLS0tLS0tLSstLSstLS0tKy0tKy0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0t LS0tLS0tKw0KICAgICB8IEZpZWxkICAgICAgICAgIHxGUHxGQ0lEfERJfCBWYWx1ZSAgIHwgTWF0 Y2ggIHwgQ29tcCBEZWNvbXAgfA0KICAgICB8ICAgICAgICAgICAgICAgIHwgIHwgICAgfCAgfCAg ICAgICAgIHwgT3BlcmEuIHwgQWN0aW9uICAgICAgfA0KICAgICArLS0tLS0tLS0tLS0tLS0tLSst LSstLS0tKy0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICB8SVB2NiB2 ZXJzaW9uICAgIHwxIHwgICAgfEJpfDYgICAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0K ICAgICB8SVB2NiBEaWZmU2VydiAgIHwxIHwgICAgfEJpfDAgICAgICAgIHwgZXF1YWwgIHwgbm90 LXNlbnQgICAgfA0KICAgICB8SVB2NiBGbG93IExhYmVsIHwxIHwgICAgfEJpfDAgICAgICAgIHwg ZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8SVB2NiBMZW5ndGggICAgIHwxIHwgICAgfEJp fCAgICAgICAgIHwgaWdub3JlIHwgY29tcC1sZW5ndGggfA0KICAgICB8SVB2NiBOZXh0IEhlYWRl cnwxIHwgICAgfEJpfDE3ICAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8SVB2 NiBIb3AgTGltaXQgIHwxIHwgICAgfEJpfDI1NSAgICAgIHwgaWdub3JlIHwgbm90LXNlbnQgICAg fA0KICAgICB8SVB2NiBERVZwcmVmaXggIHwxIHwgICAgfEJpfEZFODA6Oi82NHwgZXF1YWwgIHwg bm90LXNlbnQgICAgfA0KICAgICB8SVB2NiBERVZpaWQgICAgIHwxIHwgICAgfEJpfCAgICAgICAg IHwgaWdub3JlIHwgREVWaWlkICAgICAgfA0KICAgICB8SVB2NiBBUFBwcmVmaXggIHwxIHwgICAg fEJpfEZFODA6Oi82NHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8SVB2NiBBUFBpaWQg ICAgIHwxIHwgICAgfEJpfDo6MSAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICAr PT09PT09PT09PT09PT09PSs9PSs9PT09Kz09Kz09PT09PT09PSs9PT09PT09PSs9PT09PT09PT09 PT09Kw0KICAgICB8VURQIERFVnBvcnQgICAgIHwxIHwgMCAgfEJpfDEyMyAgICAgIHwgZXF1YWwg IHwgbm90LXNlbnQgICAgfCAgICAgICAgIA0KICAgICB8ICAgICAgICAgICAgICAgIHwxIHwgMSAg fEJpfDU2ODMgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8ICAgICAgICAgICAg ICAgIHwxIHwgMiAgfEJpfDg3MjAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8 VURQIEFQUHBvcnQgICAgIHwxIHwgMCAgfEJpfDEyNCAgICAgIHwgZXF1YWwgIHwgbm90LXNlbnQg ICAgfA0KICAgICB8ICAgICAgICAgICAgICAgIHwxIHwgMSAgfEJpfDU2ODMgICAgIHwgZXF1YWwg IHwgbm90LXNlbnQgICAgfA0KICAgICB8ICAgICAgICAgICAgICAgIHwxIHwgMiAgfEJpfDg3MjAg ICAgIHwgZXF1YWwgIHwgbm90LXNlbnQgICAgfA0KICAgICB8VURQIExlbmd0aCAgICAgIHwxIHwg ICAgfEJpfCAgICAgICAgIHwgaWdub3JlIHwgY29tcC1sZW5ndGggfA0KICAgICB8VURQIGNoZWNr c3VtICAgIHwxIHwgICAgfEJpfCAgICAgICAgIHwgaWdub3JlIHwgY29tcC1jaGsgICAgfA0KICAg ICArPT09PT09PT09PT09PT09PSs9PSs9PT09Kz09Kz09PT09PT09PSs9PT09PT09PSs9PT09PT09 PT09PT09Kw== --_004_BN6PR12MB1524414E42066BDA08D38DE9D9DA0BN6PR12MB1524namp_-- From nobody Wed Jun 21 01:54:51 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A75131BC5; Wed, 21 Jun 2017 01:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 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 lgLkZTPOiC5M; Wed, 21 Jun 2017 01:54:47 -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 0CA9D131BE0; Wed, 21 Jun 2017 01:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6262; q=dns/txt; s=iport; t=1498035255; x=1499244855; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=w/t+LOKLkwHGSFwtPjTvZskVogVjA8KCMAx8Zgu1oMk=; b=C97EaAWWwK5h3IH/t1uHDfYMKZwMIUnROgeB7cpi2wJzSCRnvfVd/bzb poaTWLBy5ZaWlJWF309qQWuBETa3Lhtij60it9FEotp19GFhwgLoYhUiw 3ssxYG+2wcbydqUtv39aQWvTubXxIoGCRsD5QrNDxsBPpI0IWBdMho67P 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQDCM0pZ/4oNJK1MERoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYNYYoENB4NlihmSAXOVBYIRLIV4AhqCVD8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDHQYRNB0EAgEIEQQBAQMCIwMCAgIwFAEGAQEFAwIEARIIDIoYEKoAgiaDU?= =?us-ascii?q?wKFAIMHAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VigWCCGFg0gTwBgn4PAwG?= =?us-ascii?q?DLoJhBZBBhlyHRQKHMYM9iGmCEYVIij6VEAEfOH8LdBVJhw92AYc5gSOBDQEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.39,368,1493683200"; d="scan'208";a="250191569" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2017 08:54:14 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v5L8sEhM027203 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2017 08:54:14 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Jun 2017 03:54:13 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 21 Jun 2017 03:54:13 -0500 From: "Pascal Thubert (pthubert)" To: lp-wan , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: NomCom 2017-2018 Third and FINAL Call for Volunteers Thread-Index: AQHS6gIoPEuFc40AVE2Z+LGfWLTSqKIvA21Q Date: Wed, 21 Jun 2017 08:54:08 +0000 Deferred-Delivery: Wed, 21 Jun 2017 08:54:07 +0000 Message-ID: <829acf12b786413a897a8ac230ba6628@XCH-RCD-001.cisco.com> References: <149788872004.10693.15641542068601991395.idtracker@ietfa.amsl.com> In-Reply-To: <149788872004.10693.15641542068601991395.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [lp-wan] FW: NomCom 2017-2018 Third and FINAL Call for Volunteers X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 08:54:50 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYtQW5ub3VuY2UgW21haWx0bzpp ZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOb21Db20gQ2hhaXIg MjAxNw0KU2VudDogbHVuZGkgMTkganVpbiAyMDE3IDE4OjEyDQpUbzogSUVURiBBbm5vdW5jZW1l bnQgTGlzdCA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiBpZXRmQGlldGYub3JnDQpTdWJq ZWN0OiBOb21Db20gMjAxNy0yMDE4IFRoaXJkIGFuZCBGSU5BTCBDYWxsIGZvciBWb2x1bnRlZXJz DQoNClRoZSBJRVRGIE5vbUNvbSBhcHBvaW50cyBmb2xrcyB0byBmaWxsIHRoZSBvcGVuIHNsb3Rz IG9uIHRoZSBJQU9DLCB0aGUgSUFCLCBhbmQgdGhlIElFU0cuDQoNClRlbiB2b3RpbmcgbWVtYmVy cyBmb3IgdGhlIE5vbUNvbSBhcmUgc2VsZWN0ZWQgaW4gYSB2ZXJpZmlhYmx5IHJhbmRvbSB3YXkg ZnJvbSBhIHBvb2wgb2Ygdm9sdW50ZWVycy4gVGhlIG1vcmUgdm9sdW50ZWVycywgdGhlIGJldHRl ciBjaGFuY2Ugd2UgaGF2ZSBvZiBjaG9vc2luZyBhIHJhbmRvbSB5ZXQgcmVwcmVzZW50YXRpdmUg Y3Jvc3Mgc2VjdGlvbiBvZiB0aGUgSUVURiBwb3B1bGF0aW9uLg0KDQpUaGUgZGV0YWlscyBvZiB0 aGUgb3BlcmF0aW9uIG9mIHRoZSBOb21Db20gY2FuIGJlIGZvdW5kIGluIFJGQyA3NDM3IChCQ1Ag MTApLCBhbmQgUkZDIDM3OTcgZGV0YWlscyB0aGUgc2VsZWN0aW9uIGFsZ29yaXRobS4NCg0KVm9s dW50ZWVycyBtdXN0IGhhdmUgYXR0ZW5kZWQgMyBvZiB0aGUgcGFzdCA1IElFVEYgbWVldGluZ3Mu ICBBcyBzcGVjaWZpZWQgaW4gUkZDIDc0MzcsIHRoYXQgbWVhbnMgdGhyZWUgb3V0IG9mIHRoZSBm aXZlIHBhc3QgbWVldGluZ3MgdXAgdG8gdGhlIHRpbWUgdGhpcyBlbWFpbCBhbm5vdW5jZW1lbnQg Z29lcyBvdXQgdG8gc3RhcnQgdGhlIHNvbGljaXRhdGlvbiBvZiB2b2x1bnRlZXJzLiBUaGUgZml2 ZSBtZWV0aW5ncyBvdXQgb2Ygd2hpY2ggeW91IG11c3QgaGF2ZSBhdHRlbmRlZCAqdGhyZWUqIGFy ZToNCg0KSUVURiA9IDk0IChZb2tvaGFtYSkgICAgICBcDQogICAgICAgOTUgKEJ1ZW5vcyBBaXJl cykgICBcDQogICAgICAgOTYgKEJlcmxpbikgICAgICAgICAgLSoqKiBBTlkgVEhSRUUhDQogICAg ICAgOTcgKFNlb3VsKSAgICAgICAgICAvDQogICAgICAgOTggKENoaWNhZ28pICAgICAgIC8NCg0K WW91IGNhbiBjaGVjayB5b3VyIGVsaWdpYmlsaXR5IGF0OiBodHRwczovL3d3dy5pZXRmLm9yZy9y ZWdpc3RyYXRpb24vbm9tY29tLnB5DQoNCklmIHlvdSBxdWFsaWZ5LCBwbGVhc2Ugdm9sdW50ZWVy LiBCZWZvcmUgeW91IGRlY2lkZSB0byB2b2x1bnRlZXIsIHBsZWFzZSByZW1lbWJlciB0aGF0IGFu eW9uZSBhcHBvaW50ZWQgdG8gdGhpcyBOb21Db20gd2lsbCBub3QgYmUgY29uc2lkZXJlZCBhcyBh IGNhbmRpZGF0ZSBmb3IgYW55IG9mIHRoZSBwb3NpdGlvbnMgdGhhdCB0aGUgMjAxNyAtIDIwMTgg Tm9tQ29tIGlzIHJlc3BvbnNpYmxlIGZvciBmaWxsaW5nLg0KDQpTb21lIDIwMSBwZW9wbGUgaGF2 ZSBhbHJlYWR5IHZvbHVudGVlcmVkIGJ5IHRpY2tpbmcgdGhlIGJveCBvbiB0aGUgSUVURiA5NiB0 aHJvdWdoIDk4IHJlZ2lzdHJhdGlvbiBmb3Jtcy4gSSB3aWxsIGNvbnRhY3QgYWxsIG9mIHRoZXNl IHZvbHVudGVlcnMgc2hvcnRseS4gVGhhbmsgeW91IGZvciB2b2x1bnRlZXJpbmchDQoNClRoZSBs aXN0IG9mIHBlb3BsZSBhbmQgcG9zdHMgd2hvc2UgdGVybXMgZW5kIHdpdGggdGhlIE1hcmNoIDIw MTggSUVURiBtZWV0aW5nLCBhbmQgdGh1cyB0aGUgcG9zaXRpb25zIGZvciB3aGljaCB0aGlzIE5v bUNvbSBpcyByZXNwb25zaWJsZSwgYXJlDQoNCklBT0M6DQoNCiAgICBMZXNsaWUgRGFpZ2xlDQoN CklBQjoNCg0KICAgIFRlZCBIYXJkaWUNCiAgICBKb2UgSGlsZGVicmFuZA0KICAgIExlZSBIb3dh cmQNCiAgICBFcmlrIE5vcmRtYXJrDQogICAgTWFydGluIFRob21zb24NCiAgICBCcmlhbiBUcmFt bWVsbA0KDQpJRVNHOg0KDQogICAgQWxpYSBBdGxhcyAoUlRHKQ0KICAgIEJlbm9pdCBDbGFpc2Ug KE9QUykNCiAgICBTdXJlc2ggS3Jpc2huYW4gKElOVCkNCiAgICBNaXJqYSBLw7xobGV3aW5kIChU U1YpDQogICAgQWxleGV5IE1lbG5pa292IChBUlQpDQogICAgS2F0aGxlZW4gTW9yaWFydHkgKFNF QykNCiAgICBBZGFtIFJvYWNoIChBUlQpDQogDQoNCkFsbCBhcHBvaW50bWVudHMgYXJlIGZvciAy IHllYXJzLiBUaGUgQVJUIGFuZCBSb3V0aW5nIGFyZWFzIGhhdmUgMyBBRHMgYW5kIHRoZSBHZW5l cmFsIGFyZWEgaGFzIDE7IGFsbCBvdGhlciBhcmVhcyBoYXZlIDIgQURzLiAgVGh1cywgYWxsIGFy ZWFzIGhhdmUgYXQgbGVhc3Qgb25lIGNvbnRpbnVpbmcgQUQuDQoNClRoZSBwcmltYXJ5IGFjdGl2 aXR5IGZvciB0aGlzIE5vbUNvbSB3aWxsIGJlZ2luIGluIEp1bHkgMjAxNyBhbmQgc2hvdWxkIGJl IGNvbXBsZXRlZCBpbiBKYW51YXJ5IDIwMTguICBUaGUgTm9tQ29tIHdpbGwgaGF2ZSByZWd1bGFy bHkgc2NoZWR1bGVkIGNvbmZlcmVuY2UgY2FsbHMgdG8gZW5zdXJlIHByb2dyZXNzLiBUaGVyZSB3 aWxsIGJlIGFjdGl2aXRpZXMgdG8gY29sbGVjdCByZXF1aXJlbWVudHMgZnJvbSB0aGUgY29tbXVu aXR5LCByZXZpZXcgY2FuZGlkYXRlIHF1ZXN0aW9ubmFpcmVzLCByZXZpZXcgZmVlZGJhY2sgZnJv bSBjb21tdW5pdHkgbWVtYmVycyBhYm91dCBjYW5kaWRhdGVzLCBhbmQgdGFsayB0byBjYW5kaWRh dGVzLg0KDQpXaGlsZSBiZWluZyBhIE5vbUNvbSBtZW1iZXIgZG9lcyByZXF1aXJlIHNvbWUgdGlt ZSBjb21taXRtZW50IGl0IGlzIGFsc28gYSB2ZXJ5IHJld2FyZGluZyBleHBlcmllbmNlLg0KDQpB cyBhIG1lbWJlciBvZiB0aGUgTm9tQ29tIGl0IGlzIHZlcnkgaW1wb3J0YW50IHRoYXQgeW91IGJl IGFibGUgdG8gYXR0ZW5kIElFVEYgMTAwIChTaW5nYXBvcmUpIHRvIGNvbmR1Y3QgaW50ZXJ2aWV3 cy4gIEJlaW5nIGF0IElFVEYgOTkgKFByYWd1ZSkgaXMgdXNlZnVsIGZvciBvcmllbnRhdGlvbi4g IEJlaW5nIGF0IElFVEYgMTAxIChMb25kb24pIGlzIG5vdCBlc3NlbnRpYWwuDQoNClBsZWFzZSB2 b2x1bnRlZXIgYnkgc2VuZGluZyBtZSBhbiBlbWFpbCBiZWZvcmUgMjM6NTkgVVRDIEp1bmUgMjYs IDIwMTcsIGFzIGZvbGxvd3M6DQoNClRvOiBub21jb20tY2hhaXItMjAxNyBhdCBpZXRmIGRvdCBv cmcNClN1YmplY3Q6IE5vbUNvbSAyMDE3LTE4IFZvbHVudGVlcg0KDQpQbGVhc2UgaW5jbHVkZSB0 aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIGluIHRoZSBlbWFpbCBib2R5Og0KDQpZb3VyIEZ1bGwg TmFtZTogX19fX19fX19fXw0KICAgIC8vIGFzIHlvdSB3cml0ZSBpdCBvbiB0aGUgSUVURiByZWdp c3RyYXRpb24gZm9ybQ0KDQpDdXJyZW50IFByaW1hcnkgQWZmaWxpYXRpb246DQogICAgLy8gVHlw aWNhbGx5IHdoYXQgZ29lcyBpbiB0aGUgQ29tcGFueSBmaWVsZA0KICAgIC8vIGluIHRoZSBJRVRG IFJlZ2lzdHJhdGlvbiBGb3JtDQoNCkVtYWlsczogX19fX19fX19fX19fX19fDQogICAvLyBBbGwg ZW1haWwgYWRkcmVzc2VzIHVzZWQgdG8gcmVnaXN0ZXIgZm9yIHRoZSBwYXN0IDUgSUVURiBtZWV0 aW5ncw0KICAgLy8gUHJlZmVycmVkIGVtYWlsIGFkZHJlc3MgZmlyc3QNCg0KVGVsZXBob25lOiBf X19fX19fX19fX19fX19fX19fX19fXw0KICAgIC8vIEZvciBjb25maXJtYXRpb24gaWYgc2VsZWN0 ZWQNCg0KWW91IHNob3VsZCBleHBlY3QgYW4gZW1haWwgcmVzcG9uc2UgZnJvbSBtZSB3aXRoaW4g NSBidXNpbmVzcyBkYXlzIHN0YXRpbmcgd2hldGhlciBvciBub3QgeW91IGFyZSBxdWFsaWZpZWQu ICBJZiB5b3UgZG9uJ3QgcmVjZWl2ZSB0aGlzIHJlc3BvbnNlLCBwbGVhc2UgcmUtc2VuZCB5b3Vy IGVtYWlsIHdpdGggdGhlIHRhZyAiUkVTRU5EIiIgYWRkZWQgdG8gdGhlIHN1YmplY3QgbGluZS4N Cg0KSWYgeW91IGFyZSBub3QgeWV0IHN1cmUgaWYgeW91IHdvdWxkIGxpa2UgdG8gdm9sdW50ZWVy LCBwbGVhc2UgY29uc2lkZXIgdGhhdCBOb21Db20gbWVtYmVycyBwbGF5IGEgdmVyeSBpbXBvcnRh bnQgcm9sZSBpbiBzaGFwaW5nIHRoZSBsZWFkZXJzaGlwIG9mIHRoZSBJRVRGLiAgUXVlc3Rpb25z IGJ5IGVtYWlsIG9yIHZvaWNlIGFyZSB3ZWxjb21lLiBWb2x1bnRlZXJpbmcgZm9yIHRoZSBOb21D b20gaXMgYSBncmVhdCB3YXkgdG8gY29udHJpYnV0ZSB0byB0aGUgSUVURiENCg0KWW91IGNhbiBm aW5kIGEgZGV0YWlsZWQgdGltZWxpbmUgb24gdGhlIE5vbUNvbSB3ZWIgc2l0ZSBhdDoNCiAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDE3Lw0KDQpJIHdpbGwgYmUgcHVi bGlzaGluZyBhIG1vcmUgZGV0YWlsZWQgdGFyZ2V0IHRpbWV0YWJsZSwgYXMgd2VsbCBhcyBkZXRh aWxzIG9mIHRoZSByYW5kb21uZXNzIHNlZWRzIHRvIGJlIHVzZWQgZm9yIHRoZSBSRkMgMzc5NyBz ZWxlY3Rpb24gcHJvY2Vzcywgd2l0aGluIHNob3J0IG9yZGVyLg0KDQpUaGFuayB5b3UhDQoNClBl dGVyIFllZQ0KcGV0ZXIgYXQgYWtheWxhIGRvdCBjb20NCm5vbWNvbS1jaGFpci0yMDE3IGF0IGll dGYgZG90IG9yZw0KDQo= From nobody Wed Jun 21 02:23:55 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FA3131C78 for ; Wed, 21 Jun 2017 02:23:54 -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] 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 jetsFzk8Wivo for ; Wed, 21 Jun 2017 02:23:52 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23864131C74 for ; Wed, 21 Jun 2017 02:23:51 -0700 (PDT) Received: from mfilter12-d.gandi.net (mfilter12-d.gandi.net [217.70.178.129]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 15E33FB8DA; Wed, 21 Jun 2017 11:23:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter12-d.gandi.net Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter12-d.gandi.net (mfilter12-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id rqDbCkkfhWjB; Wed, 21 Jun 2017 11:23:48 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.157] (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: arun@acklio.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id E3767FB8C9; Wed, 21 Jun 2017 11:23:47 +0200 (CEST) To: Carles Gomez Montenegro Cc: lp-wan@ietf.org References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu> From: Arun Message-ID: <7a4cf891-5c53-96c3-3b4e-4e45a6408b44@ackl.io> Date: Wed, 21 Jun 2017 11:23:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bpjdJBWXvnd9PI8E79lFgf4AHIMlgO7L0" Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 09:23:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bpjdJBWXvnd9PI8E79lFgf4AHIMlgO7L0 Content-Type: multipart/mixed; boundary="Vvmdtb434UsvUjxrOScWnkk5MFBSg9xkR"; protected-headers="v1" From: Arun To: Carles Gomez Montenegro Cc: lp-wan@ietf.org Message-ID: <7a4cf891-5c53-96c3-3b4e-4e45a6408b44@ackl.io> Subject: Re: [lp-wan] re-order header field request References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu> In-Reply-To: <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu> --Vvmdtb434UsvUjxrOScWnkk5MFBSg9xkR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Carles, IMO, Rule ID would be a separate entity from other fields and will not consume Wbit. thanks, Arun On 21/06/2017 10:02, Carles Gomez Montenegro wrote: > Hi Arun, > > The point here is that the Rule ID field in fragments except the last o= ne > will not use the W bit (or equivalently, have one bit less than the Rul= e > ID field in the last fragment as per current formats). > > So I'm wondering if this "additional bit" in the Rule ID of the last > fragment could have any useful purpose or not, or conversely would just= > complicate the structure and uniformity of fragmentation headers. > > Thoughts? > > Cheers, > > Carles > > > >> Hi Carles, >> >> Having the uniform header format seems to be an ideal solution but >> Tx'ing additional bit without any significance seems contentious. >> Will wait for more feedbacks or comments :) >> >> thanks, >> Arun > --Vvmdtb434UsvUjxrOScWnkk5MFBSg9xkR-- --bpjdJBWXvnd9PI8E79lFgf4AHIMlgO7L0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZSjsjAAoJENe8HNMjzJQRCp8P/1som1Ozim0iJgHk3+w+ziRu fB35sZ6IPxkWtFdkd22OZVxAkeop5gmJH94CalKrYCZmYQdOV/ntsMaXHYq50Uzh ctDOy+6wvZgAmSgRKazmawblqNm1Y0ImZoX2KTZLxKM0CR9uHTP6taYQt9wuAI/q m6bvPOvzp0725OTsZ2Vt0nRe0JZLd3FC/HIIdFJtU4YdO8KZGQz00Z29VoPy3UC2 w62f7J0IUk80Ma42DQrBh3LocPT0ToS8VdqKgYN8gtCtY4Yyqa/ZiaQqgqJCz7NO NJwrUQZ3Yykt3k4d5v/zBB7ehydZ/aaYHhOyOEjjpQNTmZy/fLAA+R8rQhJvYUEo yVYGTIWJOF5pkXKJdBDSEDT9DerOtrdcQk45Oj+Lw0c4dPiFQ4Szk/ylxTZq/UoX MzB5Zo/1zzUFgZ0SZEg/ph/W+7BjedfH6/euIxVeWm4fK5AQ2jcWGwJiJcUVS13A /u9obvDt9r/XzIF7WhdYLqMf7efdWQEkPf/rHQA8jpGRnir5+YFmeN46wWY6rUiq 8eePB5Y6JQNbxBpBCPye6OLDvPHE8mRvno/AFQ53vI1CC6fH/5rYXWTqysbKAktT fjI7u0nqEhhuRlSKW6uc4oPNAWL7Mnwm3MSCFbeasovZMq/IwNnmviBeYHfGySSm u/wdYqWMrhLN9hzPlf22 =hOER -----END PGP SIGNATURE----- --bpjdJBWXvnd9PI8E79lFgf4AHIMlgO7L0-- From nobody Wed Jun 21 02:56:03 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD50131CE3 for ; Wed, 21 Jun 2017 02:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 OuBpK-nAkoqW for ; Wed, 21 Jun 2017 02:56:00 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 AE326131C3A for ; Wed, 21 Jun 2017 02:55:59 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5L9tt4S060104; Wed, 21 Jun 2017 11:55:55 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id A4BF51D53C1; Wed, 21 Jun 2017 11:55:54 +0200 (CEST) Received: from 147.83.113.31 by webmail.entel.upc.edu with HTTP; Wed, 21 Jun 2017 11:55:25 +0200 Message-ID: <86fcc1550858ed0ceef59727db24cd24.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu> Date: Wed, 21 Jun 2017 11:55:25 +0200 From: "Carles Gomez Montenegro" To: "Laurent Toutain" Cc: "Arun" , "lp-wan" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: Delayed for 16:05:46 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 21 Jun 2017 11:55:55 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 09:56:02 -0000 Hi Laurent, > I don't think it is a problem to keep it, in a All 1 Frag, even if we > don't > use it (MIC is out of window numbering). we have alignment on bytes when > we send a message, so the benefit is not obvious if we don't keep it. Thanks for your comment. > But in ACK message the W bit must be present. Yes, this is covered by the new feature in -04 whereby all ACKs carry a W bit, which indicates the window being acknowledged. Cheers, Carles > Laurent > > On Wed, Jun 21, 2017 at 10:02 AM, Carles Gomez Montenegro < > carlesgo@entel.upc.edu> wrote: > >> Hi Arun, >> >> The point here is that the Rule ID field in fragments except the last >> one >> will not use the W bit (or equivalently, have one bit less than the Rule >> ID field in the last fragment as per current formats). >> >> So I'm wondering if this "additional bit" in the Rule ID of the last >> fragment could have any useful purpose or not, or conversely would just >> complicate the structure and uniformity of fragmentation headers. >> >> Thoughts? >> >> Cheers, >> >> Carles >> >> >> >> > Hi Carles, >> > >> > Having the uniform header format seems to be an ideal solution but >> > Tx'ing additional bit without any significance seems contentious. >> > Will wait for more feedbacks or comments :) >> > >> > thanks, >> > Arun From nobody Wed Jun 21 02:59:48 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611CC131D01 for ; Wed, 21 Jun 2017 02:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 uGSdjwagDLvu for ; Wed, 21 Jun 2017 02:59:45 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 D0697131CFB for ; Wed, 21 Jun 2017 02:59:44 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5L9xfLg061111; Wed, 21 Jun 2017 11:59:41 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 73A801D53C1; Wed, 21 Jun 2017 11:59:40 +0200 (CEST) Received: from 147.83.113.31 by webmail.entel.upc.edu with HTTP; Wed, 21 Jun 2017 11:59:11 +0200 Message-ID: <687419f530ae701543cb8cb569ba2155.squirrel@webmail.entel.upc.edu> In-Reply-To: <7a4cf891-5c53-96c3-3b4e-4e45a6408b44@ackl.io> References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> <8dd1a778fe41fe8b6ce97cad2b43d62b.squirrel@webmail.entel.upc.edu> <7a4cf891-5c53-96c3-3b4e-4e45a6408b44@ackl.io> Date: Wed, 21 Jun 2017 11:59:11 +0200 From: "Carles Gomez Montenegro" To: "Arun" Cc: lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 21 Jun 2017 11:59:41 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 09:59:46 -0000 Hi Arun, Yes, actually it is the other way round: the W bit is consuming 1 bit out of R bits (the latter defines the size of something we could call the 'original Rule ID space'). Thanks, Carles > Hi Carles, > IMO, Rule ID would be a separate entity from other fields and will not > consume Wbit. > > thanks, > Arun From nobody Wed Jun 21 07:01:54 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F74129B06 for ; Wed, 21 Jun 2017 07:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.273 X-Spam-Level: X-Spam-Status: No, score=-12.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tstaVyq03ofL for ; Wed, 21 Jun 2017 07:01:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B503C129B31 for ; Wed, 21 Jun 2017 07:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41432; q=dns/txt; s=iport; t=1498053708; x=1499263308; h=from:to:subject:date:message-id:mime-version; bh=/wXzZZiTWAiZCiXxwqe0XsKkWGkI1f4mWCEsxfNXCiI=; b=S28anH5iRxl4z++GhZxQDmq4KuOALVVybt+qLd2KWEerfsazcObYIg4Y 8GjUVe6UON48AAdTFt4uqCqPM0S3e73N1A71yif6Z7suNDKAzimTNpCeC ucPPkUUJ3g8P/LILkV4xgKJCiG1CxV1mUloL2SjXWlRqmPcE7RMuJMBpS s=; X-Files: WebEx_Meeting.ics : 4738 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAAAwe0pZ/5JdJa1DFwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCb2ligQ0Hg2VriS6nWIEpBWMHASaEQoE0HIJaPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUdJQo5JQE0BAgBAwYCBDAkAgEEEwgGih4QMqlxgiaDVIgBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBDg+GbYFgHYRDAYFDJoEFMCYKJgeCBxYngkcaBYlZhzO?= =?us-ascii?q?NVgKEE4IdgQGGfYUpghEZPYEPgV+CBIo+ihOKfQEfOIEKdBWFVhyBF092AYhcg?= =?us-ascii?q?Q0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,369,1493683200"; d="ics'?scan'208,217";a="42731745" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 14:01:47 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v5LE1lxb032180 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Jun 2017 14:01:47 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Jun 2017 09:01:46 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 21 Jun 2017 09:01:46 -0500 From: "Pascal Thubert (pthubert)" To: lp-wan Thread-Topic: Join WebEx meeting in progress: LPWAN Interim Thread-Index: AdLqlraichysBKBHTB6uxp33aPffJw== Date: Wed, 21 Jun 2017 14:01:28 +0000 Deferred-Delivery: Wed, 21 Jun 2017 14:01:20 +0000 Message-ID: <64f81596f01d41c8b22f3e946ee58cb0@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/mixed; boundary="_004_64f81596f01d41c8b22f3e946ee58cb0XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Join WebEx meeting in progress: LPWAN Interim X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:01:53 -0000 --_004_64f81596f01d41c8b22f3e946ee58cb0XCHRCD001ciscocom_ Content-Type: multipart/alternative; boundary="_000_64f81596f01d41c8b22f3e946ee58cb0XCHRCD001ciscocom_" --_000_64f81596f01d41c8b22f3e946ee58cb0XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsOiB0aGUgTFBXQU4gV2ViZXggaGFkIHRvIGJlIGNoYW5nZWQgZHVlIHRvIGhhY2tlcnMgc3Rl YWxpbmcgdGhlIHNsb3QuDQoNClBsZWFzZSBmaW5kIHRoZSBuZXcgaW5mb3JtYXRpb24gYmVsb3c6 DQoNCg0KDQpIZWxsbywNCg0KTXkgV2ViRXggbWVldGluZyBpcyBpbiBwcm9ncmVzcy4NCg0KDQoN Cg0KDQpMUFdBTiBJbnRlcmltDQoNCldlZG5lc2RheSAyMSBKdW5lIDIwMTcNCg0KMTU6NTQgIHwg IEV1cm9wZSBTdW1tZXIgVGltZSAoUGFyaXMsIEdNVCswMjowMCkgIHwgIDEgaHINCg0KDQpNZWV0 aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAyMDMgMjY4IDQzMg0KDQoNCk1lZXRpbmcgcGFzc3dv cmQ6IEFEcHRadW45ICgyMzc4OTg2OSBmcm9tIHBob25lcykNCg0KDQoNCg0KDQpKb2luIE1lZXRp bmc8aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9lLnBocD9NVElEPW0xZmY4OTM3 YWM4YjMxMmY3MDViNDQ1NzQ3YWFmZjY4Nz4NCg0KDQoNCg0KDQoNCg0KDQoNCkpvaW4gZnJvbSBh IHZpZGVvIHN5c3RlbSBvciBhcHBsaWNhdGlvbg0KDQpEaWFsIDIwMzI2ODQzMkBjaXNjby53ZWJl eC5jb208JTIwc2lwOjIwMzI2ODQzMkBjaXNjby53ZWJleC5jb20+DQoNCkZyb20gdGhlIENpc2Nv IGludGVybmFsIG5ldHdvcmssIGRpYWwgKjI2NyogYW5kIHRoZSA5LWRpZ2l0IG1lZXRpbmcgbnVt YmVyLiBJZiB5b3UgYXJlIHRoZSBob3N0LCBlbnRlciB5b3VyIFBJTiB3aGVuIHByb21wdGVkLg0K DQoNCg0KDQpKb2luIGJ5IHBob25lDQoNCisxLTg2Ni00MzItOTkwMyBDYWxsLWluIHRvbGwtZnJl ZSBudW1iZXIgKFVTL0NhbmFkYSkNCg0KKzEtNDA4LTUyNS02ODAwIENhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSkNCg0KR2xvYmFsIGNhbGwtaW4gbnVtYmVyczxodHRwczovL2Npc2NvLndl YmV4LmNvbS9jaXNjb3NhbGVzL2dsb2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9TUMmRUQ9Mzkx MTQ1MjAyJnRvbGxGcmVlPTE+ICB8ICBUb2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8aHR0 cHM6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmPg0KDQoNCg0K DQoNCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IDxodHRwczovL2hlbHAud2ViZXguY29tL2RvY3Mv RE9DLTU0MTI+DQoNCg0KDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0 aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50 IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVy YWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRv bWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNl bnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0 IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLg0KDQoNCg0KDQo= --_000_64f81596f01d41c8b22f3e946ee58cb0XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJB cmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjojNjY2NjY2Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzY2NjY2NjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiM2 NjY2NjYiIHZsaW5rPSIjNjY2NjY2Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFsbDogdGhlPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5MUFdBTjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQiPg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2ViZXggaGFkIHRvIGJlIGNoYW5n ZWQgZHVlIHRvIGhhY2tlcnMgc3RlYWxpbmcgdGhlIHNsb3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBmaW5kIHRoZSBuZXcgaW5mb3JtYXRpb24gYmVsb3c6 PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2Vs bHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjEwMCUiIHN0 eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjMu NzVwdCAwY20gMGNtIDBjbSI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSIx MTgxIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQ7bWFyZ2luLWxlZnQ6My43NXB0Ij4NCjx0Ym9keT4N Cjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUi IGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJv ZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7 bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzY2NjY2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEu MHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTE4 MSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6 MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj5IZWxsbywNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjcuNXB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNh bDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+TXkgV2ViRXgg bWVldGluZyBpcyBpbiBwcm9ncmVzcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpu b25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9 IjExODEiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdo dDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNv LWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2 NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5n PSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQiPkxQV0FOIEludGVy aW08L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM0RDRENEQiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzY2NjY2NiI+V2VkbmVzZGF5IDIxIEp1bmUgMjAxNw0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+MTU6NTQmbmJzcDsmbmJzcDt8Jm5ic3A7 Jm5ic3A7RXVyb3BlIFN1bW1lciBUaW1lIChQYXJpcywgR01UJiM0MzswMjowMCkmbmJzcDsmbmJz cDt8Jm5ic3A7Jm5ic3A7MSBocg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEu MHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIg c3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2 NiI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMjAzIDI2OCA0MzINCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI1IiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBv cnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1l bGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13 cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPk1lZXRpbmcgcGFzc3dvcmQ6IEFEcHRadW45ICgy Mzc4OTg2OSBmcm9tIHBob25lcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0O2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NjY2NjY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lk dGg9IjExODEiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9Imhl aWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6 MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50 LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6 Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2 NjY2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSIwIiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1wb3J0YW50Ij4NCjx0Ym9keT4NCjx0 cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207d2lkdGg6YXV0byFpbXBvcnRh bnQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxsc3BhY2lu Zz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO2JhY2tncm91 bmQ6IzQzQTk0Mjtib3JkZXI6c29saWQgIzQzQTk0MiAxLjVwdDt3aWR0aDphdXRvIWltcG9ydGFu dCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MTAuNXB0 IDE1LjBwdCAxMC41cHQgMTUuMHB0O3dpZHRoOmF1dG8haW1wb3J0YW50O21pbi13aWR0aDogMTg2 cHghaW1wb3J0YW50Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJ0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7 bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzY2NjY2NiI+PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxl cy9lLnBocD9NVElEPW0xZmY4OTM3YWM4YjMxMmY3MDViNDQ1NzQ3YWFmZjY4NyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Y29sb3I6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkpv aW4gTWVldGluZzwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY207d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxU YWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIw IiBzdHlsZT0id2lkdGg6MGNtO3dpZHRoOmF1dG8haW1wb3J0YW50O21pbi13aWR0aDoxODZweCFp bXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbTt3aWR0aDphdXRvIWltcG9ydGFudDttaW4td2lkdGg6MTg2cHghaW1wb3J0YW50Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFi bGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1l bGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13 cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl bGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjExODEiIHN0eWxlPSJ3aWR0aDoz OTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVs ZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv cmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTE4MSIgc3R5 bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFw cGxpY2F0aW9uPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5EaWFsIDxhIGhyZWY9IiUyMHNpcDoyMDMyNjg0MzJAY2lz Y28ud2ViZXguY29tIj4NCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3Jh dGlvbjpub25lIj4yMDMyNjg0MzJAY2lzY28ud2ViZXguY29tPC9zcGFuPjwvYj48L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6 MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+RnJvbSB0aGUgQ2lzY28g aW50ZXJuYWwgbmV0d29yaywgZGlhbCAqMjY3KiBhbmQgdGhlIDktZGlnaXQgbWVldGluZyBudW1i ZXIuIElmIHlvdSBhcmUgdGhlIGhvc3QsIGVudGVyIHlvdXIgUElOIHdoZW4gcHJvbXB0ZWQuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6 MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2lu Zz0iNSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMTgxIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQi Pg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NjY2NjY2Ij5Kb2luIGJ5IHBob25lPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mIzQzOzEtODY2LTQzMi05OTAz PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwO0NhbGwtaW4gdG9s bC1mcmVlIG51bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM2NjY2NjYiPiYjNDM7MS00MDgtNTI1LTY4MDA8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9 Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvZ2xvYmFsY2FsbGluLnBocD9zZXJ2 aWNlVHlwZT1NQyZhbXA7RUQ9MzkxMTQ1MjAyJmFtcDt0b2xsRnJlZT0xIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5HbG9i YWwgY2FsbC1pbg0KIG51bWJlcnM8L3NwYW4+PC9hPiZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDs8 YSBocmVmPSJodHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5w ZGYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMwMEFGRjk7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvc3Bhbj48L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNp bmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTE4MSIgc3R5bGU9IndpZHRoOjM5My43NXB0 Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDtt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxsc3BhY2luZz0iNSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMTgxIiBzdHlsZT0id2lk dGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9Imh0dHBzOi8vaGVscC53 ZWJleC5jb20vZG9jcy9ET0MtNTQxMiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/DQo8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZy YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjExODEiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+ DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo3LjVwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6 MGNtIDBjbSAwY20gMGNtO2hlaWdodDo3LjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDo3LjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2 NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxsc3BhY2luZz0iNSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMTgxIiBzdHlsZT0i d2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0EwQTBBMCI+SU1QT1JUQU5UIE5PVElDRTogUGxl YXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBp bmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2gg bWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZw0KIHRoaXMg c2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElm IHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNl cm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3Ry Pg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_64f81596f01d41c8b22f3e946ee58cb0XCHRCD001ciscocom_-- --_004_64f81596f01d41c8b22f3e946ee58cb0XCHRCD001ciscocom_ Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=4738; creation-date="Wed, 21 Jun 2017 13:55:00 GMT"; modification-date="Wed, 21 Jun 2017 13:55:00 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTUxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE1MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iUGFzY2FsIFRodWJl cnQiO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86cHRodWJlcnRAY2lzY28u Y29tCk9SR0FOSVpFUjtDTj0iUGFzY2FsIFRodWJlcnQiOk1BSUxUTzpwdGh1YmVydEBjaXNjby5j b20KRFRTVEFSVDtUWklEPSJFdXJvcGUgVGltZSI6MjAxNzA2MjFUMTU1NDU4CkRURU5EO1RaSUQ9 IkV1cm9wZSBUaW1lIjoyMDE3MDYyMVQxNjU0NTgKTE9DQVRJT046aHR0cHM6Ly9jaXNjby53ZWJl eC5jb20vY2lzY29zYWxlcwpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjE0OTgwNTMyOTgKVUlEOjMx YzY1YmE2LWY3MTctNDk5OS1hODk4LTA5NDg4ZWYwM2I3NgpEVFNUQU1QOjIwMTcwNjIxVDEzNTQ1 OFoKREVTQ1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vY2lzY28u d2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/TVRJRD1tZWVkYmI4MDFkYTM1Mzk3NjIyZjZmZTIz MzVmYWUxY2Fcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDIwMyAyNjggNDMyXG5NZWV0 aW5nIHBhc3N3b3JkOiBBRHB0WnVuOSAoMjM3ODk4NjkgZnJvbSBwaG9uZXMpXG5cblxuXG5KT0lO IEZST00gQSBWSURFTyBTWVNURU0gT1IgQVBQTElDQVRJT05cbkRpYWwgc2lwOjIwMzI2ODQzMkBj aXNjby53ZWJleC5jb21cbkZyb20gdGhlIENpc2NvIGludGVybmFsIG5ldHdvcmssIGRpYWwgKjI2 NyogYW5kIHRoZSA5LWRpZ2l0IG1lZXRpbmcgbnVtYmVyLiAgSWYgeW91IGFyZSB0aGUgaG9zdCwg ZW50ZXIgeW91ciBQSU4gd2hlbiBwcm9tcHRlZC4gIFxuXG5cbkpPSU4gQlkgUEhPTkVcbisxLTg2 Ni00MzItOTkwMyBDYWxsLWluIHRvbGwtZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgXG4rMS00MDgt NTI1LTY4MDAgQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuXG5HbG9iYWwgY2FsbC1p biBudW1iZXJzOlxuaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9nbG9iYWxjYWxs aW4ucGhwP3NlcnZpY2VUeXBlPU1DJkVEPTM5MTE0NTIwMiZ0b2xsRnJlZT0xXG5cblRvbGwtZnJl ZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogXG5odHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxm cmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRw czovL2hlbHAud2ViZXguY29tL2RvY3MvRE9DLTU0MTJcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQ bGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVy IGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGlj aCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMg c2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElm IHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNl cm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVT QztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxC Uj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj4JCTxhIGhy ZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/TVRJRD1tZWVkYmI4 MDFkYTM1Mzk3NjIyZjZmZTIzMzVmYWUxY2EiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5 IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9GT05UPjwvYT4JCQk8dGFibGU+CQkJ CTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDIwMyAyNjggNDMyPC9GT05UPgkJ CQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCQkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZP TlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+ QURwdFp1bjkgKDIzNzg5ODY5IGZyb20gcGhvbmVzKTwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4J CTwvRk9OVD48YnI+PEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAiPjwvRk9OVD48YnI+PEZP TlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPjxGT05U IFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVvIHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvRk9OVD48 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05U PiA8YSBocmVmPSJzaXA6MjAzMjY4NDMyQGNpc2NvLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIg Q09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFsIj4yMDMyNjg0MzJAY2lzY28ud2ViZXguY29tPC9G T05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+RnJvbSB0aGUgQ2lzY28gaW50ZXJuYWwgbmV0d29yaywgZGlhbCAqMjY3KiBhbmQgdGhl IDktZGlnaXQgbWVldGluZyBudW1iZXIuICBJZiB5b3UgYXJlIHRoZSBob3N0LCBlbnRlciB5b3Vy IFBJTiB3aGVuIHByb21wdGVkLiAgPC9GT05UPiAmbmJzcDsgPEJSPjwvRk9OVD4mbmJzcDsgPEJS PiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJS PjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4rMS04 NjYtNDMyLTk5MDM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwtZnJlZSBudW1iZXIgKFVTL0Nh bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPjxzdHJvbmc+KzEtNDA4LTUyNS02ODAwPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0 b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxhIGhyZWY9Imh0dHBzOi8v Y2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvZ2xvYmFsY2FsbGluLnBocD9zZXJ2aWNlVHlwZT1N QyZFRD0zOTExNDUyMDImdG9sbEZyZWU9MSI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9ImFyaWFsIj5HbG9iYWwgY2FsbC1pbiBudW1iZXJzPC9GT05UPjwvYT48Rk9OVCBTSVpF PSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzwvRk9OVD48YSBocmVm PSJodHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxG T05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9sbC1mcmVlIGNhbGxp bmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+PEJSPjxCUj4JJm5i c3A7PEJSPgk8YSBocmVmPSJodHRwczovL2hlbHAud2ViZXguY29tL2RvY3MvRE9DLTU0MTIiPgk8 Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwiPkNhbid0IGpvaW4gdGhl IG1lZXRpbmc/PC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0iI0Ew QTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3Rl IHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRp b24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBk aXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5 b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5v dCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0 aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZPTlQ+PC9GT05UPgpTVU1NQVJZ OkxQV0FOIEludGVyaW0KUFJJT1JJVFk6NQpDTEFTUzpQVUJMSUMKRU5EOlZFVkVOVApFTkQ6VkNB TEVOREFSCg== --_004_64f81596f01d41c8b22f3e946ee58cb0XCHRCD001ciscocom_-- From nobody Wed Jun 21 07:54:30 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3465B12EB3A for ; Wed, 21 Jun 2017 07:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, 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 5TH2BlVUelp6 for ; Wed, 21 Jun 2017 07:54:26 -0700 (PDT) Received: from smtp-6-48.vip.sina.com.cn (r3-66.sinamail.sina.com.cn [202.108.3.66]) by ietfa.amsl.com (Postfix) with SMTP id 7461312EABA for ; Wed, 21 Jun 2017 07:51:57 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([221.222.221.189]) by vip.sina.com with ESMTP 21 Jun 2017 22:51:52 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 67629066439 Message-ID: <1C1F6BA607D54CE2AE61A0CDA5F6E0B2@WeiGengyuPC> From: "weigengyu" To: "Carles Gomez Montenegro" Cc: "lp-wan" , "Arun" , "Ana Minaburo" , "Laurent Toutain" References: <386f3ac3-cc15-3fe7-8a7e-04d5be66c0ce@ackl.io> <331F64BD15B741A986014F6C1AA51C75@WeiGengyuPC> In-Reply-To: Date: Wed, 21 Jun 2017 22:51:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:54:29 -0000 Hi, > Note that not all IPv6 packets will require fragmentation, > and then losses may happen, > also non-fragmented packets may be interleaved with fragments, etc. It seems that there may not apply two rules for one IP packets. Or all fragments belonged to one pakcet should have the same Rule ID and the Dtag. If one fragment is lost, the packet can not be assembled. The packet will be assembled only after all fragments received correctly. Fragments belonged to different packets will be assigned with different Dtags. Anything wrong? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carles Gomez Montenegro Sent: Wednesday, June 21, 2017 2:13 PM To: weigengyu Cc: lp-wan ; Arun ; Ana Minaburo ; Laurent Toutain Subject: Re: [lp-wan] re-order header field request Hi Gengyu, > Why each successive fragment must contain a Rule ID? > It is known that the DTag is used as an indication of fragments belonged > to > the same IPv6 packet. > A Rule ID in the first fragement can be passed to the receiver how to do > HC > compression, > but the successive fragments containing a Rule ID just send a redundent > information to the receiver. > Right? The Rule ID is needed to provide a receiver with information on what type of content is being carried (and how it has to be handled). Note that not all IPv6 packets will require fragmentation, and then losses may happen, also non-fragmented packets may be interleaved with fragments, etc. Cheers, Carles > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Wed Jun 21 08:16:28 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56486129C6C for ; Wed, 21 Jun 2017 08:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEZVLGkuKIy9 for ; Wed, 21 Jun 2017 08:16:23 -0700 (PDT) Received: from smtp-6-45.vip.sina.com.cn (r3-68.sinamail.sina.com.cn [202.108.3.68]) by ietfa.amsl.com (Postfix) with SMTP id 9D45612EB36 for ; Wed, 21 Jun 2017 08:11:31 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([221.219.54.237]) by vip.sina.com with ESMTP 21 Jun 2017 23:10:54 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 220945221785 Message-ID: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> From: "weigengyu" To: "Carles Gomez Montenegro" Cc: Date: Wed, 21 Jun 2017 23:10:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 15:16:26 -0000 Hi Carles, Suppose that one packet is partitioned into two fragments. Because the Dtag indicates two fragments belonged to one packet, the Rule ID in the second fragment is repeated, or redundent, isn't it? If the Rule ID is not exist in the second fragment, the receiver can process it according to the Dtag which is the same in two fragments. Is there any confusions at the receiver side? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carles Gomez Montenegro Sent: Wednesday, June 21, 2017 2:07 PM To: weigengyu Subject: Re: [lp-wan] Fw: re-order header field request Hi Gengyu, > Why each successive fragment must contain a Rule ID? > It is known that the DTag is used as an indication of fragments belonged > to > the same IPv6 packet. > A Rule ID in the first fragement can be passed to the receiver how to do > HC > compression, > but the successive fragments containing a Rule ID just send a redundent > information to the receiver. > Right? The Rule ID is needed to provide a receiver with information on what type of content is being carried (and how it has to be handled). Note that not all IPv6 packets will require fragmentation, and then losses may happen, also non-fragmented packets may be interleaved with fragments, etc. Cheers, Carles > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications From nobody Wed Jun 21 08:53:58 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592F812EBCC for ; Wed, 21 Jun 2017 08:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 L5j0LMpoPrNl for ; Wed, 21 Jun 2017 08:53:52 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C10312E037 for ; Wed, 21 Jun 2017 08:53:06 -0700 (PDT) Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 0F2BBC5A85 for ; Wed, 21 Jun 2017 17:53:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Md4seHosw4f1 for ; Wed, 21 Jun 2017 17:52:33 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.157] (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: arun@acklio.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 7AA57C5A97 for ; Wed, 21 Jun 2017 17:52:33 +0200 (CEST) To: lp-wan@ietf.org References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> From: Arun Message-ID: <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> Date: Wed, 21 Jun 2017 17:52:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kpf1JMrxN9qeKRLAeNTX7i1fq7alD6N5U" Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 15:53:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kpf1JMrxN9qeKRLAeNTX7i1fq7alD6N5U Content-Type: multipart/mixed; boundary="Q8cnav81MfeWGEuJ3lsgFU8HTh8l1XpBf"; protected-headers="v1" From: Arun To: lp-wan@ietf.org Message-ID: <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> Subject: Re: [lp-wan] Fw: re-order header field request References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> In-Reply-To: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> --Q8cnav81MfeWGEuJ3lsgFU8HTh8l1XpBf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Gengyu, The flow shall be; BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment. In such cases, RuleID serves the purpose to identify if the incoming packet is a fragmented packet or if it's just came out of SCHC. If we are sure that all the packets received will be fragmented then it makes sense to send ruleID at the beginning. hope that helps, Arun On 21/06/2017 17:10, weigengyu wrote: > > > > Hi Carles, > > Suppose that one packet is partitioned into two fragments. > > Because the Dtag indicates two fragments belonged to one packet, > the Rule ID in the second fragment is repeated, or redundent, isn't it?= > > If the Rule ID is not exist in the second fragment, > the receiver can process it according to the Dtag which is the same in > two fragments. > Is there any confusions at the receiver side? > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carles Gomez Monte= negro > Sent: Wednesday, June 21, 2017 2:07 PM > To: weigengyu > Subject: Re: [lp-wan] Fw: re-order header field request > > > Hi Gengyu, > >> Why each successive fragment must contain a Rule ID? >> It is known that the DTag is used as an indication of fragments belong= ed >> to >> the same IPv6 packet. >> A Rule ID in the first fragement can be passed to the receiver how to = do >> HC >> compression, >> but the successive fragments containing a Rule ID just send a redunden= t >> information to the receiver. >> Right? > > The Rule ID is needed to provide a receiver with information on what ty= pe > of content is being carried (and how it has to be handled). Note that n= ot > all IPv6 packets will require fragmentation, and then losses may happen= , > also non-fragmented packets may be interleaved with fragments, etc. > > Cheers, > > Carles > > >> Regards, >> >> Gengyu WEI >> Network Technology Center >> School of Computer >> Beijing University of Posts and Telecommunications > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --Q8cnav81MfeWGEuJ3lsgFU8HTh8l1XpBf-- --kpf1JMrxN9qeKRLAeNTX7i1fq7alD6N5U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZSpY+AAoJENe8HNMjzJQRl2cP/iNc7HNq9poJBlae2vtLTOgK NUbiMq9QTi8pCx7InWwAG3ApuBZfTgnRqgOgyXzYhDt014NrrxiI+zJV7otRTwsB FuQgSYIpKIANjkl0kbk+CS2VgpUyWNMvpfKWZC8As1Ib5guYrqKe53qHQBNjRLNz kCwv3VJ41nXGozDD1HBUcR2l3xb74o4kByyRsNt+nWxMGmAOhhezrfhfJL7Y6CzH ylS9Tu1cfde0pgDbEXgdBdz699cTyhf64bhdXXnAEauEJty3fU0PcG/WG1vMA5ub i9J4f+Mo+WHL0S6PYOZypK0tDDHVhk2DUnatzY0e6R123Poa6To4yXhkB26u18PX RFpveV2aq8ev16SXlkAEjktsmQIR+AIqoo8stG3NjuuCWWCVPK30e8LMQeQYe1wo rdrMCnY+TXPdHeXP4d98799vAtuvK8bCYy8KTp+AcGhpb0oK+fXTPAqYysVizgxP W9tVMpA06V5PSXv3aWiCkp/uvgUw6GOaB4EdDsGmNUcn/xHGT9/j26H+65c+6xDg wplfCWJ8/br3aF5xWGMt98uUBJRK5tD+QqbpLuEmLBjstX5fRMdVY660LfZUid7C +RdXIOvzkZ9rBMVqs04vbSZ5Mr89WIQHc8XeiFsLJwihYh0gFBdOckiDd8jfUHmI UegS/61XdhTYyXXO/U7Y =nDj9 -----END PGP SIGNATURE----- --kpf1JMrxN9qeKRLAeNTX7i1fq7alD6N5U-- From nobody Wed Jun 21 09:31:45 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00AB1286B1 for ; Wed, 21 Jun 2017 09:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 LBKQoVp_0P7f for ; Wed, 21 Jun 2017 09:31:40 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00112.outbound.protection.outlook.com [40.107.0.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954DD127909 for ; Wed, 21 Jun 2017 09:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4bFvDkzK1UW7F9NmHCfNCpx4kFxavN6KhAsukMIah3w=; b=JxzWIPKsVSrAcwXw/8WaoIViE5xWyNcmEPIBaNRn45cwlXv94sHQx3bvBkFtyUoM010PRj9qcyakLBXi6K9mSMT20CkjHxVuuVqqnq6FHVQNRIObK6+zN3L2ZUbZ593DeV+erzdocO4rEq24980t2yuNiyORLe8PXYSwlb48EBc= Received: from VI1PR08MB2688.eurprd08.prod.outlook.com (10.175.245.26) by VI1PR08MB2685.eurprd08.prod.outlook.com (10.175.245.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Wed, 21 Jun 2017 16:31:36 +0000 Received: from VI1PR08MB2688.eurprd08.prod.outlook.com ([fe80::7100:bfd4:aee2:c3d]) by VI1PR08MB2688.eurprd08.prod.outlook.com ([fe80::7100:bfd4:aee2:c3d%13]) with mapi id 15.01.1178.018; Wed, 21 Jun 2017 16:31:36 +0000 From: Juan Carlos Zuniga To: Ana Minaburo , lp-wan CC: "Pascal Thubert (pthubert)" , Alexander Pelov Thread-Topic: [lp-wan] New version of draft SCHC compression and fragmentation Thread-Index: AQHS5non7blMfBAWjUerdZU/y7U1S6IvfMcQ Date: Wed, 21 Jun 2017 16:31:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ackl.io; dkim=none (message not signed) header.d=none;ackl.io; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [198.58.159.155] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR08MB2685; 7:tUXvjbbI3+mbNhUNRZ3H/FwBhRRch2rDOTlGNFuzmshLy/38fXZdAw4rBgSUJtCHywIKFVEHxwPeLLsIXiWvpfRBRzRYpigudpD5opNPPOqjGdESahuGVgmkAslBX2rfif/zJUYc0Cue5reHrhdhWMf/UOvNzMV/QXhWVxAUXB73aVBe4JPIu9N2SaE2Up5tw9sVJgs1bPzxinWtMqq2a4NxsW3d0iD7E5Ocwtk5gOaH8YV6pEVyVccPLChxlxQwPFZhsPHjy6FG0B+JM+5CK/a1ld1Ut8cx8mKMt96jzX05GgjPOyq6UavLGJm/EsY0kDMoeFzPXH2u07JbkJ6MgLAS5kDKt/8p6tYs/woxsx+baLdZyi3MfUa5BOMTMJvN0wp4eNMsvKixzYgCnrOSh7dawFOEcwPUOb5sPT15fDrPk/n3pbdkgk5dmy56s6N6NLr0Y4aHhfUQXH7ZOWecP7KcUNHMq8ZAVdi9j5Qzj+Rp9OxKjuTPRnIiGYOIxv1Xpw9/SP1ARNCeimr5q5K/07dRe/yMpBiHOPwCDgm2ssWuj18p7bwb4T5pkR/MaltpiE8UFTSWo3hHPXd3RoaiQBxAbs5vlAJTGrVk4F4fQMELdf20utWL8lLUiUSjTOOi991tXiLJCDm6TI8vt72QbtcelXFBC6qucACQC6n8nCjICm5tRpnplwHcuzxpB59Hppw9PJ/CJtwXD7cGiY+o9uPMFMiIm+ujYKT1U9qMZTfFgs1QqBx9PAfUhUJQbyML6RRXvT9DvKUpIy43Sdi0VuQiGTcrvPeCO1xghdZFbBA= x-ms-office365-filtering-correlation-id: 719aefc2-1956-42dc-dd96-08d4b8c2fc70 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR08MB2685; x-ms-traffictypediagnostic: VI1PR08MB2685: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR08MB2685; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR08MB2685; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39400400002)(39450400003)(39830400002)(377454003)(86362001)(6436002)(38730400002)(8676002)(4326008)(74316002)(3660700001)(6306002)(50986999)(33656002)(55016002)(99286003)(3280700002)(54356999)(25786009)(54896002)(7696004)(54906002)(53546010)(236005)(9686003)(6506006)(7906003)(53936002)(5250100002)(76176999)(2950100002)(81166006)(2900100001)(478600001)(7736002)(966005)(102836003)(66066001)(8936002)(3846002)(790700001)(6116002)(6246003)(2906002)(606005)(189998001)(5660300001)(229853002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR08MB2685; H:VI1PR08MB2688.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR08MB268817A4AFE8730CF5CB79FC89DA0VI1PR08MB2688eurp_" MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 16:31:36.3566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2685 Archived-At: Subject: Re: [lp-wan] New version of draft SCHC compression and fragmentation X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:31:44 -0000 --_000_VI1PR08MB268817A4AFE8730CF5CB79FC89DA0VI1PR08MB2688eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ana, all, Thanks for addressing the previous comments in this new version. As mentioned during the call, I have some new minor comments in preparation= for the WGLC: 6.2. value-sent CDA The value-sent action is generally used when the field value is not known by both Compressor and Decompressor. The value is sent in the compressed message header. Both Compressor and Decompressor must know the size of the field, either implicitly (the size is known by both sides) or explicitly in the compressed header field by indicating the length. This function is generally used with the "ignore" MO. The compressor sends the Target Value stored on the rule in the compressed header message. The decompressor restores the field value with the one received from the LPWAN I believe the second paragraph (starting from "The compressor...") is not n= eeded, as the "actual field value" should be sent, and not the TV. Right? T= he two paragraphs seems to be contradictory. 6.5. DEViid, APPiid CDA These functions are used to process respectively the Dev and the App Interface Identifiers (Deviid and Appiid) of the IPv6 addresses. Appiid CDA is less common, since current LPWAN technologies frames contain a single address. The IID value can be computed from the Device ID present in the Layer 2 header. The computation is specific for each LPWAN technology and depends on the Device ID size. In the downstream direction, these CDA are used to determine the L2 addresses used by the LPWAN. I would suggest changing the last sentences as: "The computation is specifi= c for each LPWAN technology and may depend on the Device ID size. In the downstream direction, these CDA may be used to determine the L2 addr= esses used by the LPWAN." 7.7.2. IPv6 source and destination IID If the DEV or APP IID are based on an LPWAN address, then the IID can be reconstructed with information coming from the LPWAN header. In that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "DEViid" or "APPiid". Note that the LPWAN technology is generally carrying a single device identifier corresponding to the DEV. The SCHC C/D may also not be aware of these values. If the DEV address has a static value that is not derivated from the EUI-64, then TV contains the value, the MO operator is set to "equal" and the CDA is set to "not-sent". Since not all technologies use EUI-64 (e.g. NB-IoT, Sigfox) I would suggest= changing the last paragraph as follows: "If the DEV address has a static v= alue that is not derived from an IEEE EUI-64, then TV contains the actual D= EV address value, the MO operator is set to "equal" and the CDA is set to "= not-sent"." Best, Juan Carlos From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Ana Minaburo Sent: June 16, 2017 4:25 AM To: lp-wan Cc: Pascal Thubert (pthubert) ; Alexander Pelov Subject: [lp-wan] New version of draft SCHC compression and fragmentation Hello LPWANers, I hope you are all fine! I want to announce that we have published a new version of the draft SCHC c= ompression and fragmentation. We would like to receive your comments and= questions. Thanks Ana _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan --_000_VI1PR08MB268817A4AFE8730CF5CB79FC89DA0VI1PR08MB2688eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ana, all,<= /span>

 =

Thanks for addressing th= e previous comments in this new version.

 =

As mentioned during the = call, I have some new minor comments in preparation for the WGLC:

 =

6.2. value-sent CDA

The value-sent action is general= ly used when the field value is not

known by both Compressor and Dec= ompressor. The value is sent in the

compressed message header. Both = Compressor and Decompressor must

know the size of the field, eith= er implicitly (the size is known by

both sides) or explicitly in the= compressed header field by

indicating the length. This func= tion is generally used with the

"ignore" MO.

The compressor sends the Target = Value stored on the rule in the

compressed header message. The d= ecompressor restores the field value

with the one received from the LPWAN

 

I believe the second par= agraph (starting from “The compressor…”) is not needed, a= s the “actual field value” should be sent, and not the TV. Righ= t? The two paragraphs seems to be contradictory.

 =

6.5. DEViid, APPiid CDA

These functions are used to proc= ess respectively the Dev and the App

Interface Identifiers (Deviid an= d Appiid) of the IPv6 addresses.

Appiid CDA is less common, since= current LPWAN technologies frames

contain a single address.

The IID value can be computed fr= om the Device ID present in the Layer

2 header. The computation is spe= cific for each LPWAN technology and

depends on the Device ID size.

In the downstream direction, the= se CDA are used to determine the L2

addresses used by the LPWAN.

 =

I would suggest changing the last sentences as: “The computation is specific for each LPWAN technology and may depend on = the Device ID size.

In the downstream direction, the= se CDA may b= e used to de= termine the L2 addresses used by the LPWAN.”

 

7.7.2. IPv6 source and destination I= ID

If the DEV or APP IID are based = on an LPWAN address, then the IID can

be reconstructed with informatio= n coming from the LPWAN header. In

that case, the TV is not set, th= e MO is set to "ignore" and the CDA

is set to "DEViid" or = "APPiid". Note that the LPWAN technology is

generally carrying a single devi= ce identifier corresponding to the

DEV. The SCHC C/D may also not b= e aware of these values.

If the DEV address has a static = value that is not derivated from the

EUI-64, then TV contains the val= ue, the MO operator is set to "equal"

and the CDA is set to "not-= sent".

 

Since not all technologies use EUI-64 (e.g. NB-IoT, Sigfox) I would s= uggest changing the last paragraph as follows: “If the DEV address has a static value that is not derived from an IEEE EUI-64, the= n TV contains the actual DEV address value, the MO operator is set to "equal" and the CDA is set to "no= t-sent".”

 

Best,

 

Juan Carlos

 

 =

From: = lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of Ana Minaburo
Sent: June 16, 2017 4:25 AM
To: lp-wan <lp-wan@ietf.org>
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; Alexander = Pelov <a@ackl.io>
Subject: [lp-wan] New version of draft SCHC compression and fragment= ation

 



Hello LPWANers,

I hope you are all fine!

I want to announce that we have published a new version of the draft SCHC c= ompression    and fragmentation. We would like to receive yo= ur comments and questions.

Thanks
Ana


 

___________________= ____________________________
lp-wan mailing list
= lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

--_000_VI1PR08MB268817A4AFE8730CF5CB79FC89DA0VI1PR08MB2688eurp_-- From nobody Wed Jun 21 09:42:30 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD667127977 for ; Wed, 21 Jun 2017 09:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 XJffqUxvZUeq for ; Wed, 21 Jun 2017 09:42:27 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0127.outbound.protection.outlook.com [104.47.2.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457E91270AC for ; Wed, 21 Jun 2017 09:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tSsXc7xkBFUJLRMdbv+7f993tSceysaGaTkHjp9fO88=; b=qIh3NyQGwkkJVjDTkxMRjg3Kr8Gj3/2Q7rQL6eCfyc/zPFfeuWBVHhxAX8u6BylqrGyOOltvcRPZ7sijwhb+Cga49WPy6+tuHCiHmVAziFJIBnIXRoz2f9vpMuBn36j3cyfscVX6RjrDeTFsVl483/d4aUzDoD7K5ZbV/KjiSN4= Received: from VI1PR08MB2688.eurprd08.prod.outlook.com (10.175.245.26) by VI1PR08MB2687.eurprd08.prod.outlook.com (10.175.245.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Wed, 21 Jun 2017 16:42:24 +0000 Received: from VI1PR08MB2688.eurprd08.prod.outlook.com ([fe80::7100:bfd4:aee2:c3d]) by VI1PR08MB2688.eurprd08.prod.outlook.com ([fe80::7100:bfd4:aee2:c3d%13]) with mapi id 15.01.1178.018; Wed, 21 Jun 2017 16:42:24 +0000 From: Juan Carlos Zuniga To: Laurent Toutain CC: lp-wan Thread-Topic: SCHC - To pad or not to pad Thread-Index: AdLqrHjb0rgKSR1ERzq0v9X1Gn0iUQ== Date: Wed, 21 Jun 2017 16:42:24 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: imt-atlantique.fr; dkim=none (message not signed) header.d=none;imt-atlantique.fr; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [198.58.159.155] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR08MB2687; 7:05upHay60MjnXHTkTlqJ+VRSS0uTQGIAaMb/LKD1LLxB31lDcReOuiSOGsLK77KyktUCoWdLMfuGJCnRKJjYgkrhD+Ih90m6EQAZ4NP1e7Bv5B5F/TUPj59S8JwyBCRRN8I5mc3G650SraOrNlBPj3n2+Xbohv33Z39FqcfMo9Q9wwfMdVOtc1+3IA1uN8rdmDvOsgglIKtcZr5D6taVRuvcVYVE8vu5v8iUTubFfz94Mxk1qnL0/GoPGn68cj6a3B2WXl51cqxwyVMZaBC2e2d8w5DsODByFZncTBW/0cUz84fEHURzwXIEsDY/2wTnItS8eoaBeoVDHVlYqsgD4GEYbXtRL/AcDvZc38cdSaHW11sQyUJqkjn55cbcMon2xcY6c3LdyIzvWZMi2Lx8XF8W8sH4bYcZjcmsryYKLVajev09fuC1hJqwPthB4OOOSNdJJSIvv23lFC9NXcHx7PUZbrAMdPHYpqgGUpfU2sJOqI8OJmyiIJODREHH5Hl6j1EwVOHKa0dm9ZFGuegxUcmryjrS7FmDsOHG7iMqiMCae2s+EiqbP4GUU70coyWmh0BVp9gaszDZ+P7jjqvFszLfrnaoCBIoWownUVVIH/Lh55+WWIxXqXNiKkjUrdBlOaKAMf0O+l8u204vJDjIIxgJrQXqiqYQWFNj03Cvm5XbrpwpRXLQIQQqMkezgpEwwVzo99ddy0p+7DQxkW0V242nEZlH6xTwAxa+LOjGGbUSGDsuin6KvvA4L1ng+AUVWDcQcWit2zVX5oCvuUiEkZXJxwiRFomSss3gyhZvtSA= x-ms-office365-filtering-correlation-id: e990ccdf-792b-41f8-95ec-08d4b8c47ed7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR08MB2687; x-ms-traffictypediagnostic: VI1PR08MB2687: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR08MB2687; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR08MB2687; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39410400002)(39830400002)(6916009)(7736002)(8936002)(4326008)(9326002)(6306002)(55016002)(66066001)(54896002)(53936002)(74316002)(9686003)(99286003)(6436002)(14454004)(5250100002)(3660700001)(8676002)(86362001)(478600001)(7696004)(189998001)(81166006)(5660300001)(3280700002)(790700001)(2900100001)(25786009)(6116002)(2906002)(6506006)(102836003)(110136004)(38730400002)(50986999)(33656002)(3846002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR08MB2687; H:VI1PR08MB2688.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR08MB2688414BB3821567E326AE8589DA0VI1PR08MB2688eurp_" MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2017 16:42:24.5834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2687 Archived-At: Subject: [lp-wan] SCHC - To pad or not to pad X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:42:29 -0000 --_000_VI1PR08MB2688414BB3821567E326AE8589DA0VI1PR08MB2688eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Laurent, In the call you proposed padding in-between SCHC header and Payload Data. H= owever, seems to me that this would limit the (already small) amount of bit= s available for Data. For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11 bi= ts would be padded up to 16, leaving only 48 available bits for data instea= d of 53. Is my understanding correct? Best, Juan Carlos --_000_VI1PR08MB2688414BB3821567E326AE8589DA0VI1PR08MB2688eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Laurent,

 

In the call you proposed padding in-between SCHC hea= der and Payload Data. However, seems to me that this would limit the (alrea= dy small) amount of bits available for Data.

 

For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11 bits would be padded up to 16, leaving only 4= 8 available bits for data instead of 53.

 

Is my understanding correct?

 

Best,

 

Juan Carlos

 

--_000_VI1PR08MB2688414BB3821567E326AE8589DA0VI1PR08MB2688eurp_-- From nobody Wed Jun 21 10:06:24 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CFD127876 for ; Wed, 21 Jun 2017 10:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, 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 YGCg2FeSVgnv for ; Wed, 21 Jun 2017 10:06:19 -0700 (PDT) Received: from smtp-6-47.vip.sina.com.cn (r3-63.sinamail.sina.com.cn [202.108.3.63]) by ietfa.amsl.com (Postfix) with SMTP id E569D128C82 for ; Wed, 21 Jun 2017 10:06:17 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([221.219.54.237]) by vip.sina.com with ESMTP 22 Jun 2017 01:06:11 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 746985278672 Message-ID: From: "weigengyu" To: , "Arun" References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> In-Reply-To: <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> Date: Thu, 22 Jun 2017 01:06:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 17:06:22 -0000 Hi Arun, > BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment. > In such cases, RuleID serves the purpose to identify if the incoming > packet is a fragmented packet If a packet is fragmented, each fragment contain both Rule ID and Dtag as the draft defined. But, the receiver can know which Rule ID is used by the Dtag in the succesive fragments even in which Rule ID in not existed. > or if it's just came out of SCHC. If a packet is not fragmented, there is a Rule ID as a indication. Is there a Dtag? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Arun Sent: Wednesday, June 21, 2017 11:52 PM To: lp-wan@ietf.org Subject: Re: [lp-wan] Fw: re-order header field request Hi Gengyu, The flow shall be; BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment. In such cases, RuleID serves the purpose to identify if the incoming packet is a fragmented packet or if it's just came out of SCHC. If we are sure that all the packets received will be fragmented then it makes sense to send ruleID at the beginning. hope that helps, Arun On 21/06/2017 17:10, weigengyu wrote: > > > > Hi Carles, > > Suppose that one packet is partitioned into two fragments. > > Because the Dtag indicates two fragments belonged to one packet, > the Rule ID in the second fragment is repeated, or redundent, isn't it? > > If the Rule ID is not exist in the second fragment, > the receiver can process it according to the Dtag which is the same in > two fragments. > Is there any confusions at the receiver side? > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----原始邮件----- From: Carles Gomez Montenegro > Sent: Wednesday, June 21, 2017 2:07 PM > To: weigengyu > Subject: Re: [lp-wan] Fw: re-order header field request > > > Hi Gengyu, > >> Why each successive fragment must contain a Rule ID? >> It is known that the DTag is used as an indication of fragments belonged >> to >> the same IPv6 packet. >> A Rule ID in the first fragement can be passed to the receiver how to do >> HC >> compression, >> but the successive fragments containing a Rule ID just send a redundent >> information to the receiver. >> Right? > > The Rule ID is needed to provide a receiver with information on what type > of content is being carried (and how it has to be handled). Note that not > all IPv6 packets will require fragmentation, and then losses may happen, > also non-fragmented packets may be interleaved with fragments, etc. > > Cheers, > > Carles > > >> Regards, >> >> Gengyu WEI >> Network Technology Center >> School of Computer >> Beijing University of Posts and Telecommunications > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Wed Jun 21 12:27:16 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67221241FC for ; Wed, 21 Jun 2017 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 oSSBrlREfgQL for ; Wed, 21 Jun 2017 12:27:12 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFC8128CDB for ; Wed, 21 Jun 2017 12:27:11 -0700 (PDT) Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 8F99BC5A5C for ; Wed, 21 Jun 2017 21:27:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id l3uCADBBwb0H for ; Wed, 21 Jun 2017 21:27:08 +0200 (CEST) X-Originating-IP: 209.85.223.177 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) (Authenticated sender: arun@acklio.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 81D8AC5A67 for ; Wed, 21 Jun 2017 21:27:06 +0200 (CEST) Received: by mail-io0-f177.google.com with SMTP id t87so9941637ioe.0 for ; Wed, 21 Jun 2017 12:27:06 -0700 (PDT) X-Gm-Message-State: AKS2vOydMxVx6EsuL8lSR0O4HLVlSflg5a7wwYEdQq/PVWIqVQrrZ+NN Z2IE0SdlsSRw55UHZ5W8wRv/PARt0Q== X-Received: by 10.107.173.221 with SMTP id m90mr38309900ioo.152.1498073225755; Wed, 21 Jun 2017 12:27:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.36.6 with HTTP; Wed, 21 Jun 2017 12:27:05 -0700 (PDT) Received: by 10.36.36.6 with HTTP; Wed, 21 Jun 2017 12:27:05 -0700 (PDT) In-Reply-To: References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> From: =?UTF-8?B?4K6F4K6w4K+B4K6j4K+N4K6q4K6/4K6w4K6q4K+BIChhcnVucHJhYmh1KQ==?= Date: Wed, 21 Jun 2017 21:27:05 +0200 X-Gmail-Original-Message-ID: Message-ID: To: weigengyu Cc: lp-wan@ietf.org Content-Type: multipart/alternative; boundary="001a11449aa6780d6305527d5aeb" Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 19:27:16 -0000 --001a11449aa6780d6305527d5aeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gengyu, On Jun 21, 2017 7:06 PM, "weigengyu" wrote: Hi Arun, BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment. > In such cases, RuleID serves the purpose to identify if the incoming > packet is a fragmented packet > If a packet is fragmented, each fragment contain both Rule ID and Dtag as the draft defined. But, the receiver can know which Rule ID is used by the Dtag in the succesive fragments even in which Rule ID in not existed. or if it's just came out of SCHC. > If a packet is not fragmented, there is a Rule ID as a indication. Is there a Dtag? There is no Dtag in this case. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Arun Sent: Wednesday, June 21, 2017 11:52 PM To: lp-wan@ietf.org Subject: Re: [lp-wan] Fw: re-order header field request Hi Gengyu, The flow shall be; BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no fragment. In such cases, RuleID serves the purpose to identify if the incoming packet is a fragmented packet or if it's just came out of SCHC. If we are sure that all the packets received will be fragmented then it makes sense to send ruleID at the beginning. hope that helps, Arun On 21/06/2017 17:10, weigengyu wrote: > > > > Hi Carles, > > Suppose that one packet is partitioned into two fragments. > > Because the Dtag indicates two fragments belonged to one packet, > the Rule ID in the second fragment is repeated, or redundent, isn't it? > > If the Rule ID is not exist in the second fragment, > the receiver can process it according to the Dtag which is the same in > two fragments. > Is there any confusions at the receiver side? > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carles Gomez Montene= gro > Sent: Wednesday, June 21, 2017 2:07 PM > To: weigengyu > Subject: Re: [lp-wan] Fw: re-order header field request > > > Hi Gengyu, > > Why each successive fragment must contain a Rule ID? >> It is known that the DTag is used as an indication of fragments belonged >> to >> the same IPv6 packet. >> A Rule ID in the first fragement can be passed to the receiver how to do >> HC >> compression, >> but the successive fragments containing a Rule ID just send a redundent >> information to the receiver. >> Right? >> > > The Rule ID is needed to provide a receiver with information on what type > of content is being carried (and how it has to be handled). Note that not > all IPv6 packets will require fragmentation, and then losses may happen, > also non-fragmented packets may be interleaved with fragments, etc. > > Cheers, > > Carles > > > Regards, >> >> Gengyu WEI >> Network Technology Center >> School of Computer >> Beijing University of Posts and Telecommunications >> > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan --001a11449aa6780d6305527d5aeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gengyu,

On Jun 21, 20= 17 7:06 PM, "weigengyu" <weigengyu@vip.sina.com> wrote:

Hi Arun,


BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no f= ragment.
In such cases, RuleID serves the purpose to identify if the incoming packet= is a fragmented packet

If a packet is fragmented, each fragment contain both Rule ID and Dtag as t= he draft defined.
But, the receiver can know which Rule ID is used by the Dtag in the succesi= ve fragments even in which Rule ID in not existed.


or if it's just came out of SCHC.

If a packet is not fragmented, there is a Rule ID as a indication.
Is there a Dtag?
<= /div>
There is no Dtag =C2=A0in this case.


Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Arun
Sent: Wednesday, June 21, 2017 11:52 PM
To: lp-wan@ietf.org

Subject: Re: [lp-wan] Fw: re-order header field request

Hi Gengyu,
The flow shall be;

BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no f= ragment.

In such cases, RuleID serves the purpose to identify if the incoming
packet is a fragmented packet or if it's just came out of SCHC. If we are sure that all the packets received will be fragmented then it makes
sense to send ruleID at the beginning.

hope that helps,
Arun


On 21/06/2017 17:10, weigengyu wrote:



Hi Carles,

Suppose that one packet is partitioned into two fragments.

Because the Dtag indicates two fragments belonged to one packet,
the Rule ID in the second fragment is repeated, or redundent, isn't it?=

If the Rule ID is not exist in the second fragment,
the receiver can process it according to the Dtag which is the same in
two fragments.
Is there any confusions at the receiver side?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carles Gomez Montenegr= o
Sent: Wednesday, June 21, 2017 2:07 PM
To: weigengyu
Subject: Re: [lp-wan] Fw: re-order header field request


Hi Gengyu,

Why each successive fragment must contain a Rule ID?
It is known that the DTag is used as an indication of fragments belonged to
the same IPv6 packet.
A Rule ID in the first fragement can be passed to the receiver how to do HC
compression,
but the successive fragments containing a Rule ID just send a redundent
information to the receiver.
Right?

The Rule ID is needed to provide a receiver with information on what type of content is being carried (and how it has to be handled). Note that not all IPv6 packets will require fragmentation, and then losses may happen, also non-fragmented packets may be interleaved with fragments, etc.

Cheers,

Carles


Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications


_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan








_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan
_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan

--001a11449aa6780d6305527d5aeb-- From nobody Wed Jun 21 14:40:34 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469E1127873 for ; Wed, 21 Jun 2017 14:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Yxol_NrQ62iL for ; Wed, 21 Jun 2017 14:40:30 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC44124217 for ; Wed, 21 Jun 2017 14:40:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 979AD300466 for ; Wed, 21 Jun 2017 17:40:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aGt-NAApMgUO for ; Wed, 21 Jun 2017 17:40:28 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6633A3002C1 for ; Wed, 21 Jun 2017 17:40:28 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> Date: Wed, 21 Jun 2017 17:40:28 -0400 To: lp-wan@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lp-wan] WGLC on LPWAN Overview draft X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 21:40:32 -0000 Section 2.1.2 talks about three symmetric keys that are used with AES. = The text explains how the keys are used, but it would be helpful to add = this to the tables: NwkSKey : 128-bit network session key used with AES-CMAC AppSKey : 128-bit application session key used with AES-CTR AppKey : 128-bit long term application key used with AES-ECB Section 2.2.2 tells us that the Packet Data Convergence Protocol (PDCP) = provides ciphering and integrity protection.Unlike the earlier section, = we do not learn anything about the source of the keys for these = cryptographic operations or the modes that are used. A quick look at = the 3GPP document tells me that PDCP is configured by upper layers, = which leads to more documents. So, these answers are not trivial to = find, but if they are known it would be useful to include them here. Section 2.3.2 does not talk about encryption, so I assume that the = messages are always in the clear. However, the section does talk about = a message authentication code. The section does not say anything about = the source of the authentication keys or the authentication algorithm. = If they are known it would be useful to include them here. Section 2.4.2 tells us that security is based on 802.1X and 802.11i. = Does the Wi-SUN Alliance require a particular public key algorithm for = use with EAP-TLS? Does 802.11i mean that AES-CCM is used for encryption = and integrity? Section 4.1 observes that "cryptographic protocols such as IPsec and = TLS, in addition to the round-trips required for secure session = establishment, cryptographic operations can require padding and addition = of authenticators that are problematic when considering LPWAN lower = layers.=E2=80=9D However, the Wi-SUN Alliance seems to use 802.1X with = EAP-TLS. This is quite different than the other three example LP WANs. = How does the gap analysis address this situation? Nits Section 2.1.2: s/described below../described below./ s/AEs-encrypt operation/AES-encrypt operation/ > Date: Mon, 19 Jun 2017 21:29:05 +0200 > From: Alexander Pelov > To: lp-wan@ietf.org > Subject: [lp-wan] WGLC on LPWAN Overview draft >=20 > Dear all, >=20 > As discussed during the last interim, we are starting a WGLC on the=20 > LPWAN Overview document: >=20 > https://tools.ietf.org/html/draft-ietf-lpwan-overview-04 >=20 >=20 > There should be no issues with the document at this stage, but please,=20= > DO review the document now and DO provide your comments and remarks if=20= > you see any issues. >=20 > The WGCL will end in two weeks, on July 3rd, 2017, 23h55 CEST. >=20 > Best, > Pascal and Alexander From nobody Wed Jun 21 15:15:45 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014A7124B0A for ; Wed, 21 Jun 2017 15:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 fI757ZfrcKfF for ; Wed, 21 Jun 2017 15:15:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D893128B37 for ; Wed, 21 Jun 2017 15:15:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BA52BBE55; Wed, 21 Jun 2017 23:15:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7EybES1S5ig; Wed, 21 Jun 2017 23:15:36 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 09117BE4D; Wed, 21 Jun 2017 23:15:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498083336; bh=oVeNaC9de8zNAvZ/fSB2stMCCqqU83x7+kQqtmQkzHs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Vo0ucYQNzBypU+ofO+RFnBGdP7mgsj85g8Aiqdk7By/bFuWUrnVDbztXCaFjqnJs4 LssX3tugJsOiYzKQDQrFvfoeTYfXgGVP4eHx8g9v/9im+rkmfbbxq1E+x8W0tT5vZX s9Y0VKvtbEzVmpgeHZTnkfIvOzYiVCERs5JruhR0= To: Russ Housley , lp-wan@ietf.org References: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <53a1a152-0c0c-3e12-8ec1-ca3ab2887425@cs.tcd.ie> Date: Wed, 21 Jun 2017 23:15:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kauNNWpi0t1EgtAKMPLAhtDIV3Rtv5LcF" Archived-At: Subject: Re: [lp-wan] WGLC on LPWAN Overview draft X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 22:15:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kauNNWpi0t1EgtAKMPLAhtDIV3Rtv5LcF Content-Type: multipart/mixed; boundary="CifGA1P78tPqhTuTCnoNslxEGorRrMsHl"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , lp-wan@ietf.org Message-ID: <53a1a152-0c0c-3e12-8ec1-ca3ab2887425@cs.tcd.ie> Subject: Re: [lp-wan] WGLC on LPWAN Overview draft References: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> In-Reply-To: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> --CifGA1P78tPqhTuTCnoNslxEGorRrMsHl Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Thanks Russ, good questions. I'm fine with making the change in 2.1.2 (as I contributed that text). For the others, I hope folks who know those technologies will chime in. (If not, I'll chase 'em but I hope they do:-) Cheers, S. On 21/06/17 22:40, Russ Housley wrote: > Section 2.1.2 talks about three symmetric keys that are used with AES. = The text explains how the keys are used, but it would be helpful to add = this to the tables: > NwkSKey : 128-bit network session key used with AES-CMAC > AppSKey : 128-bit application session key used with AES-CTR > AppKey : 128-bit long term application key used with AES-ECB >=20 > Section 2.2.2 tells us that the Packet Data Convergence Protocol (PDCP)= provides ciphering and integrity protection.Unlike the earlier section, = we do not learn anything about the source of the keys for these cryptogra= phic operations or the modes that are used. A quick look at the 3GPP doc= ument tells me that PDCP is configured by upper layers, which leads to mo= re documents. So, these answers are not trivial to find, but if they are= known it would be useful to include them here. >=20 > Section 2.3.2 does not talk about encryption, so I assume that the mess= ages are always in the clear. However, the section does talk about a mes= sage authentication code. The section does not say anything about the so= urce of the authentication keys or the authentication algorithm. If they= are known it would be useful to include them here. >=20 > Section 2.4.2 tells us that security is based on 802.1X and 802.11i. D= oes the Wi-SUN Alliance require a particular public key algorithm for use= with EAP-TLS? Does 802.11i mean that AES-CCM is used for encryption and= integrity? >=20 > Section 4.1 observes that "cryptographic protocols such as IPsec and TL= S, in addition to the round-trips required for secure session establishme= nt, cryptographic operations can require padding and addition of authenti= cators that are problematic when considering LPWAN lower layers.=E2=80=9D= However, the Wi-SUN Alliance seems to use 802.1X with EAP-TLS. This i= s quite different than the other three example LP WANs. How does the gap= analysis address this situation? >=20 > Nits >=20 > Section 2.1.2: > s/described below../described below./ > s/AEs-encrypt operation/AES-encrypt operation/ >=20 >> Date: Mon, 19 Jun 2017 21:29:05 +0200 >> From: Alexander Pelov >> To: lp-wan@ietf.org >> Subject: [lp-wan] WGLC on LPWAN Overview draft >> >> Dear all, >> >> As discussed during the last interim, we are starting a WGLC on the=20 >> LPWAN Overview document: >> >> https://tools.ietf.org/html/draft-ietf-lpwan-overview-04 >> >> >> There should be no issues with the document at this stage, but please,= =20 >> DO review the document now and DO provide your comments and remarks if= =20 >> you see any issues. >> >> The WGCL will end in two weeks, on July 3rd, 2017, 23h55 CEST. >> >> Best, >> Pascal and Alexander >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >=20 --CifGA1P78tPqhTuTCnoNslxEGorRrMsHl-- --kauNNWpi0t1EgtAKMPLAhtDIV3Rtv5LcF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZSvAHAAoJEC88hzaAX42itPsH/iV1kNmHp9Um8qLgtM0kDjD1 R49Ej86314mbmKamIpJyFaDleRCZWX2YExXl+1KySjLNH6+wWoefKcQ3fKCc7o4T hS18MXjZMAUx8lhK3QljhDBBe0j0d4vsOW7Tt5KwqWixetv3lw4vkfpdAzlmtIt8 I+P31tagULltWDukqmIpTVtCL1QjwrAUhepn4AgL7oZPkLsEBvrJFpX7peqtT8Rm FaOOJ5Wfor+MFFx6Lh2Sm2O1ft7pq0usp1uUVG9qBXBSGxnjW6KCZaDgoInVO81y MoVZhmbjLVmFW04lDxK+7yPnq+hTml6x7zy1K2eLytMCdoa1uItOxXsTdhzunwk= =Xdd8 -----END PGP SIGNATURE----- --kauNNWpi0t1EgtAKMPLAhtDIV3Rtv5LcF-- From nobody Wed Jun 21 15:18:59 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA39B1294BD for ; Wed, 21 Jun 2017 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luc4b9-XQtiO for ; Wed, 21 Jun 2017 15:18:56 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E8112949E for ; Wed, 21 Jun 2017 15:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=417; q=dns/txt; s=iport; t=1498083536; x=1499293136; h=reply-to:subject:references:to:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=pRZrKjbg/q1k23DFA5JlPy8GTGNTX3wp4OF2IowxkIY=; b=EE7W7JNYKSvDithAOJ3+ivHCxn76tf+FknzZSNQsV7PAIoMbKLiLmZt1 I/WBpoMvIee/ug9Yno2SPjxalm0pMhJOnb/LYhm5OUqNH1ojPALs/XIkV U47AJ6HvxaculzIze+MnkGD4aRROynEnoYEKkBoHEm7NOiv5VKSri4ZIN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAADn70pZ/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iFW4oZkV6VeIIRhiQCgnY/GAECAQEBAQEBAWsohRgBAQEBAgE?= =?us-ascii?q?jFUYLCxgCAiYCAlcGAQwIAQGKIAirBoImhG+GdgEBAQEBAQEBAQEBAQEBAQEig?= =?us-ascii?q?QuFYoFgK4J5h3yCYQEEnmKTYoFwAYkqhnOMSohHHziBCjAhCBsVgXKGAopEAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.39,370,1493683200"; d="scan'208";a="263899578" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2017 22:18:55 +0000 Received: from [161.44.79.64] ([161.44.79.64]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5LMIt0v005998; Wed, 21 Jun 2017 22:18:55 GMT Reply-To: paduffy@cisco.com References: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> To: Russ Housley , lp-wan@ietf.org From: Paul Duffy Organization: Cisco Systems Message-ID: Date: Wed, 21 Jun 2017 18:18:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lp-wan] WGLC on LPWAN Overview draft X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 22:18:58 -0000 On 6/21/2017 5:40 PM, Russ Housley wrote: > Section 2.4.2 tells us that security is based on 802.1X and 802.11i. Does the Wi-SUN Alliance require a particular public key algorithm for use with EAP-TLS? TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 is required > Does 802.11i mean that AES-CCM is used for encryption and integrity? Not quite Frame security is implemented as AES-CCM* as spec-ed in IEEE 802.15.4 From nobody Wed Jun 21 15:21:50 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A66F1294D4 for ; Wed, 21 Jun 2017 15:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prnZx4bSQ-rG for ; Wed, 21 Jun 2017 15:21:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2067012949E for ; Wed, 21 Jun 2017 15:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=346; q=dns/txt; s=iport; t=1498083681; x=1499293281; h=reply-to:subject:references:to:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=67YRFHBpwPNSMoszez+f1YptFmT5F6IfvX1d6LHe92k=; b=TQ5bw2lVp11AEqaSfkuTZz8L/oKBqRa6Axt5Q6JfQIjAk2UwTLcFOQ6z acVRLqpX8mY9RZvUMRZtcp+KKIwXnm82hwE44KUr2A570/DkbCMaEaQU3 WZxyP0jvZy2FvxtL4KjMl9IOHMifpNniBKkHqeV2hXJYL3ItfZD2R9mUP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAACr8EpZ/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iFW4oZkV6VeIIRhiQCgnY/GAECAQEBAQEBAWsohRkBBSMVUQs?= =?us-ascii?q?YAgImAgJXBgEMCAEBiiirB4ImhG+GdgEBAQEBAQEBAQEBAQEBAQEigQuFYoFgK?= =?us-ascii?q?4J5h3yCYQEEnmKTYoFwAYkqhnOMSohHHziBCjAhCBsVgXKGAopEAQEB?= X-IronPort-AV: E=Sophos;i="5.39,370,1493683200"; d="scan'208";a="42922427" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2017 22:21:20 +0000 Received: from [161.44.79.64] ([161.44.79.64]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v5LMLJmX018734; Wed, 21 Jun 2017 22:21:20 GMT Reply-To: paduffy@cisco.com References: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> To: Russ Housley , lp-wan@ietf.org From: Paul Duffy Organization: Cisco Systems Message-ID: <0a9023da-073e-2af8-6b5c-59d3e9b94413@cisco.com> Date: Wed, 21 Jun 2017 18:21:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lp-wan] WGLC on LPWAN Overview draft X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 22:21:49 -0000 On 6/21/2017 5:40 PM, Russ Housley wrote: > However, the Wi-SUN Alliance seems to use 802.1X with EAP-TLS. This is quite different than the other three example LP WANs. How does the gap analysis address this situation? Mains powered Wi-SUN mesh router nodes will typically be more resource capable than the other LPWAN techs discussed. From nobody Wed Jun 21 22:37:36 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17DC1267BB for ; Wed, 21 Jun 2017 22:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dleet5huWaCT for ; Wed, 21 Jun 2017 22:37:32 -0700 (PDT) Received: from smtp-6-47.vip.sina.com.cn (r3-68.sinamail.sina.com.cn [202.108.3.68]) by ietfa.amsl.com (Postfix) with SMTP id 6B3C41200CF for ; Wed, 21 Jun 2017 22:37:30 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.255.40.41]) by vip.sina.com with ESMTP 22 Jun 2017 13:37:25 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 179488278559 Message-ID: <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> From: "weigengyu" To: =?utf-8?B?4K6F4K6w4K+B4K6j4K+N4K6q4K6/4K6w4K6q4K+BIChhcnVucHJhYmh1KQ==?= Cc: References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> In-Reply-To: Date: Thu, 22 Jun 2017 13:37:24 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D2EB5C.AE49DAC0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 05:37:36 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0042_01D2EB5C.AE49DAC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Arun and all,=20 After reading through the draft-ietf-lpwan-ipv6-static-context-hc-04, one point needs to be exiplicit described: how many Rule IDs are used to = fragment one large IPv6 packet? =20 By my understanding, whne one IPv6 packet is fragmented, it adopts only = one Rule ID.=20 Each fragment contains the same rule ID and Dtag. Anything wrong?=20 Such a way to deliver the repeated Rule ID can be suppressed.=20 It may be available to have the first fragement only include the Rule ID = while containing the Dtag.=20 And the following successive fragments have the Dtage without the Rule = ID. The receiver can get the correct Rule ID from the first fragment = referred as the same Dtag. The Rule ID is suppressed in fragments from the second to the last. Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: = =E0=AE=85=E0=AE=B0=E0=AF=81=E0=AE=A3=E0=AF=8D=E0=AE=AA=E0=AE=BF=E0=AE=B0=E0= =AE=AA=E0=AF=81 (arunprabhu)=20 Sent: Thursday, June 22, 2017 3:27 AM To: weigengyu=20 Cc: lp-wan@ietf.org=20 Subject: Re: [lp-wan] Fw: re-order header field request Hi Gengyu, On Jun 21, 2017 7:06 PM, "weigengyu" wrote: Hi Arun,=20 BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no = fragment. In such cases, RuleID serves the purpose to identify if the incoming = packet is a fragmented packet If a packet is fragmented, each fragment contain both Rule ID and Dtag = as the draft defined. But, the receiver can know which Rule ID is used by the Dtag in the = succesive fragments even in which Rule ID in not existed.=20 or if it's just came out of SCHC. If a packet is not fragmented, there is a Rule ID as a indication. Is there a Dtag?=20 There is no Dtag in this case. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Arun Sent: Wednesday, June 21, 2017 11:52 PM To: lp-wan@ietf.org=20 Subject: Re: [lp-wan] Fw: re-order header field request Hi Gengyu, The flow shall be; BigPacket -> SCHC-> if size > MTU ? -> then fragment; else no = fragment. In such cases, RuleID serves the purpose to identify if the incoming packet is a fragmented packet or if it's just came out of SCHC. If we are sure that all the packets received will be fragmented then it = makes sense to send ruleID at the beginning. hope that helps, Arun On 21/06/2017 17:10, weigengyu wrote: Hi Carles, Suppose that one packet is partitioned into two fragments. Because the Dtag indicates two fragments belonged to one packet, the Rule ID in the second fragment is repeated, or redundent, isn't = it? If the Rule ID is not exist in the second fragment, the receiver can process it according to the Dtag which is the same = in two fragments. Is there any confusions at the receiver side? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carles Gomez = Montenegro Sent: Wednesday, June 21, 2017 2:07 PM To: weigengyu Subject: Re: [lp-wan] Fw: re-order header field request Hi Gengyu, Why each successive fragment must contain a Rule ID? It is known that the DTag is used as an indication of fragments = belonged to the same IPv6 packet. A Rule ID in the first fragement can be passed to the receiver how = to do HC compression, but the successive fragments containing a Rule ID just send a = redundent information to the receiver. Right? The Rule ID is needed to provide a receiver with information on what = type of content is being carried (and how it has to be handled). Note = that not all IPv6 packets will require fragmentation, and then losses may = happen, also non-fragmented packets may be interleaved with fragments, etc. Cheers, Carles Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan=20 _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan -------------------------------------------------------------------------= ------- _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan ------=_NextPart_000_0042_01D2EB5C.AE49DAC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi Arun and all,
 
After reading through the = draft-ietf-lpwan-ipv6-static-context-hc-04,
one point needs to be exiplicit described: how many Rule IDs are = used to=20 fragment one large IPv6 packet? 
 
By my understanding, whne one IPv6 packet is fragmented, it adopts = only one=20 Rule ID.
Each fragment contains the same rule ID and Dtag.
Anything wrong?
 
Such a way to deliver the repeated Rule ID can be suppressed. =
It may be available to have the first fragement only include the = Rule ID=20 while containing the Dtag.
And the following successive fragments have the Dtage without the = Rule=20 ID.
The receiver can get the correct Rule ID from the first fragment = referred=20 as the same Dtag.
 
The Rule ID is suppressed in fragments from the second to the = last.
 
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
Sent: Thursday, June 22, 2017 3:27 AM
Subject: Re: [lp-wan] Fw: re-order header field=20 request
 
Hi Gengyu,
 
On Jun 21, 2017 7:06 PM, "weigengyu" <weigengyu@vip.sina.com> = wrote:

Hi=20 Arun,=20


BigPacket=20 -> SCHC-> if size > MTU ? -> then fragment; else no=20 fragment.
In such cases, RuleID serves the purpose to identify if = the=20 incoming packet is a fragmented packet

If = a packet=20 is fragmented, each fragment contain both Rule ID and Dtag as the = draft=20 defined.
But, the receiver can know which Rule ID is used by the = Dtag in=20 the succesive fragments even in which Rule ID in not existed.=20


or=20 if it's just came out of SCHC.

If a packet = is not=20 fragmented, there is a Rule ID as a indication.
Is there a Dtag?=20
There is no Dtag  in this case.


Regards,

Gengyu WEI
Network = Technology Center
School of Computer
Beijing University of Posts = and=20 = Telecommunications
-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----= - From: Arun
Sent: Wednesday, June=20 21, 2017 11:52 PM
To: lp-wan@ietf.org=20

Subject: Re: [lp-wan] Fw: re-order header = field=20 request

Hi Gengyu,
The flow shall be;

BigPacket -> = SCHC-> if size > MTU ? -> then fragment; else no = fragment.

In=20 such cases, RuleID serves the purpose to identify if the = incoming
packet is=20 a fragmented packet or if it's just came out of SCHC. If we
are = sure that=20 all the packets received will be fragmented then it makes
sense to = send=20 ruleID at the beginning.

hope that helps,
Arun


On = 21/06/2017 17:10, weigengyu wrote:



Hi=20 Carles,

Suppose that one packet is partitioned into two=20 fragments.

Because the Dtag indicates two fragments belonged = to one=20 packet,
the Rule ID in the second fragment is repeated, or = redundent,=20 isn't it?

If the Rule ID is not exist in the second = fragment,
the=20 receiver can process it according to the Dtag which is the same = in
two=20 fragments.
Is there any confusions at the receiver=20 side?

Regards,

Gengyu WEI
Network Technology=20 Center
School of Computer
Beijing University of Posts and=20 Telecommunications
-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- = From: Carles Gomez Montenegro
Sent:=20 Wednesday, June 21, 2017 2:07 PM
To: weigengyu
Subject: Re: = [lp-wan]=20 Fw: re-order header field request


Hi Gengyu,

Why=20 each successive fragment must contain a Rule ID?
It is known = that the=20 DTag is used as an indication of fragments belonged
to
the = same IPv6=20 packet.
A Rule ID in the first fragement can be passed to the = receiver=20 how to do
HC
compression,
but the successive fragments = containing=20 a Rule ID just send a redundent
information to the=20 receiver.
Right?

The Rule ID is needed to = provide a=20 receiver with information on what type
of content is being = carried (and=20 how it has to be handled). Note that not
all IPv6 packets will = require=20 fragmentation, and then losses may happen,
also non-fragmented = packets=20 may be interleaved with fragments,=20 etc.

Cheers,

Carles


Regards,

Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing=20 University of Posts and=20 = Telecommunications


______________________________= _________________
lp-wan=20 mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan
=








____________________________= ___________________
lp-wan=20 mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan=20

_______________________________________________
lp-wan = mailing=20 list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan
=
 

_______________________________________________
lp-wan mailing=20 list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan
------=_NextPart_000_0042_01D2EB5C.AE49DAC0-- From nobody Thu Jun 22 00:11:29 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775FD1296C9 for ; Thu, 22 Jun 2017 00:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] 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 IMvccGZpAa-6 for ; Thu, 22 Jun 2017 00:11:26 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C972129666 for ; Thu, 22 Jun 2017 00:11:26 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id A972C180267; Thu, 22 Jun 2017 09:11:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 387D41C005D; Thu, 22 Jun 2017 09:11:24 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0352.000; Thu, 22 Jun 2017 09:11:24 +0200 From: To: Juan Carlos Zuniga , Laurent Toutain CC: lp-wan Thread-Topic: [lp-wan] SCHC - To pad or not to pad Thread-Index: AQHS6ybB81GOZs0+UEeR+3Au3Ky5VQ== Date: Thu, 22 Jun 2017 07:11:23 +0000 Message-ID: <15956_1498115484_594B6D9C_15956_13_1_D57137F0.44D52%dominique.barthel@orange.com> 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.168.234.5] Content-Type: multipart/alternative; boundary="_000_D57137F044D52dominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] SCHC - To pad or not to pad X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 07:11:28 -0000 --_000_D57137F044D52dominiquebarthelorangecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Juan Carlos, Good point. I think your understanding is correct, and I see your point. It seems to me that we don't have to mandate the padding behaviour in the g= eneric SCHC document. Each SCHC-over-foo derivation could make its own decision regarding padding= or not and impose it on the implementors. Or this could even be a flag in the SCHC compressor/decompressor state, lea= ving the decision to pad or not to the integrator. Comments ? Best regards Dominique De : lp-wan > on be= half of Juan Carlos Zuniga > Date : Wednesday 21 June 2017 18:42 =C0 : Laurent Toutain > Cc : lp-wan > Objet : [lp-wan] SCHC - To pad or not to pad Hi Laurent, In the call you proposed padding in-between SCHC header and Payload Data. H= owever, seems to me that this would limit the (already small) amount of bit= s available for Data. For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11 bi= ts would be padded up to 16, leaving only 48 available bits for data instea= d of 53. Is my understanding correct? Best, Juan Carlos ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_D57137F044D52dominiquebarthelorangecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1748A2011A7DC8408ED6F6BFE9820A7F@adroot.infra.ftgroup> Content-Transfer-Encoding: quoted-printable
Hi Juan Carlos,

Good point. I think your understanding is correct, and I see your poin= t.
It seems to me that we don't have to mandate the padding behaviour in = the generic SCHC document.
Each SCHC-over-foo derivation could make its own decision regarding pa= dding or not and impose it on the implementors.
Or this could even be a flag in the SCHC compressor/decompressor state= , leaving the decision to pad or not to the integrator.
Comments ?
Best regards

Dominique

De : lp-wan <lp-wan-bounces@ietf.org> on behalf of J= uan Carlos Zuniga <juanc= arlos.zuniga@sigfox.com>
Date : Wednesday 21 June 2017 = 18:42
=C0 : Laurent Toutain <laurent.toutain@imt-atlant= ique.fr>
Cc : lp-wan <lp-wan@ietf.org>
Objet : [lp-wan] SCHC - To pad= or not to pad

Hi Laurent,

 

In the call you proposed padding in-between SCHC hea= der and Payload Data. However, seems to me that this would limit the (alrea= dy small) amount of bits available for Data.

 

For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11 bits would be padded up to 16, leaving only 4= 8 available bits for data instead of 53.

 

Is my understanding correct?

 

Best,

 

Juan Carlos

 

 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_D57137F044D52dominiquebarthelorangecom_-- From nobody Thu Jun 22 01:49:25 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679AE128799 for ; Thu, 22 Jun 2017 01:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 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, T_SPF_PERMERROR=0.01, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 Di6EOKaLMeVh for ; Thu, 22 Jun 2017 01:49:20 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [IPv6:2001:660:330f:2::c1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A358127419 for ; Thu, 22 Jun 2017 01:49:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 047471005FE for ; Thu, 22 Jun 2017 10:49:19 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id FC0GJvCmuIN8 for ; Thu, 22 Jun 2017 10:49:18 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 3FC3A1005FD for ; Thu, 22 Jun 2017 10:49:18 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy120.enst.fr 3FC3A1005FD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1498121358; bh=nJfUSo2Rj5qBO9cRjYYGvu/L/zzi02a64xUvM8E+OG0=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=BUel59iAzXFMnE7pAS/73cJk5zQhBhzyKJKVloihoE6V7MT6maYaZMUc8iOMo+YSn 24U3p8aSVmsIMwGtmUMTfMRbzeSNIBHDuhVNVh5VFwcC7G6MHUOPAJDSzJ6vbxiqZn H6odiQ2xzUx4nqeBulHKrvXp43ndtnGHwOiQjpuM= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id zaV4x56qlVlw for ; Thu, 22 Jun 2017 10:49:18 +0200 (CEST) Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com [209.85.217.172]) by zproxy120.enst.fr (Postfix) with ESMTPSA id CF23E100604 for ; Thu, 22 Jun 2017 10:49:17 +0200 (CEST) Received: by mail-ua0-f172.google.com with SMTP id g40so9906164uaa.3 for ; Thu, 22 Jun 2017 01:49:17 -0700 (PDT) X-Gm-Message-State: AKS2vOxGo9h3rOBIdsAiX3pJqK1LZELIjACiRipF5FmYpzBgxc6sV/ae dstvV+YM2j8ANeLypagBXh8pwO6VzQ== X-Received: by 10.176.78.29 with SMTP id g29mr1474485uah.55.1498121356477; Thu, 22 Jun 2017 01:49:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.61.94 with HTTP; Thu, 22 Jun 2017 01:48:35 -0700 (PDT) In-Reply-To: <15956_1498115484_594B6D9C_15956_13_1_D57137F0.44D52%dominique.barthel@orange.com> References: <15956_1498115484_594B6D9C_15956_13_1_D57137F0.44D52%dominique.barthel@orange.com> From: Laurent Toutain Date: Thu, 22 Jun 2017 10:48:35 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "BARTHEL Dominique IMT/OLPS" Cc: Juan Carlos Zuniga , lp-wan Content-Type: multipart/alternative; boundary="f40304378a6c48c1dd0552888fab" Archived-At: Subject: Re: [lp-wan] SCHC - To pad or not to pad X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 08:49:23 -0000 --f40304378a6c48c1dd0552888fab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juan Carlos Yes this is good point. In fact putting padding between header and data is not a so good idea if the data are not themselves aligned on a byte boundary. For instance if the header is 12 bit long and the data 4 bit long. If we introduce padding between header and data the result will be 2 bytes. If we stick the data to the header only one byte is needed. The risk if the padding is added after the data is to include it into the data (as Ethernet) and since the length is elided by compression it can be more tricky to solve the problem. In fact we can state that when the payload is an IETF payload it is always bytes that are send, therefore it is easy to solve the padding problem. When the payload is not IETF compatible, then the payload must have a way to avoid confusion (strict data format, length included,...) My feeling is that LoRa is may be more byte oriented than Sigfox, but I don't think it is necessary to complexify the standard and the implementation by two different behaviors. I will propose to state on the draft =C2=A7 4.3 ---- o sending: The Rule ID is sent to the other end followed by information resulting from the compression of header fields *, directly followed by the payload.* This *The result of field compression is* information is sent in the order expressed in the Rule for the matching fields. The way the Rule ID is sent depends on the specific LPWAN layer two technology and will be specified in a specific document, and is out of the scope of this document. For example, it can be either included in a Layer 2 header or sent in the first byte of the L2 payload. (cf. Figure 4). o decompression: In both directions, The receiver identifies the sender through its device-id (e.g. MAC address) and selects the appropriate Rule through the Rule ID. This Rule gives the compressed header format and associates these values to header fields. It applies the CDA action to reconstruct the original header fields. The CDA application order can be different of the order given by the Rule. For instance Compute-* may be applied at end, after the other CDAs. * Payload is always a multiple of 8 bits, so the last bit of a L2 payload* * must be ignored. * +--- ... ---+-------------- ... --------------+*-------------+*--+ | Rule ID |Compressed Hdr Fields information| * payload |//|* +--- ... ---+-------------- ... --------------+*-------------+--+* On Thu, Jun 22, 2017 at 9:11 AM, wrote: > Hi Juan Carlos, > > Good point. I think your understanding is correct, and I see your point. > It seems to me that we don't have to mandate the padding behaviour in the > generic SCHC document. > Each SCHC-over-foo derivation could make its own decision regarding > padding or not and impose it on the implementors. > Or this could even be a flag in the SCHC compressor/decompressor state, > leaving the decision to pad or not to the integrator. > Comments ? > Best regards > > Dominique > > De : lp-wan on behalf of Juan Carlos Zuniga < > juancarlos.zuniga@sigfox.com> > Date : Wednesday 21 June 2017 18:42 > =C3=80 : Laurent Toutain > Cc : lp-wan > Objet : [lp-wan] SCHC - To pad or not to pad > > Hi Laurent, > > > > In the call you proposed padding in-between SCHC header and Payload Data. > However, seems to me that this would limit the (already small) amount of > bits available for Data. > > > > For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11 > bits would be padded up to 16, leaving only 48 available bits for data > instead of 53. > > > > Is my understanding correct? > > > > Best, > > > > Juan Carlos > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > > --f40304378a6c48c1dd0552888fab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juan Carlos

Yes this is good point.

=
In fact putting padding between header and data is not a so good= idea if the data are not themselves aligned on a byte boundary. For instan= ce if the header is 12 bit long and the data 4 bit long. If we introduce pa= dding between header and data the result will be 2 bytes. If we stick the d= ata to the header only one byte is needed.

The risk if the padding = is added after the data is to include it into the data (as Ethernet) and si= nce the length is elided=C2=A0 by compression it can be more tricky to solv= e the problem. In fact we can state that when the payload is an IETF payloa= d it is always bytes that are send, therefore it is easy to solve the paddi= ng problem. When the payload is not IETF compatible, then the payload must = have a way to avoid confusion (strict data format, length included,...)
=
My feeling is that LoRa is may be more byte oriented than Si= gfox, but I don't think it is necessary to complexify the standard and = the implementation by two different behaviors. I will propose to state on t= he draft =C2=A7 4.3

=C2=A0 ----
o  sending: The Rule ID is s=
ent to the other end followed by
      information resulting from the compression of header fields, direc=
tly followed
      by the payload.  This The result of field compres=
sion is
      information is sent in the order expressed in the Rule for the
      matching fields.  The way the Rule ID is sent depends on the
      specific LPWAN layer two technology and will be specified in a
      specific document, and is out of the scope of this document.  For
      example, it can be either included in a Layer 2 header or sent in
      the first byte of the L2 payload. (cf.  Figure 4). 
      =C2=A0



=C2=A0o  decompression: In b=
oth directions, The receiver identifies the
      sender through its device-id (e.g.  MAC address) and selects the
      appropriate Rule through the Rule ID.  This Rule gives the
      compressed header format and associates these values to header
      fields.  It applies the CDA action to reconstruct the original
      header fields.  The CDA application order can be different of the
      order given by the Rule.  For instance Compute-* may be applied at
      end, after the other CDAs.

      Payload is alwa=
ys a multiple of 8 bits, so the last bit of a L2 payload
=
      must be ignored.  



  =C2=A0+--- ... =
---+-------------- ... --------------+-------------+--+
   |  Rule ID  |Compressed Hdr Fields information|   payload   |//|
   +--- ... ---+-------------- ... --------------+-------------+--+=

= On Thu, Jun 22, 2017 at 9:11 AM, <dominique.barthel@orange.com= > wrote:
Hi Juan Carlos,

Good point. I think your understanding is correct, and I see your poin= t.
It seems to me that we don't have to mandate the padding behaviour= in the generic SCHC document.
Each SCHC-over-foo derivation could make its own decision regarding pa= dding or not and impose it on the implementors.
Or this could even be a flag in the SCHC compressor/decompressor state= , leaving the decision to pad or not to the integrator.
Comments ?
Best regards

Dominique

De=C2=A0: lp-wan <lp-wan-bounces@ietf.org&= gt; on behalf of Juan Carlos Zuniga <juancarlos.zuniga@sigfox.com>
Date=C2=A0: Wednesday 21 June 2017 = 18:42
=C3=80=C2=A0: Laurent Toutain <<= a href=3D"mailto:laurent.toutain@imt-atlantique.fr" target=3D"_blank">laure= nt.toutain@imt-atlantique.fr>
Cc=C2=A0: lp-wan <lp-wan@ietf.org>
Objet=C2=A0: [lp-wan] SCHC - To pad= or not to pad

Hi Laurent,

=C2=A0

In the call you proposed padding in-between SCHC hea= der and Payload Data. However, seems to me that this would limit the (alrea= dy small) amount of bits available for Data.

=C2=A0

For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11 bits would be padded up to 16, leaving only 4= 8 available bits for data instead of 53.

=C2=A0

Is my understanding correct?

=C2=A0

Best,

=C2=A0

Juan Carlos

=C2=A0

 
____________________________________________________________=
_____________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan

--f40304378a6c48c1dd0552888fab-- From nobody Thu Jun 22 04:21:37 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EFA126B6D for ; Thu, 22 Jun 2017 04:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EoPmN3AwuWi for ; Thu, 22 Jun 2017 04:21:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92F312773A for ; Thu, 22 Jun 2017 04:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3304; q=dns/txt; s=iport; t=1498130493; x=1499340093; h=from:to:subject:date:message-id:mime-version; bh=YAl9VdxR3Dk2EmNiHvof9xZjLu7lcp+HFKnSPjex9hg=; b=MsqKBeHuqbLCQnmdLQaMrcsEuhkcTAHskC+sGt1Ms30lMIcWbypa7Iab 5jqftn5ZbWY1r1Z04TAmuyUuSei6MPZLJT0gAJ5VEchs3HzUBXP4rJniD QqpAnKt7FzSrVawWu+yhU5Ck0mPaWSzDa6gMa5e84wJLyqkG2oGKYRLnw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQAPp0tZ/40NJK1dARkBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJvaWKBFI1+oiyFKoIRLoh1PxgBAgEBAQEBAQFrKIVMXgEMdCYBBBu?= =?us-ascii?q?JQGQQrhaLZAEBAQEBBQEBAQEBAQEcBYZthkCJIgWeYwKBXYVUjCaCEoVIiQGBP?= =?us-ascii?q?ZUVAR84gQp0FYdYiUaBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,373,1493683200"; d="scan'208,217";a="261075580" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jun 2017 11:21:32 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v5MBLWES007030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Jun 2017 11:21:33 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 22 Jun 2017 06:21:32 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Thu, 22 Jun 2017 06:21:32 -0500 From: "Pascal Thubert (pthubert)" To: lp-wan Thread-Topic: Minutes of LPWAN WG interim meeting, June 21st, posted Thread-Index: AdLrSXp3hVeFCvOxThu4xCvTumT2+g== Date: Thu, 22 Jun 2017 11:21:10 +0000 Deferred-Delivery: Thu, 22 Jun 2017 11:20:59 +0000 Message-ID: <7c4f604d986a4a178ee9f0cc8f131c87@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_7c4f604d986a4a178ee9f0cc8f131c87XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Minutes of LPWAN WG interim meeting, June 21st, posted X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 11:21:36 -0000 --_000_7c4f604d986a4a178ee9f0cc8f131c87XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all : The minutes and other proceedings of the Interim meeting are now available = on the IETF datatracker at https://datatracker.ietf.org/meeting/interim-201= 7-lpwan-05/session/lpwan . Please review the minutes, and provide feedback if somethings was mis-captu= red or is missing. Cheers, The chairs --_000_7c4f604d986a4a178ee9f0cc8f131c87XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all :<= /p>

 

The minutes and other proceedings of the Interim mee= ting are now available on the IETF datatracker at https://datatracker.ietf.org/meeting/interim-2017-lpwan-05/session/lpwan .

Please review the minutes, and provide feedback if s= omethings was mis-captured or is missing.

 

Cheers,

 

The chairs

 

 

 

--_000_7c4f604d986a4a178ee9f0cc8f131c87XCHRCD001ciscocom_-- From nobody Thu Jun 22 11:11:41 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B0312778D; Thu, 22 Jun 2017 11:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 jEa6uMYvC5QS; Thu, 22 Jun 2017 11:11:38 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [IPv6:2001:660:330f:2::c0]) by ietfa.amsl.com (Postfix) with ESMTP id B2B3A1201FA; Thu, 22 Jun 2017 11:11:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 61EE3102C93; Thu, 22 Jun 2017 20:11:36 +0200 (CEST) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id yyUIgKn9zF_4; Thu, 22 Jun 2017 20:11:34 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id CF8A6102CF0; Thu, 22 Jun 2017 20:11:34 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy110.enst.fr CF8A6102CF0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1498155094; bh=lM8VO8fCfXdHzurTsvqqjdaEb09Ydv5ev9Ei4zRw9W0=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=XA0Wskgjhnqletg9WWBfHeP1X2asmvLgF68dzT1b0WEAG846DlmOnK5iN7Bf78ui7 ZUTQcl1t6B1NpgTdv8VRRnJpVAb6CvgcaXgh7UXhHzhG6HrLuaEV2Jk95KF9hJW0+y 5pOKzh6+kYMjjalZkY72DjQez/BN4GDcadnpxCVM= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id Hl1U8ozev7tv; Thu, 22 Jun 2017 20:11:34 +0200 (CEST) Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 792D6102C93; Thu, 22 Jun 2017 20:11:34 +0200 (CEST) Received: by mail-vk0-f47.google.com with SMTP id 191so3270237vko.2; Thu, 22 Jun 2017 11:11:34 -0700 (PDT) X-Gm-Message-State: AKS2vOysrWft+Sr6Nd8XhWoZzrJ7+yw8S6PKCR6k0UWVMEoCEdsE3+pc FnpGFdJ8QDYnihQKYLy+13SfwDG3yA== X-Received: by 10.31.67.80 with SMTP id q77mr562842vka.140.1498155093168; Thu, 22 Jun 2017 11:11:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.61.94 with HTTP; Thu, 22 Jun 2017 11:10:52 -0700 (PDT) From: Laurent Toutain Date: Thu, 22 Jun 2017 20:10:52 +0200 X-Gmail-Original-Message-ID: Message-ID: To: lp-wan , hackathon@ietf.org Content-Type: multipart/alternative; boundary="001a114dcaae259c8c0552906a62" Archived-At: Subject: [lp-wan] SCHC testing X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 18:11:40 -0000 --001a114dcaae259c8c0552906a62 Content-Type: text/plain; charset="UTF-8" Hi, The LPWAN compression mechanism SCHC defined in draft-ietf-lpwan-ipv6-static-context-hc is mature and at least 3 implementations already exist. During the next Hackathon in Prague, a LoRaWAN and a Sigfox network will be available to perform test of SCHC with several objectives: - allow developers to understand SCHC behavior and implement their own version of the mechanism - test interoperability between the existing implementations - define compression and fragmentation rules related to specific traffic Come with your own devices or use the pycom devices we will bring to participate to the real Internet of Things. To participate you need to register as quickly as possible on http://ietf.org/hackathon/99-hackathon.html We will provide more technical details on the coming days. Laurent --001a114dcaae259c8c0552906a62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

<= br>

The LPWAN compression mechanism SCHC defined = in draft-ietf-lpwan-ipv6-static-context-hc is mature and at least 3 implementations already exist. During the next Hackathon in Prague, a LoRaW= AN and a Sigfox network will be available to perform test of SCHC with several objectives:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 allow developers to understand SCHC behavior and implement their own version of the mechanism

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 test interoperability between the existing implementations

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 define compression and fragmentation rules related to = specific traffic

Come with your own devices or use the pycom devices = we will bring to participate to the real Internet of Things. To participate you nee= d to register as quickly as possible on http://ietf.org/hackathon/99-hackathon.html


We will provide mor= e technical details on the coming days.


<= p class=3D"MsoNormal">Laurent

--001a114dcaae259c8c0552906a62-- From nobody Thu Jun 22 23:15:04 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A95C129484 for ; Thu, 22 Jun 2017 23:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 xoPaVONUqmKQ for ; Thu, 22 Jun 2017 23:14:54 -0700 (PDT) Received: from smtp-6-47.vip.sina.com.cn (r3-63.sinamail.sina.com.cn [202.108.3.63]) by ietfa.amsl.com (Postfix) with SMTP id 8F48A129B83 for ; Thu, 22 Jun 2017 23:14:51 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.246.135.90]) by vip.sina.com with ESMTP 23 Jun 2017 14:14:46 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 185960278552 Message-ID: <7EC68881FD0D46BFA4A8BF5BFF51ADFE@WeiGengyuPC> From: "weigengyu" To: "Laurent Toutain" , "lp-wan" , References: In-Reply-To: Date: Fri, 23 Jun 2017 14:14:44 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01D2EC2B.100C5C00" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] SCHC testing X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 06:14:58 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_00C4_01D2EC2B.100C5C00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, The doc is just a draft.=20 > The LPWAN compression mechanism SCHC defined in = draft-ietf-lpwan-ipv6-static-context-hc is mature=20 >From a technical view point, it is not a mature because it can be = optimize apparently. Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Laurent Toutain=20 Sent: Friday, June 23, 2017 2:10 AM To: lp-wan ; hackathon@ietf.org=20 Subject: [lp-wan] SCHC testing Hi, The LPWAN compression mechanism SCHC defined in = draft-ietf-lpwan-ipv6-static-context-hc is mature and at least 3 = implementations already exist. During the next Hackathon in Prague, a = LoRaWAN and a Sigfox network will be available to perform test of SCHC = with several objectives: - allow developers to understand SCHC behavior and implement their = own version of the mechanism - test interoperability between the existing implementations - define compression and fragmentation rules related to specific = traffic Come with your own devices or use the pycom devices we will bring to = participate to the real Internet of Things. To participate you need to = register as quickly as possible on = http://ietf.org/hackathon/99-hackathon.html=20 We will provide more technical details on the coming days. Laurent -------------------------------------------------------------------------= ------- _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan ------=_NextPart_000_00C4_01D2EC2B.100C5C00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
The doc is just a draft.
 
> The LPWAN compression mechanism SCHC defined in=20 draft-ietf-lpwan-ipv6-static-context-hc is mature
From a technical view point, it is not a mature because it can be = optimize=20 apparently.
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
From: Laurent Toutain =
Sent: Friday, June 23, 2017 2:10 AM
Subject: [lp-wan] SCHC testing
 

Hi,

 

The LPWAN compression mechanism SCHC defined in=20 draft-ietf-lpwan-ipv6-static-context-hc is mature and at least 3=20 implementations already exist. During the next Hackathon in Prague, a = LoRaWAN=20 and a Sigfox network will be available to perform test of SCHC with = several=20 objectives:

 

= -       = allow developers to understand SCHC behavior and = implement=20 their own version of the mechanism

-       = test interoperability between the existing=20 implementations

-       = define compression and fragmentation rules related = to=20 specific traffic

Come with your own devices or use the pycom devices = we will=20 bring to participate to the real Internet of Things. To participate you = need to=20 register as quickly as possible on http://ietf.org/hack= athon/99-hackathon.html=20

 

We will provide more technical details on the = coming=20 days.

 

Laurent

_______________________________________________
lp-wan mailing=20 list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan
------=_NextPart_000_00C4_01D2EC2B.100C5C00-- From nobody Fri Jun 23 02:13:40 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A48F124BE8 for ; Fri, 23 Jun 2017 02:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 IoWKsGVsyjX5 for ; Fri, 23 Jun 2017 02:13:35 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1F312009C for ; Fri, 23 Jun 2017 02:13:35 -0700 (PDT) Received: from mfilter1-d.gandi.net (mfilter1-d.gandi.net [217.70.178.130]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id D53EDA8141; Fri, 23 Jun 2017 11:13:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter1-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter1-d.gandi.net (mfilter1-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id CPuV9aUyxooW; Fri, 23 Jun 2017 11:13:31 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from el-meco.rennes.enst-bretagne.fr (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: ana@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id D46FAA8118; Fri, 23 Jun 2017 11:13:30 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_FD9AB2AE-0AD6-4136-832C-DDC94B813275" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ana Minaburo In-Reply-To: Date: Fri, 23 Jun 2017 11:13:30 +0200 Cc: BARTHEL Dominique IMT/OLPS , lp-wan , Juan Carlos Zuniga Message-Id: References: <15956_1498115484_594B6D9C_15956_13_1_D57137F0.44D52%dominique.barthel@orange.com> To: Laurent Toutain X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [lp-wan] SCHC - To pad or not to pad X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 09:13:38 -0000 --Apple-Mail=_FD9AB2AE-0AD6-4136-832C-DDC94B813275 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, One question about your second modification in decompression If we put that =E2=80=98payload is always a multiple of 8 bits=E2=80=99 = we force the application to complete its payload to be multiple of 8 = bits before compression, so after compression we have the same problem, = isn=E2=80=99t it? I suggest instead: IF after using SCHC compression and adding the = payload to the L2 frame the datagram is not multiple of 8 bits, padding = may be used. What do you think? Ana > On 22 Jun 2017, at 10:48, Laurent Toutain = wrote: >=20 > Hi Juan Carlos >=20 > Yes this is good point. >=20 > In fact putting padding between header and data is not a so good idea = if the data are not themselves aligned on a byte boundary. For instance = if the header is 12 bit long and the data 4 bit long. If we introduce = padding between header and data the result will be 2 bytes. If we stick = the data to the header only one byte is needed.=20 >=20 > The risk if the padding is added after the data is to include it into = the data (as Ethernet) and since the length is elided by compression it = can be more tricky to solve the problem. In fact we can state that when = the payload is an IETF payload it is always bytes that are send, = therefore it is easy to solve the padding problem. When the payload is = not IETF compatible, then the payload must have a way to avoid confusion = (strict data format, length included,...) >=20 > My feeling is that LoRa is may be more byte oriented than Sigfox, but = I don't think it is necessary to complexify the standard and the = implementation by two different behaviors. I will propose to state on = the draft =C2=A7 4.3 >=20 > ---- > o sending: The Rule ID is sent to the other end followed by > information resulting from the compression of header fields, = directly followed > by the payload. This The result of field compression is > information is sent in the order expressed in the Rule for the > matching fields. The way the Rule ID is sent depends on the > specific LPWAN layer two technology and will be specified in a > specific document, and is out of the scope of this document. = For > example, it can be either included in a Layer 2 header or sent = in > the first byte of the L2 payload. (cf. Figure 4).=20 > =20 >=20 >=20 >=20 > o decompression: In both directions, The receiver identifies the > sender through its device-id (e.g. MAC address) and selects the > appropriate Rule through the Rule ID. This Rule gives the > compressed header format and associates these values to header > fields. It applies the CDA action to reconstruct the original > header fields. The CDA application order can be different of = the > order given by the Rule. For instance Compute-* may be applied = at > end, after the other CDAs. >=20 > Payload is always a multiple of 8 bits, so the last bit of a L2 = payload > must be ignored. =20 >=20 >=20 >=20 > +--- ... ---+-------------- ... --------------+-------------+--+ > | Rule ID |Compressed Hdr Fields information| payload |//| > +--- ... ---+-------------- ... --------------+-------------+--+ >=20 > On Thu, Jun 22, 2017 at 9:11 AM, > wrote: > Hi Juan Carlos, >=20 > Good point. I think your understanding is correct, and I see your = point. > It seems to me that we don't have to mandate the padding behaviour in = the generic SCHC document. > Each SCHC-over-foo derivation could make its own decision regarding = padding or not and impose it on the implementors. > Or this could even be a flag in the SCHC compressor/decompressor = state, leaving the decision to pad or not to the integrator. > Comments ? > Best regards >=20 > Dominique >=20 > De : lp-wan > = on behalf of Juan Carlos Zuniga > > Date : Wednesday 21 June 2017 18:42 > =C3=80 : Laurent Toutain > > Cc : lp-wan > > Objet : [lp-wan] SCHC - To pad or not to pad >=20 > Hi Laurent, >=20 > =20 >=20 > In the call you proposed padding in-between SCHC header and Payload = Data. However, seems to me that this would limit the (already small) = amount of bits available for Data. >=20 > =20 >=20 > For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of = 11 bits would be padded up to 16, leaving only 48 available bits for = data instead of 53. >=20 > =20 >=20 > Is my understanding correct? >=20 > =20 >=20 > Best, >=20 > =20 >=20 > Juan Carlos >=20 > =20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan = >=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --Apple-Mail=_FD9AB2AE-0AD6-4136-832C-DDC94B813275 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

One = question about your second modification in decompression

If we put that = =E2=80=98payload is always a multiple of 8 bits=E2=80=99 we force the = application to complete its payload to be multiple of 8 bits before = compression, so after compression we have the same problem, isn=E2=80=99t = it?

I suggest = instead: IF after using SCHC compression and adding the payload to the = L2 frame the datagram is not multiple of 8 bits, padding may be = used.

What do = you think?

Ana



On = 22 Jun 2017, at 10:48, Laurent Toutain <Laurent.Toutain@imt-atlantique.fr> wrote:

Hi Juan Carlos

Yes= this is good point.

In= fact putting padding between header and data is not a so good idea if = the data are not themselves aligned on a byte boundary. For instance if = the header is 12 bit long and the data 4 bit long. If we introduce = padding between header and data the result will be 2 bytes. If we stick = the data to the header only one byte is needed.

The risk if the padding is added after the data is to include = it into the data (as Ethernet) and since the length is elided  by = compression it can be more tricky to solve the problem. In fact we can = state that when the payload is an IETF payload it is always bytes that = are send, therefore it is easy to solve the padding problem. When the = payload is not IETF compatible, then the payload must have a way to = avoid confusion (strict data format, length included,...)

My feeling is that LoRa = is may be more byte oriented than Sigfox, but I don't think it is = necessary to complexify the standard and the implementation by two = different behaviors. I will propose to state on the draft =C2=A7 4.3

  ----
o  =
sending: The Rule ID is sent to the other end followed by
      information resulting from the compression of header fields, directly followed
      by the payload.  =
This The result of field compression is
      information is sent in the order expressed in the Rule for =
the
      matching fields.  The way the Rule ID is sent depends on the
      specific LPWAN layer two technology and will be specified in a
      specific document, and is out of the scope of this document.  For
      example, it can be either included in a Layer 2 header or sent in
      the first byte of the L2 payload. (cf.  Figure 4). 
 =
      



 o  =
decompression: In both directions, The receiver identifies the
      sender through its device-id (e.g.  MAC address) and selects the
      appropriate Rule through the Rule ID.  This Rule gives the
      compressed header format and associates these values to header
      fields.  It applies the CDA action to reconstruct the original
      header fields.  The CDA application order can be different of the
      order given by the Rule.  For instance Compute-* may be applied at
      end, after the other CDAs.

      Payload is always a multiple of 8 bits, =
so the last bit of a L2 payload
      must be ignored.  



   +--- ... =
---+-------------- ... --------------+-------------+--+
   |  Rule ID  |Compressed Hdr Fields information|   =
payload   |//|
   +--- ... ---+-------------- ... --------------+-------------+--+

On Thu, = Jun 22, 2017 at 9:11 AM, <dominique.barthel@orange.com> wrote:
Hi Juan Carlos,

Good point. I think your understanding is correct, and I = see your point.
It seems to me that we don't have to mandate the padding = behaviour in the generic SCHC document.
Each SCHC-over-foo derivation could make its own = decision regarding padding or not and impose it on the = implementors.
Or this could even be a flag in the SCHC = compressor/decompressor state, leaving the decision to pad or not to the = integrator.
Comments ?
Best regards

Dominique

De : lp-wan = <lp-wan-bounces@ietf.org> on behalf of Juan Carlos = Zuniga <juancarlos.zuniga@sigfox.com>
Date : Wednesday = 21 June 2017 18:42
=C3=80 : Laurent = Toutain <laurent.toutain@imt-atlantique.fr>
Cc : lp-wan = <lp-wan@ietf.org>
Objet : [lp-wan] = SCHC - To pad or not to pad

Hi Laurent,

 

In the call you proposed padding in-between SCHC = header and Payload Data. However, seems to me that this would limit the = (already small) amount of bits available for Data.

 

For instance, in a 64-bit = Sigfox DL frame, an eventual SCHC header of 11 bits would be padded up to 16, leaving = only 48 available bits for data instead of 53.

 

Is my understanding correct?

 

Best,

 

Juan = Carlos

 

 
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged =
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan


_______________________________________________
lp-wan = mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

= --Apple-Mail=_FD9AB2AE-0AD6-4136-832C-DDC94B813275-- From nobody Fri Jun 23 03:48:37 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB555127180 for ; Fri, 23 Jun 2017 03:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ShGZNwhhe9nR for ; Fri, 23 Jun 2017 03:48:33 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 77FD21200ED for ; Fri, 23 Jun 2017 03:48:33 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5NAmT6r028631; Fri, 23 Jun 2017 12:48:29 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 68D1A1D53C1; Fri, 23 Jun 2017 12:48:28 +0200 (CEST) Received: from 10.193.93.143 by webmail.entel.upc.edu with HTTP; Fri, 23 Jun 2017 12:47:57 +0200 Message-ID: <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> In-Reply-To: <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> Date: Fri, 23 Jun 2017 12:47:57 +0200 From: "Carles Gomez Montenegro" To: "weigengyu" Cc: arun@ackl.io, lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Fri, 23 Jun 2017 12:48:30 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 10:48:36 -0000 Hi, > Hi Arun and all, > > After reading through the draft-ietf-lpwan-ipv6-static-context-hc-04, > one point needs to be exiplicit described: how many Rule IDs are used to > fragment one large IPv6 packet? What we currently have in the document is: "The Rule ID in a fragment is set to a value that indicates that the data unit being carried is a fragment." So currently we do not explicitly indicate how many Rule IDs are needed for fragments of a large IPv6 packet. The most efficient solution is to just use one Rule ID to signal "this is a fragment". However, it is probably safe to keep this open in the SCHC document, so that future technology-specific SCHC over foo documents have freedom to specify whatever better suits their needs. > By my understanding, whne one IPv6 packet is fragmented, it adopts only > one Rule ID. > Each fragment contains the same rule ID and Dtag. > Anything wrong? DTag (if present) has to be the same in all fragments carrying the same IPv6 packet. One Rule ID to signal 'this is a fragment' is fine. > Such a way to deliver the repeated Rule ID can be suppressed. > It may be available to have the first fragement only include the Rule ID > while containing the Dtag. > And the following successive fragments have the Dtage without the Rule ID. > The receiver can get the correct Rule ID from the first fragment referred > as the same Dtag. > > The Rule ID is suppressed in fragments from the second to the last. I think there are problems with this proposal. If the Rule ID of successive fragments is suppressed, how does a receiver know whether those successive data units are actual fragments or not, or how the data unit has to be processed? Thanks, Carles From nobody Fri Jun 23 03:48:51 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC25C129353 for ; Fri, 23 Jun 2017 03:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 9L0dONnVtjkn for ; Fri, 23 Jun 2017 03:48:37 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 726761200ED for ; Fri, 23 Jun 2017 03:48:37 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5NAmYrU041332; Fri, 23 Jun 2017 12:48:34 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 4F3AE1D53C1; Fri, 23 Jun 2017 12:48:33 +0200 (CEST) Received: from 10.193.93.143 by webmail.entel.upc.edu with HTTP; Fri, 23 Jun 2017 12:48:02 +0200 Message-ID: In-Reply-To: <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> Date: Fri, 23 Jun 2017 12:48:02 +0200 From: "Carles Gomez Montenegro" To: "weigengyu" Cc: arun@ackl.io, lp-wan@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Fri, 23 Jun 2017 12:48:34 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 10:48:39 -0000 Hi, > Hi Arun and all, > > After reading through the draft-ietf-lpwan-ipv6-static-context-hc-04, > one point needs to be exiplicit described: how many Rule IDs are used to > fragment one large IPv6 packet? What we currently have in the document is: "The Rule ID in a fragment is set to a value that indicates that the data unit being carried is a fragment." So currently we do not explicitly indicate how many Rule IDs are needed for fragments of a large IPv6 packet. The most efficient solution is to just use one Rule ID to signal "this is a fragment". However, it is probably safe to keep this open in the SCHC document, so that future technology-specific SCHC over foo documents have freedom to specify whatever better suits their needs. > By my understanding, whne one IPv6 packet is fragmented, it adopts only > one Rule ID. > Each fragment contains the same rule ID and Dtag. > Anything wrong? DTag (if present) has to be the same in all fragments carrying the same IPv6 packet. One Rule ID to signal 'this is a fragment' is fine. > Such a way to deliver the repeated Rule ID can be suppressed. > It may be available to have the first fragement only include the Rule ID > while containing the Dtag. > And the following successive fragments have the Dtage without the Rule ID. > The receiver can get the correct Rule ID from the first fragment referred > as the same Dtag. > > The Rule ID is suppressed in fragments from the second to the last. I think there are problems with this proposal. If the Rule ID of successive fragments is suppressed, how does a receiver know whether those successive data units are actual fragments or not, or how the data unit has to be processed? Thanks, Carles From nobody Fri Jun 23 05:09:07 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A0112773A for ; Fri, 23 Jun 2017 05:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 2oLHHZYu_dBj for ; Fri, 23 Jun 2017 05:09:01 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.2.193]) by ietfa.amsl.com (Postfix) with ESMTP id 89613126B6D for ; Fri, 23 Jun 2017 05:09:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 44D4B1005E6 for ; Fri, 23 Jun 2017 14:09:00 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id rLErYTgIitEi for ; Fri, 23 Jun 2017 14:08:59 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 5B2E31005E4 for ; Fri, 23 Jun 2017 14:08:59 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy120.enst.fr 5B2E31005E4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1498219739; bh=nG5zYXRF2MZooaItIHiK5Y/SPA1PuG/+5EfZrL4TjUU=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=Ww7EJIVq6ifyEqJQYtoshKAVr105yjpnPnGRGeUv43OCUf3fuoGQDx8a/EP6ttFly smyGz8aMxkq0N9yWXfTo+3jcSp/59JfxPUqBBSvaiM9eCoPeTElyWDaGQh/fGu11lS h3zTDUwLmkV4rWQVcIrcJhJUcQseIdY69pZK9GKw= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 2ZchpNN7AC8U for ; Fri, 23 Jun 2017 14:08:59 +0200 (CEST) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) by zproxy120.enst.fr (Postfix) with ESMTPSA id E95181005D5 for ; Fri, 23 Jun 2017 14:08:58 +0200 (CEST) Received: by mail-ua0-f181.google.com with SMTP id g40so35345458uaa.3 for ; Fri, 23 Jun 2017 05:08:58 -0700 (PDT) X-Gm-Message-State: AKS2vOwp2QZ55iHHj9LyTRruR0X83tIe7dW82yj0m2wRdNSufA+Lk08N tmfOMl+5KId/0eJSrrMR4gnI3yBQMA== X-Received: by 10.176.86.86 with SMTP id z22mr5798820uaa.6.1498219737719; Fri, 23 Jun 2017 05:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.61.94 with HTTP; Fri, 23 Jun 2017 05:08:17 -0700 (PDT) In-Reply-To: References: <15956_1498115484_594B6D9C_15956_13_1_D57137F0.44D52%dominique.barthel@orange.com> From: Laurent Toutain Date: Fri, 23 Jun 2017 14:08:17 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Ana Minaburo Cc: "BARTHEL Dominique IMT/OLPS" , lp-wan , Juan Carlos Zuniga Content-Type: multipart/alternative; boundary="f403045df1d043403b05529f77ff" Archived-At: Subject: Re: [lp-wan] SCHC - To pad or not to pad X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 12:09:04 -0000 --f403045df1d043403b05529f77ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All the IETF protocol I know are aligned on byte boundary, it is not possible to send a UDP payload with only 12 bits. Therefore we don't have the problem. The case Juan Carlos raised is at the margin of what we are doing but I think it is a good to take it into account, but not to explicitly :-) Laurent On Fri, Jun 23, 2017 at 11:13 AM, Ana Minaburo wrote: > Hello, > > One question about your second modification in decompression > > If we put that =E2=80=98payload is always a multiple of 8 bits=E2=80=99 w= e force the > application to complete its payload to be multiple of 8 bits before > compression, so after compression we have the same problem, isn=E2=80=99t= it? > > I suggest instead: IF after using SCHC compression and adding the payload > to the L2 frame the datagram is not multiple of 8 bits, padding may be us= ed. > > What do you think? > > Ana > > > > On 22 Jun 2017, at 10:48, Laurent Toutain atlantique.fr> wrote: > > Hi Juan Carlos > > Yes this is good point. > > In fact putting padding between header and data is not a so good idea if > the data are not themselves aligned on a byte boundary. For instance if t= he > header is 12 bit long and the data 4 bit long. If we introduce padding > between header and data the result will be 2 bytes. If we stick the data = to > the header only one byte is needed. > > The risk if the padding is added after the data is to include it into the > data (as Ethernet) and since the length is elided by compression it can = be > more tricky to solve the problem. In fact we can state that when the > payload is an IETF payload it is always bytes that are send, therefore it > is easy to solve the padding problem. When the payload is not IETF > compatible, then the payload must have a way to avoid confusion (strict > data format, length included,...) > > My feeling is that LoRa is may be more byte oriented than Sigfox, but I > don't think it is necessary to complexify the standard and the > implementation by two different behaviors. I will propose to state on the > draft =C2=A7 4.3 > > ---- > > o sending: The Rule ID is sent to the other end followed by > information resulting from the compression of header fields > *, directly followed by the payload.* This *The result of field com= pression is* > information is sent in the order expressed in the Rule for the > matching fields. The way the Rule ID is sent depends on the > specific LPWAN layer two technology and will be specified in a > specific document, and is out of the scope of this document. For > example, it can be either included in a Layer 2 header or sent in > the first byte of the L2 payload. (cf. Figure 4). > > > > > > o decompression: In both directions, The receiver identifies the > sender through its device-id (e.g. MAC address) and selects the > appropriate Rule through the Rule ID. This Rule gives the > compressed header format and associates these values to header > fields. It applies the CDA action to reconstruct the original > header fields. The CDA application order can be different of the > order given by the Rule. For instance Compute-* may be applied at > end, after the other CDAs. > > > * Payload is always a multiple of 8 bits, so the last bit of a L2 payloa= d* > > * must be ignored. * > > > > > +--- ... ---+-------------- ... --------------+*-------------+*--+ > | Rule ID |Compressed Hdr Fields information| * payload |//|* > +--- ... ---+-------------- ... --------------+*-------------+--+* > > > On Thu, Jun 22, 2017 at 9:11 AM, wrote: > >> Hi Juan Carlos, >> >> Good point. I think your understanding is correct, and I see your point. >> It seems to me that we don't have to mandate the padding behaviour in th= e >> generic SCHC document. >> Each SCHC-over-foo derivation could make its own decision regarding >> padding or not and impose it on the implementors. >> Or this could even be a flag in the SCHC compressor/decompressor state, >> leaving the decision to pad or not to the integrator. >> Comments ? >> Best regards >> >> Dominique >> >> De : lp-wan on behalf of Juan Carlos Zuniga < >> juancarlos.zuniga@sigfox.com> >> Date : Wednesday 21 June 2017 18:42 >> =C3=80 : Laurent Toutain >> Cc : lp-wan >> Objet : [lp-wan] SCHC - To pad or not to pad >> >> Hi Laurent, >> >> >> >> In the call you proposed padding in-between SCHC header and Payload Data= . >> However, seems to me that this would limit the (already small) amount of >> bits available for Data. >> >> >> >> For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11 >> bits would be padded up to 16, leaving only 48 available bits for data >> instead of 53. >> >> >> >> Is my understanding correct? >> >> >> >> Best, >> >> >> >> Juan Carlos >> >> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >> >> > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > > > --f403045df1d043403b05529f77ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All the IETF protocol I know are aligned on byte boun= dary, it is not possible to send a UDP payload with only 12 bits. Therefore= we don't have the problem. The case Juan Carlos raised is at the margi= n of what we are doing but I think it is a good to take it into account, bu= t not to explicitly :-)

Laurent

On Fri, Jun 23, 2017 at 11:13 AM, Ana = Minaburo <ana@ackl.io> wrote:
Hello,

One question ab= out your second modification in decompression

If w= e put that =E2=80=98payload is always a multiple of 8 bits=E2=80=99 we forc= e the application to complete its payload to be multiple of 8 bits before c= ompression, so after compression we have the same problem, isn=E2=80=99t it= ?

I suggest instead: IF after using SCHC compressi= on and adding the payload to the L2 frame the datagram is not multiple of 8= bits, padding may be used.

What do you think?

Ana


=
On 22 Jun 2017, at 10:48, Laurent T= outain <Laurent.Toutain@imt-atlantique.fr> wrote:

= Hi Juan Carlos

Yes this is good point.

In fac= t putting padding between header and data is not a so good idea if the data= are not themselves aligned on a byte boundary. For instance if the header = is 12 bit long and the data 4 bit long. If we introduce padding between hea= der and data the result will be 2 bytes. If we stick the data to the header= only one byte is needed.

The risk if the padding is added after th= e data is to include it into the data (as Ethernet) and since the length is= elided=C2=A0 by compression it can be more tricky to solve the problem. In= fact we can state that when the payload is an IETF payload it is always by= tes that are send, therefore it is easy to solve the padding problem. When = the payload is not IETF compatible, then the payload must have a way to avo= id confusion (strict data format, length included,...)

My= feeling is that LoRa is may be more byte oriented than Sigfox, but I don&#= 39;t think it is necessary to complexify the standard and the implementatio= n by two different behaviors. I will propose to state on the draft =C2=A7 4= .3

=C2=A0 ----
o  sending: The Rule ID is sent to the other =
end followed by
      information resulting from the compression of header fields, direc=
tly followed
      by the payload.  This The result of field compression is
      information is sent in the order expressed in the Rule for the
      matching fields.  The way the Rule ID is sent depends on the
      specific LPWAN layer two technology and will be specified in a
      specific document, and is out of the scope of this document.  For
      example, it can be either included in a Layer 2 header or sent in
      the first byte of the L2 payload. (cf.  Figure 4). 
      =C2=A0



=C2=A0o  decompression: In b=
oth directions, The receiver identifies the
      sender through its device-id (e.g.  MAC address) and selects the
      appropriate Rule through the Rule ID.  This Rule gives the
      compressed header format and associates these values to header
      fields.  It applies the CDA action to reconstruct the original
      header fields.  The CDA application order can be different of the
      order given by the Rule.  For instance Compute-* may be applied at
      end, after the other CDAs.

      Payload is alwa=
ys a multiple of 8 bits, so the last bit of a L2 payload
=
      must be ignored.  



  =C2=A0+--- ... =
---+-------------- ... --------------+-------------+--+
   |  Rule ID  |Compressed Hdr Fields information|   payload   |//|
   +--- ... ---+-------------- ... --------------+-------------+--+=

= On Thu, Jun 22, 2017 at 9:11 AM, <dominique.barthel@orange.com= > wrote:
Hi Juan Carlos,

Good point. I think your understanding is correct, and I see your poin= t.
It seems to me that we don't have to mandate the padding behaviour= in the generic SCHC document.
Each SCHC-over-foo derivation could make its own decision regarding pa= dding or not and impose it on the implementors.
Or this could even be a flag in the SCHC compressor/decompressor state= , leaving the decision to pad or not to the integrator.
Comments ?
Best regards

Dominique

De=C2=A0: lp-wan <lp-wan-bounces@ietf.org&= gt; on behalf of Juan Carlos Zuniga <juancarlos.zuniga@sigfox.com>
Date=C2=A0: Wednesday 21 June 2017 = 18:42
=C3=80=C2=A0: Laurent Toutain <<= a href=3D"mailto:laurent.toutain@imt-atlantique.fr" target=3D"_blank">laure= nt.toutain@imt-atlantique.fr>
Cc=C2=A0: lp-wan <lp-wan@ietf.org>
Objet=C2=A0: [lp-wan] SCHC - To pad= or not to pad

Hi Laurent,

=C2=A0

In the cal= l you proposed padding in-between SCHC header and Payload Data. However, se= ems to me that this would limit the (already small) amount of bits availabl= e for Data.

=C2=A0

For instance, in a 64-bit Sigfox DL frame, an eventual SCHC header of 11 bits would be padded up to 16, leaving only 4= 8 available bits for data instead of 53.

=C2=A0

Is my underst= anding correct?

=C2=A0

Best,

<= u>=C2=A0

Juan Carlos

=C2=A0

 
____________________________________________________________=
_____________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list=
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan


--f403045df1d043403b05529f77ff-- From nobody Fri Jun 23 07:26:08 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1CD1275C5 for ; Fri, 23 Jun 2017 07:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, 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 CKoM-X2RklUW for ; Fri, 23 Jun 2017 07:26:02 -0700 (PDT) Received: from smtp-6-48.vip.sina.com.cn (r3-61.sinamail.sina.com.cn [202.108.3.61]) by ietfa.amsl.com (Postfix) with SMTP id 460A9127337 for ; Fri, 23 Jun 2017 07:26:00 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.246.135.90]) by vip.sina.com with ESMTP 23 Jun 2017 22:25:55 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 33267965568 Message-ID: <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> From: "weigengyu" To: "Carles Gomez Montenegro" Cc: , References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> In-Reply-To: <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> Date: Fri, 23 Jun 2017 22:25:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 14:26:06 -0000 Hi, > I think there are problems with this proposal. If the Rule ID of > successive fragments is suppressed, how does a receiver know whether those > successive data units are actual fragments or not, or how the data unit > has to be processed? The Dtag can be used for knowing "whether those successive data units are actual fragments or not, or how the data unit has to be processed. " For example, if an IPv6 packet is partitioned into two fragments, the first fragment inclues a Rule ID and a Dtag, the second fragment includes the Dtag without the Rule ID. After the first fragment is sent, the Rule ID is binded with a Dtag for this packet. The receiver can know which the Rule ID is used by the Dtag. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carles Gomez Montenegro Sent: Friday, June 23, 2017 6:47 PM To: weigengyu Cc: arun@ackl.io ; lp-wan@ietf.org Subject: Re: [lp-wan] Fw: re-order header field request Hi, > Hi Arun and all, > > After reading through the draft-ietf-lpwan-ipv6-static-context-hc-04, > one point needs to be exiplicit described: how many Rule IDs are used to > fragment one large IPv6 packet? What we currently have in the document is: "The Rule ID in a fragment is set to a value that indicates that the data unit being carried is a fragment." So currently we do not explicitly indicate how many Rule IDs are needed for fragments of a large IPv6 packet. The most efficient solution is to just use one Rule ID to signal "this is a fragment". However, it is probably safe to keep this open in the SCHC document, so that future technology-specific SCHC over foo documents have freedom to specify whatever better suits their needs. > By my understanding, whne one IPv6 packet is fragmented, it adopts only > one Rule ID. > Each fragment contains the same rule ID and Dtag. > Anything wrong? DTag (if present) has to be the same in all fragments carrying the same IPv6 packet. One Rule ID to signal 'this is a fragment' is fine. > Such a way to deliver the repeated Rule ID can be suppressed. > It may be available to have the first fragement only include the Rule ID > while containing the Dtag. > And the following successive fragments have the Dtage without the Rule ID. > The receiver can get the correct Rule ID from the first fragment referred > as the same Dtag. > > The Rule ID is suppressed in fragments from the second to the last. I think there are problems with this proposal. If the Rule ID of successive fragments is suppressed, how does a receiver know whether those successive data units are actual fragments or not, or how the data unit has to be processed? Thanks, Carles From nobody Fri Jun 23 10:11:36 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA4212762F for ; Fri, 23 Jun 2017 10:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sigfoxgroup.onmicrosoft.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 vuWX71JV_Fd5 for ; Fri, 23 Jun 2017 10:11:31 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10095.outbound.protection.outlook.com [40.107.1.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418941241FC for ; Fri, 23 Jun 2017 10:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigfoxgroup.onmicrosoft.com; s=selector1-sigfox-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=irubaUXuWocq+0b7sLi5479w8S4FuJnO3JA9eHePqOk=; b=EYMuBiSLDocwjVumVLaHNlJNzJuLJ0ExDLHYeh37MI14dy8pzfo49VLonkEwblphYM1cnDhd1i48K39PZA5+NXIS6ZvTA6zHJNzI++MgInLGDrTGBSy5RnWuu5Hs2LTPUEybdtWKf9boEsEWs1R1E5RC9Qc5TwTJvtuhjtS+FxE= Received: from DB6PR08MB2679.eurprd08.prod.outlook.com (10.175.235.12) by DB6PR08MB2678.eurprd08.prod.outlook.com (10.175.235.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Fri, 23 Jun 2017 17:11:26 +0000 Received: from DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::4c13:9f9a:cdb3:bb21]) by DB6PR08MB2679.eurprd08.prod.outlook.com ([fe80::4c13:9f9a:cdb3:bb21%13]) with mapi id 15.01.1199.015; Fri, 23 Jun 2017 17:11:27 +0000 From: Juan Carlos Zuniga To: Laurent Toutain , Ana Minaburo CC: BARTHEL Dominique IMT/OLPS , lp-wan Thread-Topic: [lp-wan] SCHC - To pad or not to pad Thread-Index: AQHS6ybB81GOZs0+UEeR+3Au3Ky5VaIwkl2AgAGZSwCAADDVgIAAVGLA Date: Fri, 23 Jun 2017 17:11:27 +0000 Message-ID: References: <15956_1498115484_594B6D9C_15956_13_1_D57137F0.44D52%dominique.barthel@orange.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: imt-atlantique.fr; dkim=none (message not signed) header.d=none;imt-atlantique.fr; dmarc=none action=none header.from=sigfox.com; x-originating-ip: [198.58.159.155] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR08MB2678; 7:8qNTouSQ5RIrQirmFgD8vWz/Wuxr6RQOMZ8RYHakr4M5zGzbLp40aGVMIPmfqg9ygBq/JvsDVvIgxhXSYQmH19vqYkpKSZp3mY/076pYA7Ub6YiWUSfMgvcih6jAlULLEuWKcFTHx3iEjF93doyT76TJ/bbVrT/qn/foLhliSdXPXjV8hPMSxJ97XfntBLT/ykUncRgVtKYECqwTy4fIKc1HHkEGboGfySBq9o1cSdkiucsQWaj2v6PU1EQCKkdDx8fcB7C2wblM8OcFje6JNRzSWzeLWFLPZ/Q/wTMucJvRB4eQxsIGZDg/9nhzJUdaivkioNH/4Fy2jQwRUqsi9PrptyTgjqkb9nMpieccCqZrWYpZGCI6XNbfAE0d9DAQjw8r5OwpATVqbNgIWoccA3qy0+eDpbUbTDO0yWrxVyJvFR2jUO6XYa0WXUeyPOYsSZ18ZLS+yu1HhYvVxmrFOAS5ril8xCL5tpDAEDRWAnOoYsrPX3VgKCf7FzGNFKQRVeoPQf6nCMIVo5/OxxILaHNM3e4kfn0L1ku3/YfZX41WmH6Zgq8bYlXGkOHXFqyb5KOqiUqPLnp4hUonAeftelJTAzZXMAQGNcH+b06BdO/8WLG5B8xtYfbBR+ptKFo34STc1YivCiDeJcUUhFk6b8MaAMicf4stwsAOgmvTF+tPIyby/51twIpFJjW+HNHv8719EypxU85dQzjqpTlKcaM6rwe04IX+scTFUrXR2m25Ky1E/u0S0cQE78r5RZ415eIKjibYyqoD8pRgvdsI9pTU8S+dNLW+N57GxcEOlLM= x-ms-office365-filtering-correlation-id: d46e0401-66c9-4c4d-f52f-08d4ba5ae254 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB6PR08MB2678; x-ms-traffictypediagnostic: DB6PR08MB2678: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR08MB2678; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR08MB2678; x-forefront-prvs: 0347410860 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39840400002)(39400400002)(377454003)(51444003)(24454002)(5660300001)(189998001)(25786009)(606005)(6436002)(33656002)(4326008)(790700001)(53936002)(74316002)(6506006)(2906002)(2900100001)(55016002)(7906003)(478600001)(54906002)(7696004)(93886004)(6246003)(8676002)(76176999)(50986999)(54356999)(2950100002)(86362001)(6306002)(3280700002)(54896002)(3660700001)(9686003)(38730400002)(236005)(99286003)(53546010)(14454004)(81166006)(6116002)(102836003)(3846002)(966005)(8936002)(5250100002)(229853002)(66066001)(5890100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR08MB2678; H:DB6PR08MB2679.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR08MB2679E2FCED5464AEBB8E188789D80DB6PR08MB2679eurp_" MIME-Version: 1.0 X-OriginatorOrg: sigfox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2017 17:11:27.1561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcbc8bb1-061e-4b94-9f70-3ad917b0c8d3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2678 Archived-At: Subject: Re: [lp-wan] SCHC - To pad or not to pad X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 17:11:35 -0000 --_000_DB6PR08MB2679E2FCED5464AEBB8E188789D80DB6PR08MB2679eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGF1cmVudCwgQW5hLA0KDQpGcm9tOiBMYXVyZW50IFRvdXRhaW4gW21haWx0bzpsYXVyZW50 LnRvdXRhaW5AaW10LWF0bGFudGlxdWUuZnJdDQpTZW50OiBKdW5lIDIzLCAyMDE3IDg6MDggQU0N ClRvOiBBbmEgTWluYWJ1cm8gPGFuYUBhY2tsLmlvPg0KQ2M6IEJBUlRIRUwgRG9taW5pcXVlIElN VC9PTFBTIDxkb21pbmlxdWUuYmFydGhlbEBvcmFuZ2UuY29tPjsgbHAtd2FuIDxscC13YW5AaWV0 Zi5vcmc+OyBKdWFuIENhcmxvcyBadW5pZ2EgPGp1YW5jYXJsb3MuenVuaWdhQHNpZ2ZveC5jb20+ DQpTdWJqZWN0OiBSZTogW2xwLXdhbl0gU0NIQyAtIFRvIHBhZCBvciBub3QgdG8gcGFkDQoNCkFs bCB0aGUgSUVURiBwcm90b2NvbCBJIGtub3cgYXJlIGFsaWduZWQgb24gYnl0ZSBib3VuZGFyeSwg aXQgaXMgbm90IHBvc3NpYmxlIHRvIHNlbmQgYSBVRFAgcGF5bG9hZCB3aXRoIG9ubHkgMTIgYml0 cy4NCltKQ1pdIFlvdSBtZWFuOiDigJxub3QgeWV04oCdIDspDQpUaGVyZWZvcmUgd2UgZG9uJ3Qg aGF2ZSB0aGUgcHJvYmxlbS4gVGhlIGNhc2UgSnVhbiBDYXJsb3MgcmFpc2VkIGlzIGF0IHRoZSBt YXJnaW4gb2Ygd2hhdCB3ZSBhcmUgZG9pbmcgYnV0IEkgdGhpbmsgaXQgaXMgYSBnb29kIHRvIHRh a2UgaXQgaW50byBhY2NvdW50LCBidXQgbm90IHRvIGV4cGxpY2l0bHkgOi0pDQpbSkNaXSBJIGFn cmVlLiBIb3dldmVyLCBJIHRoaW5rIHRoYXQgdGhlIHRleHQgQW5hIGlzIHByb3Bvc2luZyBpcyBh IGdvb2QgY29tcHJvbWlzZS4NCkJlc3QsDQpKdWFuIENhcmxvcw0KTGF1cmVudA0KDQpPbiBGcmks IEp1biAyMywgMjAxNyBhdCAxMToxMyBBTSwgQW5hIE1pbmFidXJvIDxhbmFAYWNrbC5pbzxtYWls dG86YW5hQGFja2wuaW8+PiB3cm90ZToNCkhlbGxvLA0KDQpPbmUgcXVlc3Rpb24gYWJvdXQgeW91 ciBzZWNvbmQgbW9kaWZpY2F0aW9uIGluIGRlY29tcHJlc3Npb24NCg0KSWYgd2UgcHV0IHRoYXQg 4oCYcGF5bG9hZCBpcyBhbHdheXMgYSBtdWx0aXBsZSBvZiA4IGJpdHPigJkgd2UgZm9yY2UgdGhl IGFwcGxpY2F0aW9uIHRvIGNvbXBsZXRlIGl0cyBwYXlsb2FkIHRvIGJlIG11bHRpcGxlIG9mIDgg Yml0cyBiZWZvcmUgY29tcHJlc3Npb24sIHNvIGFmdGVyIGNvbXByZXNzaW9uIHdlIGhhdmUgdGhl IHNhbWUgcHJvYmxlbSwgaXNu4oCZdCBpdD8NCg0KSSBzdWdnZXN0IGluc3RlYWQ6IElGIGFmdGVy IHVzaW5nIFNDSEMgY29tcHJlc3Npb24gYW5kIGFkZGluZyB0aGUgcGF5bG9hZCB0byB0aGUgTDIg ZnJhbWUgdGhlIGRhdGFncmFtIGlzIG5vdCBtdWx0aXBsZSBvZiA4IGJpdHMsIHBhZGRpbmcgbWF5 IGJlIHVzZWQuDQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpBbmENCg0KDQoNCk9uIDIyIEp1biAy MDE3LCBhdCAxMDo0OCwgTGF1cmVudCBUb3V0YWluIDxMYXVyZW50LlRvdXRhaW5AaW10LWF0bGFu dGlxdWUuZnI8bWFpbHRvOkxhdXJlbnQuVG91dGFpbkBpbXQtYXRsYW50aXF1ZS5mcj4+IHdyb3Rl Og0KDQpIaSBKdWFuIENhcmxvcw0KDQpZZXMgdGhpcyBpcyBnb29kIHBvaW50Lg0KSW4gZmFjdCBw dXR0aW5nIHBhZGRpbmcgYmV0d2VlbiBoZWFkZXIgYW5kIGRhdGEgaXMgbm90IGEgc28gZ29vZCBp ZGVhIGlmIHRoZSBkYXRhIGFyZSBub3QgdGhlbXNlbHZlcyBhbGlnbmVkIG9uIGEgYnl0ZSBib3Vu ZGFyeS4gRm9yIGluc3RhbmNlIGlmIHRoZSBoZWFkZXIgaXMgMTIgYml0IGxvbmcgYW5kIHRoZSBk YXRhIDQgYml0IGxvbmcuIElmIHdlIGludHJvZHVjZSBwYWRkaW5nIGJldHdlZW4gaGVhZGVyIGFu ZCBkYXRhIHRoZSByZXN1bHQgd2lsbCBiZSAyIGJ5dGVzLiBJZiB3ZSBzdGljayB0aGUgZGF0YSB0 byB0aGUgaGVhZGVyIG9ubHkgb25lIGJ5dGUgaXMgbmVlZGVkLg0KDQpUaGUgcmlzayBpZiB0aGUg cGFkZGluZyBpcyBhZGRlZCBhZnRlciB0aGUgZGF0YSBpcyB0byBpbmNsdWRlIGl0IGludG8gdGhl IGRhdGEgKGFzIEV0aGVybmV0KSBhbmQgc2luY2UgdGhlIGxlbmd0aCBpcyBlbGlkZWQgIGJ5IGNv bXByZXNzaW9uIGl0IGNhbiBiZSBtb3JlIHRyaWNreSB0byBzb2x2ZSB0aGUgcHJvYmxlbS4gSW4g ZmFjdCB3ZSBjYW4gc3RhdGUgdGhhdCB3aGVuIHRoZSBwYXlsb2FkIGlzIGFuIElFVEYgcGF5bG9h ZCBpdCBpcyBhbHdheXMgYnl0ZXMgdGhhdCBhcmUgc2VuZCwgdGhlcmVmb3JlIGl0IGlzIGVhc3kg dG8gc29sdmUgdGhlIHBhZGRpbmcgcHJvYmxlbS4gV2hlbiB0aGUgcGF5bG9hZCBpcyBub3QgSUVU RiBjb21wYXRpYmxlLCB0aGVuIHRoZSBwYXlsb2FkIG11c3QgaGF2ZSBhIHdheSB0byBhdm9pZCBj b25mdXNpb24gKHN0cmljdCBkYXRhIGZvcm1hdCwgbGVuZ3RoIGluY2x1ZGVkLC4uLikNCk15IGZl ZWxpbmcgaXMgdGhhdCBMb1JhIGlzIG1heSBiZSBtb3JlIGJ5dGUgb3JpZW50ZWQgdGhhbiBTaWdm b3gsIGJ1dCBJIGRvbid0IHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSB0byBjb21wbGV4aWZ5IHRoZSBz dGFuZGFyZCBhbmQgdGhlIGltcGxlbWVudGF0aW9uIGJ5IHR3byBkaWZmZXJlbnQgYmVoYXZpb3Jz LiBJIHdpbGwgcHJvcG9zZSB0byBzdGF0ZSBvbiB0aGUgZHJhZnQgwqcgNC4zDQoNCiAgLS0tLQ0K DQpvICBzZW5kaW5nOiBUaGUgUnVsZSBJRCBpcyBzZW50IHRvIHRoZSBvdGhlciBlbmQgZm9sbG93 ZWQgYnkNCg0KICAgICAgaW5mb3JtYXRpb24gcmVzdWx0aW5nIGZyb20gdGhlIGNvbXByZXNzaW9u IG9mIGhlYWRlciBmaWVsZHMsIGRpcmVjdGx5IGZvbGxvd2VkDQogICAgICBieSB0aGUgcGF5bG9h ZC4gIFRoaXMgVGhlIHJlc3VsdCBvZiBmaWVsZCBjb21wcmVzc2lvbiBpcw0KDQogICAgICBpbmZv cm1hdGlvbiBpcyBzZW50IGluIHRoZSBvcmRlciBleHByZXNzZWQgaW4gdGhlIFJ1bGUgZm9yIHRo ZQ0KDQogICAgICBtYXRjaGluZyBmaWVsZHMuICBUaGUgd2F5IHRoZSBSdWxlIElEIGlzIHNlbnQg ZGVwZW5kcyBvbiB0aGUNCg0KICAgICAgc3BlY2lmaWMgTFBXQU4gbGF5ZXIgdHdvIHRlY2hub2xv Z3kgYW5kIHdpbGwgYmUgc3BlY2lmaWVkIGluIGENCg0KICAgICAgc3BlY2lmaWMgZG9jdW1lbnQs IGFuZCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBGb3INCg0KICAgICAg ZXhhbXBsZSwgaXQgY2FuIGJlIGVpdGhlciBpbmNsdWRlZCBpbiBhIExheWVyIDIgaGVhZGVyIG9y IHNlbnQgaW4NCg0KICAgICAgdGhlIGZpcnN0IGJ5dGUgb2YgdGhlIEwyIHBheWxvYWQuIChjZi4g IEZpZ3VyZSA0KS4NCg0KDQoNCg0KDQoNCiBvICBkZWNvbXByZXNzaW9uOiBJbiBib3RoIGRpcmVj dGlvbnMsIFRoZSByZWNlaXZlciBpZGVudGlmaWVzIHRoZQ0KDQogICAgICBzZW5kZXIgdGhyb3Vn aCBpdHMgZGV2aWNlLWlkIChlLmcuICBNQUMgYWRkcmVzcykgYW5kIHNlbGVjdHMgdGhlDQoNCiAg ICAgIGFwcHJvcHJpYXRlIFJ1bGUgdGhyb3VnaCB0aGUgUnVsZSBJRC4gIFRoaXMgUnVsZSBnaXZl cyB0aGUNCg0KICAgICAgY29tcHJlc3NlZCBoZWFkZXIgZm9ybWF0IGFuZCBhc3NvY2lhdGVzIHRo ZXNlIHZhbHVlcyB0byBoZWFkZXINCg0KICAgICAgZmllbGRzLiAgSXQgYXBwbGllcyB0aGUgQ0RB IGFjdGlvbiB0byByZWNvbnN0cnVjdCB0aGUgb3JpZ2luYWwNCg0KICAgICAgaGVhZGVyIGZpZWxk cy4gIFRoZSBDREEgYXBwbGljYXRpb24gb3JkZXIgY2FuIGJlIGRpZmZlcmVudCBvZiB0aGUNCg0K ICAgICAgb3JkZXIgZ2l2ZW4gYnkgdGhlIFJ1bGUuICBGb3IgaW5zdGFuY2UgQ29tcHV0ZS0qIG1h eSBiZSBhcHBsaWVkIGF0DQoNCiAgICAgIGVuZCwgYWZ0ZXIgdGhlIG90aGVyIENEQXMuDQoNCiAg ICAgIFBheWxvYWQgaXMgYWx3YXlzIGEgbXVsdGlwbGUgb2YgOCBiaXRzLCBzbyB0aGUgbGFzdCBi aXQgb2YgYSBMMiBwYXlsb2FkDQoNCiAgICAgIG11c3QgYmUgaWdub3JlZC4NCg0KDQoNCiAgICst LS0gLi4uIC0tLSstLS0tLS0tLS0tLS0tLSAuLi4gLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LSstLSsNCg0KICAgfCAgUnVsZSBJRCAgfENvbXByZXNzZWQgSGRyIEZpZWxkcyBpbmZvcm1hdGlv bnwgICBwYXlsb2FkICAgfC8vfA0KDQogICArLS0tIC4uLiAtLS0rLS0tLS0tLS0tLS0tLS0gLi4u IC0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0rDQoNCk9uIFRodSwgSnVuIDIyLCAyMDE3 IGF0IDk6MTEgQU0sIDxkb21pbmlxdWUuYmFydGhlbEBvcmFuZ2UuY29tPG1haWx0bzpkb21pbmlx dWUuYmFydGhlbEBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIaSBKdWFuIENhcmxvcywNCg0KR29vZCBw b2ludC4gSSB0aGluayB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgYW5kIEkgc2VlIHlv dXIgcG9pbnQuDQpJdCBzZWVtcyB0byBtZSB0aGF0IHdlIGRvbid0IGhhdmUgdG8gbWFuZGF0ZSB0 aGUgcGFkZGluZyBiZWhhdmlvdXIgaW4gdGhlIGdlbmVyaWMgU0NIQyBkb2N1bWVudC4NCkVhY2gg U0NIQy1vdmVyLWZvbyBkZXJpdmF0aW9uIGNvdWxkIG1ha2UgaXRzIG93biBkZWNpc2lvbiByZWdh cmRpbmcgcGFkZGluZyBvciBub3QgYW5kIGltcG9zZSBpdCBvbiB0aGUgaW1wbGVtZW50b3JzLg0K T3IgdGhpcyBjb3VsZCBldmVuIGJlIGEgZmxhZyBpbiB0aGUgU0NIQyBjb21wcmVzc29yL2RlY29t cHJlc3NvciBzdGF0ZSwgbGVhdmluZyB0aGUgZGVjaXNpb24gdG8gcGFkIG9yIG5vdCB0byB0aGUg aW50ZWdyYXRvci4NCkNvbW1lbnRzID8NCkJlc3QgcmVnYXJkcw0KDQpEb21pbmlxdWUNCg0KRGUg OiBscC13YW4gPGxwLXdhbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpscC13YW4tYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBKdWFuIENhcmxvcyBadW5pZ2EgPGp1YW5jYXJsb3MuenVu aWdhQHNpZ2ZveC5jb208bWFpbHRvOmp1YW5jYXJsb3MuenVuaWdhQHNpZ2ZveC5jb20+Pg0KRGF0 ZSA6IFdlZG5lc2RheSAyMSBKdW5lIDIwMTcgMTg6NDINCsOAIDogTGF1cmVudCBUb3V0YWluIDxs YXVyZW50LnRvdXRhaW5AaW10LWF0bGFudGlxdWUuZnI8bWFpbHRvOmxhdXJlbnQudG91dGFpbkBp bXQtYXRsYW50aXF1ZS5mcj4+DQpDYyA6IGxwLXdhbiA8bHAtd2FuQGlldGYub3JnPG1haWx0bzps cC13YW5AaWV0Zi5vcmc+Pg0KT2JqZXQgOiBbbHAtd2FuXSBTQ0hDIC0gVG8gcGFkIG9yIG5vdCB0 byBwYWQNCg0KSGkgTGF1cmVudCwNCg0KSW4gdGhlIGNhbGwgeW91IHByb3Bvc2VkIHBhZGRpbmcg aW4tYmV0d2VlbiBTQ0hDIGhlYWRlciBhbmQgUGF5bG9hZCBEYXRhLiBIb3dldmVyLCBzZWVtcyB0 byBtZSB0aGF0IHRoaXMgd291bGQgbGltaXQgdGhlIChhbHJlYWR5IHNtYWxsKSBhbW91bnQgb2Yg Yml0cyBhdmFpbGFibGUgZm9yIERhdGEuDQoNCkZvciBpbnN0YW5jZSwgaW4gYSA2NC1iaXQgU2ln Zm94IERMIGZyYW1lLCBhbiBldmVudHVhbCBTQ0hDIGhlYWRlciBvZiAxMSBiaXRzIHdvdWxkIGJl IHBhZGRlZCB1cCB0byAxNiwgbGVhdmluZyBvbmx5IDQ4IGF2YWlsYWJsZSBiaXRzIGZvciBkYXRh IGluc3RlYWQgb2YgNTMuDQoNCklzIG15IHVuZGVyc3RhbmRpbmcgY29ycmVjdD8NCg0KQmVzdCwN Cg0KSnVhbiBDYXJsb3MNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwN Cg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0 ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu DQoNClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCmxwLXdhbiBtYWlsaW5nIGxpc3QNCmxwLXdhbkBpZXRmLm9yZzxtYWlsdG86bHAt d2FuQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13 YW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxw LXdhbiBtYWlsaW5nIGxpc3QNCmxwLXdhbkBpZXRmLm9yZzxtYWlsdG86bHAtd2FuQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13YW4NCg0KDQo= --_000_DB6PR08MB2679E2FCED5464AEBB8E188789D80DB6PR08MB2679eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpi DQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1DQTt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgTGF1cmVudCwgQW5hLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExhdXJlbnQgVG91 dGFpbiBbbWFpbHRvOmxhdXJlbnQudG91dGFpbkBpbXQtYXRsYW50aXF1ZS5mcl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBKdW5lIDIzLCAyMDE3IDg6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IEFuYSBNaW5h YnVybyAmbHQ7YW5hQGFja2wuaW8mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCQVJUSEVMIERvbWluaXF1 ZSBJTVQvT0xQUyAmbHQ7ZG9taW5pcXVlLmJhcnRoZWxAb3JhbmdlLmNvbSZndDs7IGxwLXdhbiAm bHQ7bHAtd2FuQGlldGYub3JnJmd0OzsgSnVhbiBDYXJsb3MgWnVuaWdhICZsdDtqdWFuY2FybG9z Lnp1bmlnYUBzaWdmb3guY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2xwLXdhbl0g U0NIQyAtIFRvIHBhZCBvciBub3QgdG8gcGFkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPkFsbCB0aGUgSUVURiBwcm90b2NvbCBJIGtub3cgYXJlIGFsaWduZWQgb24gYnl0ZSBib3Vu ZGFyeSwgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHNlbmQgYSBVRFAgcGF5bG9hZCB3aXRoIG9ubHkg MTIgYml0cy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltKQ1pdIFlvdSBtZWFu OiDigJxub3QgeWV04oCdIDspPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZXJlZm9yZSB3ZSBk b24ndCBoYXZlIHRoZSBwcm9ibGVtLiBUaGUgY2FzZSBKdWFuIENhcmxvcyByYWlzZWQgaXMgYXQg dGhlIG1hcmdpbiBvZiB3aGF0IHdlIGFyZSBkb2luZyBidXQgSSB0aGluayBpdCBpcyBhIGdvb2Qg dG8gdGFrZSBpdCBpbnRvIGFjY291bnQsIGJ1dCBub3QgdG8gZXhwbGljaXRseSA6LSk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bSkNaXSBJIGFncmVlLiBIb3dldmVyLCBJIHRoaW5r IHRoYXQgdGhlIHRleHQgQW5hIGlzIHByb3Bvc2luZyBpcyBhIGdvb2QgY29tcHJvbWlzZS48bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CZXN0LDxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkp1YW4gQ2FybG9zDQo8L3Nw YW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGF1cmVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdW4gMjMsIDIwMTcgYXQgMTE6MTMgQU0sIEFu YSBNaW5hYnVybyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuYUBhY2tsLmlvIiB0YXJnZXQ9Il9ibGFu ayI+YW5hQGFja2wuaW88L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8sPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgcXVlc3Rpb24gYWJvdXQgeW91ciBzZWNvbmQg bW9kaWZpY2F0aW9uIGluIGRlY29tcHJlc3Npb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgcHV0IHRoYXQg4oCYcGF5bG9hZCBpcyBh bHdheXMgYSBtdWx0aXBsZSBvZiA4IGJpdHPigJkgd2UgZm9yY2UgdGhlIGFwcGxpY2F0aW9uIHRv IGNvbXBsZXRlIGl0cyBwYXlsb2FkIHRvIGJlIG11bHRpcGxlIG9mIDggYml0cyBiZWZvcmUgY29t cHJlc3Npb24sIHNvIGFmdGVyIGNvbXByZXNzaW9uIHdlIGhhdmUgdGhlIHNhbWUgcHJvYmxlbSwg aXNu4oCZdCBpdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBzdWdnZXN0IGluc3RlYWQ6IElGIGFmdGVyIHVzaW5nIFNDSEMgY29tcHJlc3Np b24gYW5kIGFkZGluZyB0aGUgcGF5bG9hZCB0byB0aGUgTDIgZnJhbWUgdGhlIGRhdGFncmFtIGlz IG5vdCBtdWx0aXBsZSBvZiA4IGJpdHMsIHBhZGRpbmcgbWF5IGJlIHVzZWQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG8geW91IHRo aW5rPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij5BbmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMiBKdW4gMjAxNywgYXQgMTA6 NDgsIExhdXJlbnQgVG91dGFpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkxhdXJlbnQuVG91dGFpbkBp bXQtYXRsYW50aXF1ZS5mciIgdGFyZ2V0PSJfYmxhbmsiPkxhdXJlbnQuVG91dGFpbkBpbXQtYXRs YW50aXF1ZS5mcjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGkgSnVhbiBDYXJsb3M8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClllcyB0 aGlzIGlzIGdvb2QgcG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkluIGZhY3QgcHV0dGlu ZyBwYWRkaW5nIGJldHdlZW4gaGVhZGVyIGFuZCBkYXRhIGlzIG5vdCBhIHNvIGdvb2QgaWRlYSBp ZiB0aGUgZGF0YSBhcmUgbm90IHRoZW1zZWx2ZXMgYWxpZ25lZCBvbiBhIGJ5dGUgYm91bmRhcnku IEZvciBpbnN0YW5jZSBpZiB0aGUgaGVhZGVyIGlzIDEyIGJpdCBsb25nIGFuZCB0aGUgZGF0YSA0 IGJpdCBsb25nLiBJZiB3ZSBpbnRyb2R1Y2UNCiBwYWRkaW5nIGJldHdlZW4gaGVhZGVyIGFuZCBk YXRhIHRoZSByZXN1bHQgd2lsbCBiZSAyIGJ5dGVzLiBJZiB3ZSBzdGljayB0aGUgZGF0YSB0byB0 aGUgaGVhZGVyIG9ubHkgb25lIGJ5dGUgaXMgbmVlZGVkLg0KPGJyPg0KPGJyPg0KVGhlIHJpc2sg aWYgdGhlIHBhZGRpbmcgaXMgYWRkZWQgYWZ0ZXIgdGhlIGRhdGEgaXMgdG8gaW5jbHVkZSBpdCBp bnRvIHRoZSBkYXRhIChhcyBFdGhlcm5ldCkgYW5kIHNpbmNlIHRoZSBsZW5ndGggaXMgZWxpZGVk Jm5ic3A7IGJ5IGNvbXByZXNzaW9uIGl0IGNhbiBiZSBtb3JlIHRyaWNreSB0byBzb2x2ZSB0aGUg cHJvYmxlbS4gSW4gZmFjdCB3ZSBjYW4gc3RhdGUgdGhhdCB3aGVuIHRoZSBwYXlsb2FkIGlzIGFu IElFVEYgcGF5bG9hZCBpdCBpcyBhbHdheXMNCiBieXRlcyB0aGF0IGFyZSBzZW5kLCB0aGVyZWZv cmUgaXQgaXMgZWFzeSB0byBzb2x2ZSB0aGUgcGFkZGluZyBwcm9ibGVtLiBXaGVuIHRoZSBwYXls b2FkIGlzIG5vdCBJRVRGIGNvbXBhdGlibGUsIHRoZW4gdGhlIHBheWxvYWQgbXVzdCBoYXZlIGEg d2F5IHRvIGF2b2lkIGNvbmZ1c2lvbiAoc3RyaWN0IGRhdGEgZm9ybWF0LCBsZW5ndGggaW5jbHVk ZWQsLi4uKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TXkgZmVlbGluZyBpcyB0aGF0IExvUmEgaXMgbWF5IGJlIG1vcmUgYnl0ZSBvcmllbnRlZCB0 aGFuIFNpZ2ZveCwgYnV0IEkgZG9uJ3QgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5IHRvIGNvbXBsZXhp ZnkgdGhlIHN0YW5kYXJkIGFuZCB0aGUgaW1wbGVtZW50YXRpb24gYnkgdHdvIGRpZmZlcmVudCBi ZWhhdmlvcnMuIEkgd2lsbCBwcm9wb3NlIHRvIHN0YXRlIG9uIHRoZSBkcmFmdCDCpyA0LjM8YnI+ DQo8YnI+DQombmJzcDsgLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHByZT5vJm5ic3A7IHNlbmRpbmc6 IFRoZSBSdWxlIElEIGlzIHNlbnQgdG8gdGhlIG90aGVyIGVuZCBmb2xsb3dlZCBieTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmZvcm1hdGlv biByZXN1bHRpbmcgZnJvbSB0aGUgY29tcHJlc3Npb24gb2YgaGVhZGVyIGZpZWxkczxiPiwgZGly ZWN0bHkgZm9sbG93ZWQ8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5IHRoZSBw YXlsb2FkLjwvYj4mbmJzcDsgPHNwYW4gc3R5bGU9ImNvbG9yOiNDQ0NDQ0MiPlRoaXMgPGI+VGhl IHJlc3VsdCBvZiBmaWVsZCBjb21wcmVzc2lvbiBpczwvYj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiNDQ0NDQ0MiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBpbmZvcm1hdGlvbiBpczwvc3Bhbj4gc2VudCBpbiB0aGUgb3JkZXIgZXhwcmVz c2VkIGluIHRoZSBSdWxlIGZvciB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgbWF0Y2hpbmcgZmllbGRzLiZuYnNwOyBUaGUgd2F5IHRoZSBS dWxlIElEIGlzIHNlbnQgZGVwZW5kcyBvbiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWMgTFBXQU4gbGF5ZXIgdHdvIHRlY2hu b2xvZ3kgYW5kIHdpbGwgYmUgc3BlY2lmaWVkIGluIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWMgZG9jdW1lbnQsIGFuZCBpcyBv dXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuJm5ic3A7IEZvcjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleGFtcGxlLCBpdCBjYW4g YmUgZWl0aGVyIGluY2x1ZGVkIGluIGEgTGF5ZXIgMiBoZWFkZXIgb3Igc2VudCBpbjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgZmlyc3Qg Ynl0ZSBvZiB0aGUgTDIgcGF5bG9hZC4gKGNmLiZuYnNwOyBGaWd1cmUgNCkuIDxicj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT48YnI+Jm5ic3A7byZuYnNwOyBkZWNvbXByZXNzaW9uOiBJbiBib3RoIGRpcmVjdGlvbnMs IFRoZSByZWNlaXZlciBpZGVudGlmaWVzIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZW5kZXIgdGhyb3VnaCBpdHMgZGV2aWNlLWlkIChl LmcuJm5ic3A7IE1BQyBhZGRyZXNzKSBhbmQgc2VsZWN0cyB0aGU8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwcm9wcmlhdGUgUnVsZSB0aHJv dWdoIHRoZSBSdWxlIElELiZuYnNwOyBUaGlzIFJ1bGUgZ2l2ZXMgdGhlPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbXByZXNzZWQgaGVhZGVy IGZvcm1hdCBhbmQgYXNzb2NpYXRlcyB0aGVzZSB2YWx1ZXMgdG8gaGVhZGVyPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZpZWxkcy4mbmJzcDsg SXQgYXBwbGllcyB0aGUgQ0RBIGFjdGlvbiB0byByZWNvbnN0cnVjdCB0aGUgb3JpZ2luYWw8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGVhZGVy IGZpZWxkcy4mbmJzcDsgVGhlIENEQSBhcHBsaWNhdGlvbiBvcmRlciBjYW4gYmUgZGlmZmVyZW50 IG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBvcmRlciBnaXZlbiBieSB0aGUgUnVsZS4mbmJzcDsgRm9yIGluc3RhbmNlIENvbXB1dGUt KiBtYXkgYmUgYXBwbGllZCBhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuZCwgYWZ0ZXIg dGhlIG90aGVyIENEQXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxiPiZuYnNwOyZuYnNwO1BheWxvYWQgaXMgYWx3YXlzIGEgbXVsdGlwbGUgb2YgOCBiaXRzLCBz byB0aGUgbGFzdCBiaXQgb2YgYSBMMiBwYXlsb2FkPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtdXN0IGJlIGlnbm9yZWQuJm5ic3A7 IDwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YnI+PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJz cDsmIzQzOy0tLSAuLi4gLS0tJiM0MzstLS0tLS0tLS0tLS0tLSAuLi4gLS0tLS0tLS0tLS0tLS0m IzQzOzxiPi0tLS0tLS0tLS0tLS0mIzQzOzwvYj4tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgUnVsZSBJRCZuYnNwOyB8Q29tcHJlc3NlZCBIZHIgRmll bGRzIGluZm9ybWF0aW9ufCZuYnNwOyA8Yj4mbmJzcDtwYXlsb2FkJm5ic3A7Jm5ic3A7IHwvL3w8 L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tIC4uLiAtLS0m IzQzOy0tLS0tLS0tLS0tLS0tIC4uLiAtLS0tLS0tLS0tLS0tLSYjNDM7PGI+LS0tLS0tLS0tLS0t LSYjNDM7LS0mIzQzOzwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBKdW4gMjIsIDIwMTcgYXQgOToxMSBBTSwgJmx0OzxhIGhyZWY9Im1h aWx0bzpkb21pbmlxdWUuYmFydGhlbEBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZG9taW5p cXVlLmJhcnRoZWxAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5IaSBKdWFuIENhcmxvcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+R29vZCBwb2ludC4gSSB0aGluayB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVj dCwgYW5kIEkgc2VlIHlvdXIgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JdCBzZWVtcyB0byBt ZSB0aGF0IHdlIGRvbid0IGhhdmUgdG8gbWFuZGF0ZSB0aGUgcGFkZGluZyBiZWhhdmlvdXIgaW4g dGhlIGdlbmVyaWMgU0NIQyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVhY2ggU0NIQy1v dmVyLWZvbyBkZXJpdmF0aW9uIGNvdWxkIG1ha2UgaXRzIG93biBkZWNpc2lvbiByZWdhcmRpbmcg cGFkZGluZyBvciBub3QgYW5kIGltcG9zZSBpdCBvbiB0aGUgaW1wbGVtZW50b3JzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+T3IgdGhpcyBjb3VsZCBldmVuIGJlIGEgZmxhZyBpbiB0aGUgU0NIQyBjb21w cmVzc29yL2RlY29tcHJlc3NvciBzdGF0ZSwgbGVhdmluZyB0aGUgZGVjaXNpb24gdG8gcGFkIG9y IG5vdCB0byB0aGUgaW50ZWdyYXRvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNvbW1lbnRzID88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Eb21pbmlxdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzoNCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5scC13YW4gJmx0OzxhIGhyZWY9Im1haWx0bzpscC13YW4tYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxwLXdhbi1ib3VuY2VzQGlldGYub3JnPC9h PiZndDsgb24gYmVoYWxmIG9mIEp1YW4gQ2FybG9zIFp1bmlnYSAmbHQ7PGEgaHJlZj0ibWFpbHRv Omp1YW5jYXJsb3MuenVuaWdhQHNpZ2ZveC5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWFuY2FybG9z Lnp1bmlnYUBzaWdmb3guY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlJm5ic3A7OiA8L2I+V2VkbmVz ZGF5IDIxIEp1bmUgMjAxNyAxODo0Mjxicj4NCjxiPsOAJm5ic3A7OiA8L2I+TGF1cmVudCBUb3V0 YWluICZsdDs8YSBocmVmPSJtYWlsdG86bGF1cmVudC50b3V0YWluQGltdC1hdGxhbnRpcXVlLmZy IiB0YXJnZXQ9Il9ibGFuayI+bGF1cmVudC50b3V0YWluQGltdC1hdGxhbnRpcXVlLmZyPC9hPiZn dDs8YnI+DQo8Yj5DYyZuYnNwOzogPC9iPmxwLXdhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxwLXdh bkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxwLXdhbkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PGI+T2JqZXQmbmJzcDs6IDwvYj5bbHAtd2FuXSBTQ0hDIC0gVG8gcGFkIG9yIG5vdCB0byBwYWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SGkgTGF1cmVudCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkluIHRoZSBj YWxsIHlvdSBwcm9wb3NlZCBwYWRkaW5nIGluLWJldHdlZW4gU0NIQyBoZWFkZXIgYW5kIFBheWxv YWQgRGF0YS4gSG93ZXZlciwgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIHdvdWxkIGxpbWl0DQogdGhl IChhbHJlYWR5IHNtYWxsKSBhbW91bnQgb2YgYml0cyBhdmFpbGFibGUgZm9yIERhdGEuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gb3IgaW5zdGFuY2UsIGluIGEgNjQtYml0IFNpZ2ZveCBETCBmcmFtZSwN Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5hbiBldmVudHVhbCBTQ0hDIGhl YWRlciBvZiAxMSBiaXRzIHdvdWxkIGJlIHBhZGRlZCB1cCB0byAxNiwgbGVhdmluZyBvbmx5IDQ4 IGF2YWlsYWJsZSBiaXRzIGZvciBkYXRhIGluc3RlYWQgb2YgNTMuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SnVhbiBDYXJsb3MNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5UaGFuayB5b3UuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmxwLXdhbiBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bHAtd2FuQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bHAtd2FuQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbHAtd2FuIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13YW48L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbHAtd2FuIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpscC13YW5AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5scC13 YW5AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9scC13YW4iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xwLXdhbjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB6PR08MB2679E2FCED5464AEBB8E188789D80DB6PR08MB2679eurp_-- From nobody Fri Jun 23 17:09:05 2017 Return-Path: X-Original-To: lp-wan@ietf.org Delivered-To: lp-wan@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3D6129B5B; Fri, 23 Jun 2017 17:07:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: lp-wan@ietf.org, suresh.krishnan@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282076.7840.1890234780928616050.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:00 -0700 Archived-At: Subject: [lp-wan] lpwan - Requested session has been scheduled for IETF 99 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:01 -0000 Dear Alexander Pelov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lpwan Session 1 (2:00:00) Friday, Morning Session I 0930-1130 Room Name: Karlin I/II size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 over Low Power Wide-Area Networks Area Name: Internet Area Session Requester: Alexander Pelov Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: 6lo 6tisch core detnet roll cbor t2trg teep lwig Second Priority: bier netconf intarea artarea 6man ace anima Third Priority: isis quic httpbis babel trill curdle People who must be present: Pascal Thubert Suresh Krishnan Alexander Pelov Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 24 01:56:21 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF24129413; Sat, 24 Jun 2017 01:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ol2J60FK52fI; Sat, 24 Jun 2017 01:56:08 -0700 (PDT) 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 9C7D7127868; Sat, 24 Jun 2017 01:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v5O8u3NG023097; Sat, 24 Jun 2017 10:56:03 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wvq0z45w8z3Z2B; Sat, 24 Jun 2017 10:56:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Sat, 24 Jun 2017 10:56:02 +0200 X-Mao-Original-Outgoing-Id: 519987362.679874-2baefd1bca65da7e448544ab723f9c38 Content-Transfer-Encoding: quoted-printable Message-Id: <4DFB341F-0002-4FBF-9630-BEAA28820AD1@tzi.org> References: To: lo <6lo@ietf.org>, 6TiSCH mailing list <6tisch@ietf.org>, lp-wan , lwip@ietf.org, Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Constrained Node/Network Cluster @ IETF99: "FINAL" AGENDA X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 08:56:10 -0000 Here is my usual eclectic condensed agenda, now based on the "FINAL" AGENDA for IETF99. Compared to the last week's draft agenda, dnssd and acme were moved. (It is likely that there still will be some more changes after this "FINAL" agenda.) ACE people are going to miss DISPATCH (ARTAREA) again -- not sure if there would have been be any discussions relevant to Constrained Nodes/Networks in ARTAREA, but it doesn't make sense with this scheduling. CORE people will miss both ANIMA and (in-week) ICNRG. ROLL people will miss SAAG, ouch. And LPWAN is on the second half of QUIC. All no disasters, AFAICS, but not pain-free. All times are CEST (UTC+0200). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) SATURDAY, July 15, 2017 0900-1700 ACM, IRTF & ISOC Applied Networking Research Workshop 2017 = (Registration Required) - Athens/Barcelona 0900-1800 T2TRG Interim Meeting - Berlin/Brussels 0900-2100 IETF Hackathon - Chez Louis SUNDAY, July 16, 2017 0900-1600 T2TRG Interim Meeting - Berlin/Brussels 0900-1600 IETF Hackathon - Chez Louis 1345-1445 IEEE 802.1 Time-Sensitive Networking - Congress Hall III 1345-1445 IRTF Overview - Congress Hall I 1345-1445 TEEP Tutorial - Karlin I/II 1600-1700 Newcomers' Meet and Greet (open to Newcomers, WG chairs and = Mentors only) - Garden Terrace 1700-1900 Welcome Reception - Grand Hilton Ballroom & Foyer MONDAY, July 17, 2017 0930-1200 Morning Session I Congress H III ART dispatch Dispatch WG - 09:30-11:30 Grand Hilton BR INT 6man IPv6 Maintenance WG Congress H I SEC *** ace Authentication and Authorization for = Constrained Environments WG Congress H III SEC curdle CURves, Deprecating and a Little more = Encryption WG - 11:30-12:00 1330-1530 Afternoon Session I Karlin I/II INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Grand Hilton BR INT homenet Home Networking WG 1550-1720 Afternoon Session II Karlin I/II ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Berlin/Brussels SEC tokbind Token Binding WG 1740-1840 Afternoon Session III Athens/Barcel. RTG babel Babel routing protocol WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting TUESDAY, July 18, 2017 0930-1200 Morning Session I Congress H II OPS v6ops IPv6 Operations WG Congress H I TSV taps Transport Services WG 1330-1530 Afternoon Session I Grand Hilton BR IRTF*** t2trg Thing-to-Thing Berlin/Brussels SEC oauth Web Authorization Protocol WG Congress H I TSV tsvwg Transport Area Working Group WG 1550-1750 Afternoon Session II Karlin I/II INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Congress H I IRTF cfrg Crypto Forum WEDNESDAY, July 19, 2017 0930-1200 Morning Session I Congress H I ART *** core Constrained RESTful Environments WG Karlin I/II IRTF icnrg Information-Centric Networking Congress H III OPS anima Autonomic Networking Integrated Model = and Approach WG Congress H II RTG rtgarea Routing Area Open Meeting Grand Hilton BR SEC tls Transport Layer Security WG Karlin III TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1330-1500 Afternoon Session I Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG Congress H III IRTF panrg Proposed Path Aware Networking Congress H II RTG ideas IDentity Enabled Networks BOF 1520-1650 Afternoon Session II Grand Hilton BR ART httpbis Hypertext Transfer Protocol WG Athens/Barcel. INT dnssd Extensions for Scalable DNS Service = Discovery WG THURSDAY, July 20, 2017 0930-1200 Morning Session I Grand Hilton BR INT intarea Internet Area Working Group WG Congress H II IRTF maprg Measurement and Analysis for Protocols Congress H I RTG detnet Deterministic Networking WG 1330-1530 Afternoon Session I Berlin/Brussels ART ice Interactive Connectivity Establishment = WG Grand Hilton BR OPS v6ops IPv6 Operations WG Karlin I/II RTG *** roll Routing Over Low power and Lossy = networks WG Congress H III SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Athens/Barcel. INT ipwave IP Wireless Access in Vehicular = Environments WG Grand Hilton BR TSV quic QUIC WG 1810-1910 Afternoon Session III Berlin/Brussels ART uta Using TLS in Applications WG Athens/Barcel. INT *** lwig Light-Weight Implementation Guidance WG Karlin I/II RTG bier Bit Indexed Explicit Replication WG Congress H III TSV tsvwg Transport Area Working Group WG FRIDAY, July 21, 2017 0930-1130 Morning Session I Karlin I/II INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Athens/Barcel. SEC acme Automated Certificate Management = Environment WG Karlin III SEC oauth Web Authorization Protocol WG Grand Hilton BR TSV quic QUIC WG 1150-1320 Afternoon Session II Congress H III ART *** core Constrained RESTful Environments WG From nobody Mon Jun 26 01:32:41 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EF6120721; Mon, 26 Jun 2017 01:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwdHUcyg_VMY; Mon, 26 Jun 2017 01:32:37 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E8A129562; Mon, 26 Jun 2017 01:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20344; q=dns/txt; s=iport; t=1498465957; x=1499675557; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1DoOr20ajTnJd2znRnYvTjkyd+ff2/RGo3dD2z4DGEY=; b=XfJmjrgh2mp/WQ8094SoLCF7ozrLLnOfO2goEdFwVyOQp91a5A752FQT tUOJnhtvyKBh+lffX/lOATQk/Ag8r/OaaMuevcwehBbnDBNCYHYdK0Sd3 UnFeq6uiBBgi7GZ/AdT345WcNsU26m3BHMI16tSUb1AEmchwRHlXtOUDW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAQBGxlBZ/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9pYoENB4NlihmRYJBPhSuCESEBCoV4AhqCej8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBIQpBEAsCAQgRBAEBKAMCAgIlCxQJCAIEARIIiUBcCBCxV?= =?us-ascii?q?oImi1ABAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyeDTIFhgjFzgnmCJ4JdgmEFlx6?= =?us-ascii?q?HSwKHMowqgmiPM5UgAR84P0t0FUmCUoQ9dogkgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,394,1493683200"; d="scan'208,217";a="445796826" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2017 08:32:36 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v5Q8WaU6007166 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Jun 2017 08:32:36 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Jun 2017 03:32:35 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Mon, 26 Jun 2017 03:32:35 -0500 From: "Pascal Thubert (pthubert)" To: weigengyu , Laurent Toutain , lp-wan , "hackathon@ietf.org" Thread-Topic: [lp-wan] SCHC testing Thread-Index: AQHS64MDTQn0/DGfPkOytpORw7iyZaIyTM4AgASIJ8A= Date: Mon, 26 Jun 2017 08:32:34 +0000 Deferred-Delivery: Mon, 26 Jun 2017 08:32:24 +0000 Message-ID: References: <7EC68881FD0D46BFA4A8BF5BFF51ADFE@WeiGengyuPC> In-Reply-To: <7EC68881FD0D46BFA4A8BF5BFF51ADFE@WeiGengyuPC> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.12] Content-Type: multipart/alternative; boundary="_000_d400bb98dbfb46e3ac61ae00bdc430e6XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] SCHC testing X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 08:32:40 -0000 --_000_d400bb98dbfb46e3ac61ae00bdc430e6XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gR2VuZ3l1DQoNCkkgdGhpbmcgdGhhdCBieSDigJ1tYXR1cmXigJ0gTGF1cmVudCBtZWFu dCDigJxzdGFibGXigJ0uIEFuZCBJIGFncmVlIGl0IGlzIHN0YWJsZS4gSXQgd29ya3MuIFdlIGFy ZSBub3cgZ2V0dGluZyByZWFkeSBmb3IgbGFzdCBjYWxsLiBJIGFncmVlIHRoYXQgcmVhbCBtYXR1 cml0eSB3aWxsIGNvbWUgd2l0aCBkZXBsb3ltZW50IGV4cGVyaWVuY2UuDQoNCkNoZWVyczsNCg0K UGFzY2FsDQpGcm9tOiBscC13YW4gW21haWx0bzpscC13YW4tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIHdlaWdlbmd5dQ0KU2VudDogdmVuZHJlZGkgMjMganVpbiAyMDE3IDA4OjE1DQpU bzogTGF1cmVudCBUb3V0YWluIDxsYXVyZW50LnRvdXRhaW5AaW10LWF0bGFudGlxdWUuZnI+OyBs cC13YW4gPGxwLXdhbkBpZXRmLm9yZz47IGhhY2thdGhvbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtscC13YW5dIFNDSEMgdGVzdGluZw0KDQpIaSBhbGwsDQpUaGUgZG9jIGlzIGp1c3QgYSBkcmFm dC4NCg0KPiBUaGUgTFBXQU4gY29tcHJlc3Npb24gbWVjaGFuaXNtIFNDSEMgZGVmaW5lZCBpbiBk cmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGljLWNvbnRleHQtaGMgaXMgbWF0dXJlDQpGcm9tIGEg dGVjaG5pY2FsIHZpZXcgcG9pbnQsIGl0IGlzIG5vdCBhIG1hdHVyZSBiZWNhdXNlIGl0IGNhbiBi ZSBvcHRpbWl6ZSBhcHBhcmVudGx5Lg0KDQpSZWdhcmRzLA0KDQpHZW5neXUgV0VJDQpOZXR3b3Jr IFRlY2hub2xvZ3kgQ2VudGVyDQpTY2hvb2wgb2YgQ29tcHV0ZXINCkJlaWppbmcgVW5pdmVyc2l0 eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zDQoNCkZyb206IExhdXJlbnQgVG91dGFp bjxtYWlsdG86bGF1cmVudC50b3V0YWluQGltdC1hdGxhbnRpcXVlLmZyPg0KU2VudDogRnJpZGF5 LCBKdW5lIDIzLCAyMDE3IDI6MTAgQU0NClRvOiBscC13YW48bWFpbHRvOmxwLXdhbkBpZXRmLm9y Zz4gOyBoYWNrYXRob25AaWV0Zi5vcmc8bWFpbHRvOmhhY2thdGhvbkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtscC13YW5dIFNDSEMgdGVzdGluZw0KDQpIaSwNCg0KVGhlIExQV0FOIGNvbXByZXNzaW9u IG1lY2hhbmlzbSBTQ0hDIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1j b250ZXh0LWhjIGlzIG1hdHVyZSBhbmQgYXQgbGVhc3QgMyBpbXBsZW1lbnRhdGlvbnMgYWxyZWFk eSBleGlzdC4gRHVyaW5nIHRoZSBuZXh0IEhhY2thdGhvbiBpbiBQcmFndWUsIGEgTG9SYVdBTiBh bmQgYSBTaWdmb3ggbmV0d29yayB3aWxsIGJlIGF2YWlsYWJsZSB0byBwZXJmb3JtIHRlc3Qgb2Yg U0NIQyB3aXRoIHNldmVyYWwgb2JqZWN0aXZlczoNCg0KDQotICAgICAgIGFsbG93IGRldmVsb3Bl cnMgdG8gdW5kZXJzdGFuZCBTQ0hDIGJlaGF2aW9yIGFuZCBpbXBsZW1lbnQgdGhlaXIgb3duIHZl cnNpb24gb2YgdGhlIG1lY2hhbmlzbQ0KDQotICAgICAgIHRlc3QgaW50ZXJvcGVyYWJpbGl0eSBi ZXR3ZWVuIHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMNCg0KLSAgICAgICBkZWZpbmUgY29t cHJlc3Npb24gYW5kIGZyYWdtZW50YXRpb24gcnVsZXMgcmVsYXRlZCB0byBzcGVjaWZpYyB0cmFm ZmljDQpDb21lIHdpdGggeW91ciBvd24gZGV2aWNlcyBvciB1c2UgdGhlIHB5Y29tIGRldmljZXMg d2Ugd2lsbCBicmluZyB0byBwYXJ0aWNpcGF0ZSB0byB0aGUgcmVhbCBJbnRlcm5ldCBvZiBUaGlu Z3MuIFRvIHBhcnRpY2lwYXRlIHlvdSBuZWVkIHRvIHJlZ2lzdGVyIGFzIHF1aWNrbHkgYXMgcG9z c2libGUgb24gaHR0cDovL2lldGYub3JnL2hhY2thdGhvbi85OS1oYWNrYXRob24uaHRtbA0KDQpX ZSB3aWxsIHByb3ZpZGUgbW9yZSB0ZWNobmljYWwgZGV0YWlscyBvbiB0aGUgY29taW5nIGRheXMu DQoNCkxhdXJlbnQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbHAtd2FuIG1haWxpbmcgbGlz dA0KbHAtd2FuQGlldGYub3JnPG1haWx0bzpscC13YW5AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xwLXdhbg0K --_000_d400bb98dbfb46e3ac61ae00bdc430e6XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbTQ1NjkyMDA1MzE1Mzg1NTU0NjdnbWFp bC1tc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tNDU2OTIwMDUzMTUzODU1NTQ2N2dtYWlsLW1z b2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tNDU2OTIwMDUzMTUzODU1NTQ2N2dtYWlsLW1zb2xp c3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV80NTY5MjAwNTMxNTM4NTU1NDY3 Z21haWwtbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhl bGxvIEdlbmd5dQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J IHRoaW5nIHRoYXQgYnkg4oCdbWF0dXJl4oCdIExhdXJlbnQgbWVhbnQg4oCcc3RhYmxl4oCdLiBB bmQgSSBhZ3JlZSBpdCBpcyBzdGFibGUuIEl0IHdvcmtzLiBXZSBhcmUgbm93IGdldHRpbmcgcmVh ZHkgZm9yIGxhc3QgY2FsbC4gSSBhZ3JlZSB0aGF0IHJlYWwgbWF0dXJpdHkgd2lsbCBjb21lDQog d2l0aCBkZXBsb3ltZW50IGV4cGVyaWVuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5DaGVlcnM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5QYXNjYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gbHAtd2FuIFttYWlsdG86bHAtd2FuLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPndlaWdlbmd5dTxicj4NCjxiPlNlbnQ6PC9iPiB2ZW5kcmVkaSAyMyBqdWluIDIwMTcg MDg6MTU8YnI+DQo8Yj5Ubzo8L2I+IExhdXJlbnQgVG91dGFpbiAmbHQ7bGF1cmVudC50b3V0YWlu QGltdC1hdGxhbnRpcXVlLmZyJmd0OzsgbHAtd2FuICZsdDtscC13YW5AaWV0Zi5vcmcmZ3Q7OyBo YWNrYXRob25AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtscC13YW5dIFNDSEMg dGVzdGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgZG9jIGlzIGp1c3QgYSBkcmFmdC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgVGhlIExQV0FOIGNvbXByZXNzaW9uIG1lY2hhbmlz bSBTQ0hDIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhj IGlzIG1hdHVyZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJv bSBhIHRlY2huaWNhbCB2aWV3IHBvaW50LCBpdCBpcyBub3QgYSBtYXR1cmUgYmVjYXVzZSBpdCBj YW4gYmUgb3B0aW1pemUgYXBwYXJlbnRseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5SZWdhcmRzLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+R2VuZ3l1IFdFSTxi cj4NCk5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXI8YnI+DQpTY2hvb2wgb2YgQ29tcHV0ZXIgPGJy Pg0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtiYWNr Z3JvdW5kOndoaXRlc21va2UiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOmxh dXJlbnQudG91dGFpbkBpbXQtYXRsYW50aXF1ZS5mciIgdGl0bGU9ImxhdXJlbnQudG91dGFpbkBp bXQtYXRsYW50aXF1ZS5mciI+DQpMYXVyZW50IFRvdXRhaW48L2E+IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0ZXNtb2tlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+U2VudDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gRnJp ZGF5LCBKdW5lIDIzLA0KIDIwMTcgMjoxMCBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7 YmFja2dyb3VuZDp3aGl0ZXNtb2tlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VG86 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQo8YSBocmVmPSJtYWlsdG86 bHAtd2FuQGlldGYub3JnIiB0aXRsZT0ibHAtd2FuQGlldGYub3JnIj5scC13YW48L2E+IDsgPGEg aHJlZj0ibWFpbHRvOmhhY2thdGhvbkBpZXRmLm9yZyIgdGl0bGU9ImhhY2thdGhvbkBpZXRmLm9y ZyI+DQpoYWNrYXRob25AaWV0Zi5vcmc8L2E+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7 YmFja2dyb3VuZDp3aGl0ZXNtb2tlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3Vi amVjdDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gW2xwLXdhbl0gU0NI Qw0KIHRlc3Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+VGhlIExQV0FOIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBTQ0hDIGRlZmluZWQg aW4gZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjIGlzIG1hdHVyZSBhbmQg YXQgbGVhc3QgMyBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSBleGlzdC4gRHVyaW5nIHRoZSBuZXh0 IEhhY2thdGhvbiBpbiBQcmFndWUsIGEgTG9SYVdBTiBhbmQgYSBTaWdmb3gNCiBuZXR3b3JrIHdp bGwgYmUgYXZhaWxhYmxlIHRvIHBlcmZvcm0gdGVzdCBvZiBTQ0hDIHdpdGggc2V2ZXJhbCBvYmpl Y3RpdmVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9ImdtYWlsLW00NTY5MjAwNTMxNTM4NTU1NDY3Z21haWwtbXNvbGlzdHBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmFsbG93IGRldmVsb3BlcnMg dG8gdW5kZXJzdGFuZCBTQ0hDIGJlaGF2aW9yIGFuZCBpbXBsZW1lbnQgdGhlaXIgb3duIHZlcnNp b24gb2YgdGhlIG1lY2hhbmlzbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tNDU2OTIwMDUzMTUzODU1NTQ2N2dtYWlsLW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj50ZXN0IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0aGUg ZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 ImdtYWlsLW00NTY5MjAwNTMxNTM4NTU1NDY3Z21haWwtbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmRlZmluZSBjb21wcmVzc2lvbiBhbmQgZnJhZ21l bnRhdGlvbiBydWxlcyByZWxhdGVkIHRvIHNwZWNpZmljIHRyYWZmaWM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPkNvbWUgd2l0aCB5b3VyIG93biBkZXZpY2VzIG9yIHVzZSB0aGUgcHljb20gZGV2aWNl cyB3ZSB3aWxsIGJyaW5nIHRvIHBhcnRpY2lwYXRlIHRvIHRoZSByZWFsIEludGVybmV0IG9mIFRo aW5ncy4gVG8gcGFydGljaXBhdGUgeW91IG5lZWQgdG8gcmVnaXN0ZXIgYXMgcXVpY2tseSBhcyBw b3NzaWJsZSBvbg0KPGEgaHJlZj0iaHR0cDovL2lldGYub3JnL2hhY2thdGhvbi85OS1oYWNrYXRo b24uaHRtbCI+aHR0cDovL2lldGYub3JnL2hhY2thdGhvbi85OS1oYWNrYXRob24uaHRtbDwvYT4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5XZSB3 aWxsIHByb3ZpZGUgbW9yZSB0ZWNobmljYWwgZGV0YWlscyBvbiB0aGUgY29taW5nIGRheXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkxhdXJlbnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWFsaWduOmNlbnRlciI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSI1IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+ DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCmxwLXdhbiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 bHAtd2FuQGlldGYub3JnIj5scC13YW5AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13YW4iPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbHAtd2FuPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d400bb98dbfb46e3ac61ae00bdc430e6XCHRCD001ciscocom_-- From nobody Mon Jun 26 01:34:12 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629171294A2 for ; Mon, 26 Jun 2017 01:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykrTuDhWygSM for ; Mon, 26 Jun 2017 01:34:07 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54565120721 for ; Mon, 26 Jun 2017 01:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4746; q=dns/txt; s=iport; t=1498466047; x=1499675647; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=La3PsZiqmZMHBZn0QvkmskRh0bzmEvRis8So03HiXMQ=; b=YBfnN1csJ6o65nEwBSHvTWfOPy32TBSncZnZ3zgKA/HuJDHc5fFiGLdK AYZQOMtl+4suJgRNjtweGvJYkBHYAndLZNSJXzbnREzxDgIldCDcZV0iP aCEFkQmfPiEAP4CpSQiq3LjTwImIV/9Nimrsd5syqkVLDougtOHfePOcW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAQCKxVBZ/5BdJa1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNYYoENB4NlihmRYJV6ghEhC4V4AhqCej8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBIREzBwsFBwQCAQYCEQQBAQMCIwMCAgIlCxQBCAgCBAENBQgTi?= =?us-ascii?q?gkIEJN0nWKCJotQAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4Icg0yBYYIxc4E?= =?us-ascii?q?khlmCYQWeaQKKcohqkhuEFJEMAR84P0t0FUmGUD92iCSBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,394,1493683200"; d="scan'208";a="445785694" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2017 08:34:06 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v5Q8Y6o3008332 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Jun 2017 08:34:06 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Jun 2017 03:34:05 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Mon, 26 Jun 2017 03:34:05 -0500 From: "Pascal Thubert (pthubert)" To: weigengyu , Carles Gomez Montenegro CC: "lp-wan@ietf.org" , "arun@ackl.io" Thread-Topic: [lp-wan] Fw: re-order header field request Thread-Index: AQHS7CyqlbElmQ4/nkW0bbsfmP5W8qI21N+w Date: Mon, 26 Jun 2017 08:33:36 +0000 Deferred-Delivery: Mon, 26 Jun 2017 08:33:33 +0000 Message-ID: <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> In-Reply-To: <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 08:34:09 -0000 SGVsbG8gR2VuZ3l1DQoNCldlIG5lZWQgdGhlIFJ1bGUgdG8gc2F5IGZyYWdtZW50IG9uIGVhY2gg ZnJhZ21lbnQsIGFuZCB0aGVuIHRoZSBkdGFnLiBTdGFydGluZyB0aGUgbmV4dCBmcmFnbWVudCB3 aXRoIHRoZSBkdGFnIHdvdWxkIGNvbmZ1c2UgdGhlIHBhcnNlciB3aGljaCB3b3VsZCBpbnRlcnBy ZXQgdGhlIGR0YWcgYXMgYW5vdGhlciBydWxlLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGxwLXdhbiBbbWFpbHRvOmxwLXdhbi1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygd2VpZ2VuZ3l1DQpTZW50OiB2ZW5kcmVkaSAyMyBqdWlu IDIwMTcgMTY6MjYNClRvOiBDYXJsZXMgR29tZXogTW9udGVuZWdybyA8Y2FybGVzZ29AZW50ZWwu dXBjLmVkdT4NCkNjOiBscC13YW5AaWV0Zi5vcmc7IGFydW5AYWNrbC5pbw0KU3ViamVjdDogUmU6 IFtscC13YW5dIEZ3OiByZS1vcmRlciBoZWFkZXIgZmllbGQgcmVxdWVzdA0KDQoNCkhpLA0KDQo+ IEkgdGhpbmsgdGhlcmUgYXJlIHByb2JsZW1zIHdpdGggdGhpcyBwcm9wb3NhbC4gSWYgdGhlIFJ1 bGUgSUQgb2YgDQo+IHN1Y2Nlc3NpdmUgZnJhZ21lbnRzIGlzIHN1cHByZXNzZWQsIGhvdyBkb2Vz IGEgcmVjZWl2ZXIga25vdyB3aGV0aGVyIA0KPiB0aG9zZSBzdWNjZXNzaXZlIGRhdGEgdW5pdHMg YXJlIGFjdHVhbCBmcmFnbWVudHMgb3Igbm90LCBvciBob3cgdGhlIA0KPiBkYXRhIHVuaXQgaGFz IHRvIGJlIHByb2Nlc3NlZD8NCg0KVGhlIER0YWcgY2FuIGJlIHVzZWQgZm9yIGtub3dpbmcgIndo ZXRoZXIgdGhvc2Ugc3VjY2Vzc2l2ZSBkYXRhIHVuaXRzIGFyZSBhY3R1YWwgZnJhZ21lbnRzIG9y IG5vdCwgb3IgaG93IHRoZSBkYXRhIHVuaXQgaGFzIHRvIGJlIHByb2Nlc3NlZC4gIg0KDQpGb3Ig ZXhhbXBsZSwgaWYgYW4gSVB2NiBwYWNrZXQgaXMgcGFydGl0aW9uZWQgaW50byB0d28gZnJhZ21l bnRzLCB0aGUgZmlyc3QgZnJhZ21lbnQgaW5jbHVlcyBhIFJ1bGUgSUQgYW5kIGEgRHRhZywgdGhl IHNlY29uZCBmcmFnbWVudCBpbmNsdWRlcyB0aGUgRHRhZyB3aXRob3V0IHRoZSBSdWxlIElELg0K DQpBZnRlciB0aGUgZmlyc3QgZnJhZ21lbnQgaXMgc2VudCwgdGhlIFJ1bGUgSUQgaXMgYmluZGVk IHdpdGggYSBEdGFnIGZvciB0aGlzIHBhY2tldC4NClRoZSByZWNlaXZlciBjYW4ga25vdyB3aGlj aCB0aGUgUnVsZSBJRCBpcyB1c2VkIGJ5IHRoZSBEdGFnLg0KDQoNClJlZ2FyZHMsDQoNCkdlbmd5 dSBXRUkNCk5ldHdvcmsgVGVjaG5vbG9neSBDZW50ZXINClNjaG9vbCBvZiBDb21wdXRlcg0KQmVp amluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMNCi0tLS0t5Y6f 5aeL6YKu5Lu2LS0tLS0gDQpGcm9tOiBDYXJsZXMgR29tZXogTW9udGVuZWdybw0KU2VudDogRnJp ZGF5LCBKdW5lIDIzLCAyMDE3IDY6NDcgUE0NClRvOiB3ZWlnZW5neXUNCkNjOiBhcnVuQGFja2wu aW8gOyBscC13YW5AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbHAtd2FuXSBGdzogcmUtb3JkZXIg aGVhZGVyIGZpZWxkIHJlcXVlc3QNCg0KDQpIaSwNCg0KPiBIaSBBcnVuIGFuZCBhbGwsDQo+DQo+ IEFmdGVyIHJlYWRpbmcgdGhyb3VnaCB0aGUgZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1j b250ZXh0LWhjLTA0LA0KPiBvbmUgcG9pbnQgbmVlZHMgdG8gYmUgZXhpcGxpY2l0IGRlc2NyaWJl ZDogaG93IG1hbnkgUnVsZSBJRHMgYXJlIHVzZWQgdG8NCj4gZnJhZ21lbnQgb25lIGxhcmdlIElQ djYgcGFja2V0Pw0KDQpXaGF0IHdlIGN1cnJlbnRseSBoYXZlIGluIHRoZSBkb2N1bWVudCBpczoN Cg0KICAgIlRoZSBSdWxlIElEIGluIGEgZnJhZ21lbnQgaXMgc2V0IHRvIGEgdmFsdWUgdGhhdCBp bmRpY2F0ZXMgdGhhdCB0aGUgZGF0YQ0KICAgdW5pdCBiZWluZyBjYXJyaWVkIGlzIGEgZnJhZ21l bnQuIg0KDQpTbyBjdXJyZW50bHkgd2UgZG8gbm90IGV4cGxpY2l0bHkgaW5kaWNhdGUgaG93IG1h bnkgUnVsZSBJRHMgYXJlIG5lZWRlZA0KZm9yIGZyYWdtZW50cyBvZiBhIGxhcmdlIElQdjYgcGFj a2V0LiBUaGUgbW9zdCBlZmZpY2llbnQgc29sdXRpb24gaXMgdG8NCmp1c3QgdXNlIG9uZSBSdWxl IElEIHRvIHNpZ25hbCAidGhpcyBpcyBhIGZyYWdtZW50Ii4gSG93ZXZlciwgaXQgaXMNCnByb2Jh Ymx5IHNhZmUgdG8ga2VlcCB0aGlzIG9wZW4gaW4gdGhlIFNDSEMgZG9jdW1lbnQsIHNvIHRoYXQg ZnV0dXJlDQp0ZWNobm9sb2d5LXNwZWNpZmljIFNDSEMgb3ZlciBmb28gZG9jdW1lbnRzIGhhdmUg ZnJlZWRvbSB0byBzcGVjaWZ5DQp3aGF0ZXZlciBiZXR0ZXIgc3VpdHMgdGhlaXIgbmVlZHMuDQoN Cj4gQnkgbXkgdW5kZXJzdGFuZGluZywgd2huZSBvbmUgSVB2NiBwYWNrZXQgaXMgZnJhZ21lbnRl ZCwgaXQgYWRvcHRzIG9ubHkNCj4gb25lIFJ1bGUgSUQuDQo+IEVhY2ggZnJhZ21lbnQgY29udGFp bnMgdGhlIHNhbWUgcnVsZSBJRCBhbmQgRHRhZy4NCj4gQW55dGhpbmcgd3Jvbmc/DQoNCkRUYWcg KGlmIHByZXNlbnQpIGhhcyB0byBiZSB0aGUgc2FtZSBpbiBhbGwgZnJhZ21lbnRzIGNhcnJ5aW5n IHRoZSBzYW1lDQpJUHY2IHBhY2tldC4NCg0KT25lIFJ1bGUgSUQgdG8gc2lnbmFsICd0aGlzIGlz IGEgZnJhZ21lbnQnIGlzIGZpbmUuDQoNCj4gU3VjaCBhIHdheSB0byBkZWxpdmVyIHRoZSByZXBl YXRlZCBSdWxlIElEIGNhbiBiZSBzdXBwcmVzc2VkLg0KPiBJdCBtYXkgYmUgYXZhaWxhYmxlIHRv IGhhdmUgdGhlIGZpcnN0IGZyYWdlbWVudCBvbmx5IGluY2x1ZGUgdGhlIFJ1bGUgSUQNCj4gd2hp bGUgY29udGFpbmluZyB0aGUgRHRhZy4NCj4gQW5kIHRoZSBmb2xsb3dpbmcgc3VjY2Vzc2l2ZSBm cmFnbWVudHMgaGF2ZSB0aGUgRHRhZ2Ugd2l0aG91dCB0aGUgUnVsZSBJRC4NCj4gVGhlIHJlY2Vp dmVyIGNhbiBnZXQgdGhlIGNvcnJlY3QgUnVsZSBJRCBmcm9tIHRoZSBmaXJzdCBmcmFnbWVudCBy ZWZlcnJlZA0KPiBhcyB0aGUgc2FtZSBEdGFnLg0KPg0KPiBUaGUgUnVsZSBJRCBpcyBzdXBwcmVz c2VkIGluIGZyYWdtZW50cyBmcm9tIHRoZSBzZWNvbmQgdG8gdGhlIGxhc3QuDQoNCkkgdGhpbmsg dGhlcmUgYXJlIHByb2JsZW1zIHdpdGggdGhpcyBwcm9wb3NhbC4gSWYgdGhlIFJ1bGUgSUQgb2YN CnN1Y2Nlc3NpdmUgZnJhZ21lbnRzIGlzIHN1cHByZXNzZWQsIGhvdyBkb2VzIGEgcmVjZWl2ZXIg a25vdyB3aGV0aGVyIHRob3NlDQpzdWNjZXNzaXZlIGRhdGEgdW5pdHMgYXJlIGFjdHVhbCBmcmFn bWVudHMgb3Igbm90LCBvciBob3cgdGhlIGRhdGEgdW5pdA0KaGFzIHRvIGJlIHByb2Nlc3NlZD8N Cg0KVGhhbmtzLA0KDQpDYXJsZXMNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpscC13YW4gbWFpbGluZyBsaXN0DQpscC13YW5AaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHAtd2FuDQo= From nobody Mon Jun 26 11:36:42 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1481270AC; Mon, 26 Jun 2017 11:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iji51jgHzeLN; Mon, 26 Jun 2017 11:36:33 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A38E126E64; Mon, 26 Jun 2017 11:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23398; q=dns/txt; s=iport; t=1498502193; x=1499711793; h=from:to:subject:date:message-id:mime-version; bh=ETz5CrBmKIFA537Pwy9miai5LUItHPOedgptvoig/PE=; b=GojBFhj4f+Ws/CJrzqkQkTVcmR4l4aQG9nEa+EB7Bo7vd2ALhWCeDR5y yYv+eN5bB1YvLyzbIcBDPm54aKWooRkBPOOZ1xVPoyBBJ3BB6md5ECKiT ooNr4FzP4HCANAJQP4Ib0BNlfsJE8UDZ9d0ZggC3zmCSMUPg2qwcqutJQ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAAD/UlFZ/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9pYoENB4NlihmRYpV6ghEhAQqFeAIaglM/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQICAQEBIQpBEA0BCBEDAQEBKAMCBCULFAkKBAESG4ktTAMNCBCwToImK?= =?us-ascii?q?YNrAYMhHIQHAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMnhS0rgW0Zc4J5ghEWgl0?= =?us-ascii?q?wgjEFlx6HSwKHMowzC4JUjzOVIAEfOD9LdBVJEgGCP4QCATp2iCmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,396,1493683200"; d="scan'208,217";a="443915350" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jun 2017 18:36:32 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v5QIaV7U024951 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Jun 2017 18:36:32 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Jun 2017 13:36:31 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Mon, 26 Jun 2017 13:36:31 -0500 From: "Charles Eckel (eckelcu)" To: "Pascal Thubert (pthubert)" , weigengyu , Laurent Toutain , lp-wan , "hackathon@ietf.org" Thread-Topic: [hackathon] [lp-wan] SCHC testing Thread-Index: AQHS7qshCtb0VEsTlE+0w/aC9D74eQ== Date: Mon, 26 Jun 2017 18:36:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.22.0.170515 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.96.244] Content-Type: multipart/alternative; boundary="_000_EC47DFFFADCA429EB0C443416C3EE4E3ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] [hackathon] SCHC testing X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 18:36:35 -0000 --_000_EC47DFFFADCA429EB0C443416C3EE4E3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TW92aW5nIHRoYXQgbWF0dXJpdHkgbmVlZGxlIGZvcndhcmQgaXMgb25lIG9mIHRoZSBwcmltYXJ5 IGdvYWxzIG9mIHRoZSBoYWNrYXRob24uIEl0IGlzIGdyZWF0IHRvIHNlZSBwcm9qZWN0cyB0aGF0 IHdvcmsgd2l0aCBlc3RhYmxpc2hlZCBzdGFuZGFyZHMgYW5kIHByb2R1Y2UgY29kZSBhbmQgdG9v bHMgdGhhdCBoZWxwIG90aGVycyB1c2UgYW5kIGRldmVsb3Agc29sdXRpb25zIG9uIHRvcCBvZiB0 aG9zZSBzdGFuZGFyZHMsIGJ1dCBpdCBpcyBldmVuIGJldHRlciB0byBoYXZlIHByb2plY3RzIHRo YXQgc3BlZWQgdXAgYW5kIGltcHJvdmUgdGhlIHF1YWxpdHkgb2YgZW1lcmdpbmcgc3RhbmRhcmRz Lg0KDQpDaGVlcnMsDQpDaGFybGVzDQoNCkZyb206IGhhY2thdGhvbiA8aGFja2F0aG9uLWJvdW5j ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0 aHViZXJ0QGNpc2NvLmNvbT4NCkRhdGU6IE1vbmRheSwgSnVuZSAyNiwgMjAxNyBhdCAxOjMyIEFN DQpUbzogd2VpZ2VuZ3l1IDx3ZWlnZW5neXVAdmlwLnNpbmEuY29tPiwgTGF1cmVudCBUb3V0YWlu IDxsYXVyZW50LnRvdXRhaW5AaW10LWF0bGFudGlxdWUuZnI+LCBscC13YW4gPGxwLXdhbkBpZXRm Lm9yZz4sICJoYWNrYXRob25AaWV0Zi5vcmciIDxoYWNrYXRob25AaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW2hhY2thdGhvbl0gW2xwLXdhbl0gU0NIQyB0ZXN0aW5nDQoNCkhlbGxvIEdlbmd5dQ0K DQpJIHRoaW5nIHRoYXQgYnkg4oCdbWF0dXJl4oCdIExhdXJlbnQgbWVhbnQg4oCcc3RhYmxl4oCd LiBBbmQgSSBhZ3JlZSBpdCBpcyBzdGFibGUuIEl0IHdvcmtzLiBXZSBhcmUgbm93IGdldHRpbmcg cmVhZHkgZm9yIGxhc3QgY2FsbC4gSSBhZ3JlZSB0aGF0IHJlYWwgbWF0dXJpdHkgd2lsbCBjb21l IHdpdGggZGVwbG95bWVudCBleHBlcmllbmNlLg0KDQpDaGVlcnM7DQoNClBhc2NhbA0KRnJvbTog bHAtd2FuIFttYWlsdG86bHAtd2FuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB3ZWln ZW5neXUNClNlbnQ6IHZlbmRyZWRpIDIzIGp1aW4gMjAxNyAwODoxNQ0KVG86IExhdXJlbnQgVG91 dGFpbiA8bGF1cmVudC50b3V0YWluQGltdC1hdGxhbnRpcXVlLmZyPjsgbHAtd2FuIDxscC13YW5A aWV0Zi5vcmc+OyBoYWNrYXRob25AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbHAtd2FuXSBTQ0hD IHRlc3RpbmcNCg0KSGkgYWxsLA0KVGhlIGRvYyBpcyBqdXN0IGEgZHJhZnQuDQoNCj4gVGhlIExQ V0FOIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBTQ0hDIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1scHdh bi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjIGlzIG1hdHVyZQ0KRnJvbSBhIHRlY2huaWNhbCB2aWV3 IHBvaW50LCBpdCBpcyBub3QgYSBtYXR1cmUgYmVjYXVzZSBpdCBjYW4gYmUgb3B0aW1pemUgYXBw YXJlbnRseS4NCg0KUmVnYXJkcywNCg0KR2VuZ3l1IFdFSQ0KTmV0d29yayBUZWNobm9sb2d5IENl bnRlcg0KU2Nob29sIG9mIENvbXB1dGVyDQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5k IFRlbGVjb21tdW5pY2F0aW9ucw0KDQpGcm9tOiBMYXVyZW50IFRvdXRhaW48bWFpbHRvOmxhdXJl bnQudG91dGFpbkBpbXQtYXRsYW50aXF1ZS5mcj4NClNlbnQ6IEZyaWRheSwgSnVuZSAyMywgMjAx NyAyOjEwIEFNDQpUbzogbHAtd2FuPG1haWx0bzpscC13YW5AaWV0Zi5vcmc+IDsgaGFja2F0aG9u QGlldGYub3JnPG1haWx0bzpoYWNrYXRob25AaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbHAtd2FuXSBT Q0hDIHRlc3RpbmcNCg0KSGksDQoNClRoZSBMUFdBTiBjb21wcmVzc2lvbiBtZWNoYW5pc20gU0NI QyBkZWZpbmVkIGluIGRyYWZ0LWlldGYtbHB3YW4taXB2Ni1zdGF0aWMtY29udGV4dC1oYyBpcyBt YXR1cmUgYW5kIGF0IGxlYXN0IDMgaW1wbGVtZW50YXRpb25zIGFscmVhZHkgZXhpc3QuIER1cmlu ZyB0aGUgbmV4dCBIYWNrYXRob24gaW4gUHJhZ3VlLCBhIExvUmFXQU4gYW5kIGEgU2lnZm94IG5l dHdvcmsgd2lsbCBiZSBhdmFpbGFibGUgdG8gcGVyZm9ybSB0ZXN0IG9mIFNDSEMgd2l0aCBzZXZl cmFsIG9iamVjdGl2ZXM6DQoNCg0KLSAgICAgICBhbGxvdyBkZXZlbG9wZXJzIHRvIHVuZGVyc3Rh bmQgU0NIQyBiZWhhdmlvciBhbmQgaW1wbGVtZW50IHRoZWlyIG93biB2ZXJzaW9uIG9mIHRoZSBt ZWNoYW5pc20NCg0KLSAgICAgICB0ZXN0IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0aGUgZXhp c3RpbmcgaW1wbGVtZW50YXRpb25zDQoNCi0gICAgICAgZGVmaW5lIGNvbXByZXNzaW9uIGFuZCBm cmFnbWVudGF0aW9uIHJ1bGVzIHJlbGF0ZWQgdG8gc3BlY2lmaWMgdHJhZmZpYw0KQ29tZSB3aXRo IHlvdXIgb3duIGRldmljZXMgb3IgdXNlIHRoZSBweWNvbSBkZXZpY2VzIHdlIHdpbGwgYnJpbmcg dG8gcGFydGljaXBhdGUgdG8gdGhlIHJlYWwgSW50ZXJuZXQgb2YgVGhpbmdzLiBUbyBwYXJ0aWNp cGF0ZSB5b3UgbmVlZCB0byByZWdpc3RlciBhcyBxdWlja2x5IGFzIHBvc3NpYmxlIG9uIGh0dHA6 Ly9pZXRmLm9yZy9oYWNrYXRob24vOTktaGFja2F0aG9uLmh0bWwNCg0KV2Ugd2lsbCBwcm92aWRl IG1vcmUgdGVjaG5pY2FsIGRldGFpbHMgb24gdGhlIGNvbWluZyBkYXlzLg0KDQpMYXVyZW50DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmxwLXdhbiBtYWlsaW5nIGxpc3QNCmxwLXdhbkBpZXRm Lm9yZzxtYWlsdG86bHAtd2FuQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9scC13YW4NCg== --_000_EC47DFFFADCA429EB0C443416C3EE4E3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbTQ1NjkyMDA1MzE1 Mzg1NTU0NjdnbWFpbC1tc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tNDU2OTIwMDUzMTUzODU1 NTQ2N2dtYWlsLW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tNDU2OTIwMDUzMTUzODU1NTQ2 N2dtYWlsLW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV80NTY5MjAw NTMxNTM4NTU1NDY3Z21haWwtbXNvbGlzdHBhcmFncmFwaDsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TW92aW5nIHRoYXQgbWF0dXJpdHkgbmVlZGxlIGZvcndhcmQgaXMgb25l IG9mIHRoZSBwcmltYXJ5IGdvYWxzIG9mIHRoZSBoYWNrYXRob24uIEl0IGlzIGdyZWF0IHRvIHNl ZSBwcm9qZWN0cyB0aGF0IHdvcmsgd2l0aCBlc3RhYmxpc2hlZCBzdGFuZGFyZHMgYW5kIHByb2R1 Y2UgY29kZSBhbmQgdG9vbHMgdGhhdCBoZWxwIG90aGVycyB1c2UgYW5kIGRldmVsb3Agc29sdXRp b25zIG9uIHRvcCBvZiB0aG9zZSBzdGFuZGFyZHMsDQogYnV0IGl0IGlzIGV2ZW4gYmV0dGVyIHRv IGhhdmUgcHJvamVjdHMgdGhhdCBzcGVlZCB1cCBhbmQgaW1wcm92ZSB0aGUgcXVhbGl0eSBvZiBl bWVyZ2luZyBzdGFuZGFyZHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYXJsZXMgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPmhhY2thdGhvbiAmbHQ7aGFja2F0aG9uLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpJnF1 b3Q7ICZsdDtwdGh1YmVydEBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwg SnVuZSAyNiwgMjAxNyBhdCAxOjMyIEFNPGJyPg0KPGI+VG86IDwvYj53ZWlnZW5neXUgJmx0O3dl aWdlbmd5dUB2aXAuc2luYS5jb20mZ3Q7LCBMYXVyZW50IFRvdXRhaW4gJmx0O2xhdXJlbnQudG91 dGFpbkBpbXQtYXRsYW50aXF1ZS5mciZndDssIGxwLXdhbiAmbHQ7bHAtd2FuQGlldGYub3JnJmd0 OywgJnF1b3Q7aGFja2F0aG9uQGlldGYub3JnJnF1b3Q7ICZsdDtoYWNrYXRob25AaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbaGFja2F0aG9uXSBbbHAtd2FuXSBTQ0hDIHRl c3Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhlbGxvIEdlbmd5dQ0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5nIHRoYXQgYnkg4oCdbWF0 dXJl4oCdIExhdXJlbnQgbWVhbnQg4oCcc3RhYmxl4oCdLiBBbmQgSSBhZ3JlZSBpdCBpcyBzdGFi bGUuIEl0IHdvcmtzLiBXZSBhcmUgbm93IGdldHRpbmcgcmVhZHkgZm9yIGxhc3QgY2FsbC4gSSBh Z3JlZSB0aGF0IHJlYWwgbWF0dXJpdHkgd2lsbCBjb21lDQogd2l0aCBkZXBsb3ltZW50IGV4cGVy aWVuY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnM7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYXNjYWw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGxwLXdhbiBbbWFpbHRvOmxwLXdh bi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj53ZWlnZW5neXU8YnI+DQo8 Yj5TZW50OjwvYj4gdmVuZHJlZGkgMjMganVpbiAyMDE3IDA4OjE1PGJyPg0KPGI+VG86PC9iPiBM YXVyZW50IFRvdXRhaW4gJmx0O2xhdXJlbnQudG91dGFpbkBpbXQtYXRsYW50aXF1ZS5mciZndDs7 IGxwLXdhbiAmbHQ7bHAtd2FuQGlldGYub3JnJmd0OzsgaGFja2F0aG9uQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbbHAtd2FuXSBTQ0hDIHRlc3Rpbmc8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkhpIGFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIGRvYyBp cyBqdXN0IGEgZHJhZnQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsgVGhlIExQ V0FOIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBTQ0hDIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1scHdh bi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjIGlzIG1hdHVyZQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkZyb20gYSB0ZWNobmljYWwgdmlldyBwb2ludCwgaXQgaXMgbm90 IGEgbWF0dXJlIGJlY2F1c2UgaXQgY2FuIGJlIG9wdGltaXplIGFwcGFyZW50bHkuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5SZWdhcmRzLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5HZW5neXUgV0VJPGJyPg0KTmV0d29yayBUZWNobm9sb2d5IENlbnRlcjxicj4NClNjaG9vbCBv ZiBDb21wdXRlciA8YnI+DQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21t dW5pY2F0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47YmFja2dyb3VuZDp3aGl0ZXNtb2tlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCjxhIGhyZWY9 Im1haWx0bzpsYXVyZW50LnRvdXRhaW5AaW10LWF0bGFudGlxdWUuZnIiIHRpdGxlPSJsYXVyZW50 LnRvdXRhaW5AaW10LWF0bGFudGlxdWUuZnIiPg0KTGF1cmVudCBUb3V0YWluPC9hPiA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjtiYWNrZ3JvdW5kOndoaXRlc21va2UiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5TZW50Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiBGcmlkYXksIEp1bmUgMjMsIDIwMTcNCiAyOjEwIEFNPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47YmFja2dyb3VuZDp3aGl0ZXNtb2tlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+VG86PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQo8YSBocmVmPSJt YWlsdG86bHAtd2FuQGlldGYub3JnIiB0aXRsZT0ibHAtd2FuQGlldGYub3JnIj5scC13YW48L2E+ IDsgPGEgaHJlZj0ibWFpbHRvOmhhY2thdGhvbkBpZXRmLm9yZyIgdGl0bGU9ImhhY2thdGhvbkBp ZXRmLm9yZyI+DQpoYWNrYXRob25AaWV0Zi5vcmc8L2E+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluO2JhY2tncm91bmQ6d2hpdGVzbW9rZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PlN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IFtscC13YW5d IFNDSEMgdGVzdGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+VGhlIExQV0FOIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBTQ0hDIGRlZmluZWQgaW4gZHJh ZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjIGlzIG1hdHVyZSBhbmQgYXQgbGVh c3QgMyBpbXBsZW1lbnRhdGlvbnMgYWxyZWFkeSBleGlzdC4gRHVyaW5nIHRoZSBuZXh0IEhhY2th dGhvbiBpbiBQcmFndWUsIGEgTG9SYVdBTiBhbmQgYSBTaWdmb3gNCiBuZXR3b3JrIHdpbGwgYmUg YXZhaWxhYmxlIHRvIHBlcmZvcm0gdGVzdCBvZiBTQ0hDIHdpdGggc2V2ZXJhbCBvYmplY3RpdmVz Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJnbWFpbC1tNDU2OTIwMDUzMTUzODU1NTQ2N2dtYWlsLW1zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi08L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+YWxsb3cgZGV2ZWxvcGVycyB0byB1bmRlcnN0 YW5kIFNDSEMgYmVoYXZpb3IgYW5kIGltcGxlbWVudCB0aGVpciBvd24gdmVyc2lvbiBvZiB0aGUg bWVjaGFuaXNtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW00NTY5MjAw NTMxNTM4NTU1NDY3Z21haWwtbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj50ZXN0IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiB0aGUgZXhpc3RpbmcgaW1w bGVtZW50YXRpb25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW00NTY5 MjAwNTMxNTM4NTU1NDY3Z21haWwtbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5kZWZpbmUgY29tcHJlc3Npb24gYW5kIGZyYWdtZW50YXRpb24gcnVsZXMg cmVsYXRlZCB0byBzcGVjaWZpYyB0cmFmZmljPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q29tZSB3aXRo IHlvdXIgb3duIGRldmljZXMgb3IgdXNlIHRoZSBweWNvbSBkZXZpY2VzIHdlIHdpbGwgYnJpbmcg dG8gcGFydGljaXBhdGUgdG8gdGhlIHJlYWwgSW50ZXJuZXQgb2YgVGhpbmdzLiBUbyBwYXJ0aWNp cGF0ZSB5b3UgbmVlZCB0byByZWdpc3RlciBhcyBxdWlja2x5IGFzIHBvc3NpYmxlIG9uDQo8YSBo cmVmPSJodHRwOi8vaWV0Zi5vcmcvaGFja2F0aG9uLzk5LWhhY2thdGhvbi5odG1sIj5odHRwOi8v aWV0Zi5vcmcvaGFja2F0aG9uLzk5LWhhY2thdGhvbi5odG1sPC9hPg0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+V2Ugd2lsbCBwcm92aWRlIG1vcmUgdGVj aG5pY2FsIGRldGFpbHMgb24gdGhlIGNvbWluZyBkYXlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkxhdXJlbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pg0KPGhyIHNpemU9IjUiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KbHAtd2FuIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpscC13YW5A aWV0Zi5vcmciPmxwLXdhbkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xwLXdhbiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9scC13YW48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EC47DFFFADCA429EB0C443416C3EE4E3ciscocom_-- From nobody Mon Jun 26 20:12:08 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A181286D6 for ; Mon, 26 Jun 2017 20:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, 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 wN6CWRZ_Zjas for ; Mon, 26 Jun 2017 20:12:02 -0700 (PDT) Received: from smtp-6-47.vip.sina.com.cn (r3-63.sinamail.sina.com.cn [202.108.3.63]) by ietfa.amsl.com (Postfix) with SMTP id 4E75F1289C3 for ; Mon, 26 Jun 2017 20:12:01 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.246.135.90]) by vip.sina.com with ESMTP 27 Jun 2017 11:11:55 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 32757278581 Message-ID: From: "weigengyu" To: "Pascal Thubert \(pthubert\)" , "Carles Gomez Montenegro" Cc: , References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> In-Reply-To: <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> Date: Tue, 27 Jun 2017 11:11:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 03:12:07 -0000 Hi Pascal, > We need the Rule to say fragment on each fragment, All framents of a IPv6 packet obey one rule, the Rule ID is included in the first fragment is enough for conveying this information. > and then the dtag. All framents of the packet contain the same Dtag as defined. > Starting the next fragment with the dtag would confuse the parser which > would interpret the dtag as another rule. Put the Dtag at the front. Defining the first two bits of Dtag as an indication of the first fragment, fragments of the minddle and the last fragment. 00 the first fragment 10 fragments of the minddle 11 the last fragment If the first two bits are '00', the Rule ID is followed. If the first two bits are not '00', the fragment does not contain the Rule ID. If the first two bits are 11, it is the last fragment. I believe that it is worth to have this two bit to suppress the space of Rule ID in the successive fragments. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Pascal Thubert (pthubert) Sent: Monday, June 26, 2017 4:33 PM To: weigengyu ; Carles Gomez Montenegro Cc: lp-wan@ietf.org ; arun@ackl.io Subject: Re: [lp-wan] Fw: re-order header field request Hello Gengyu We need the Rule to say fragment on each fragment, and then the dtag. Starting the next fragment with the dtag would confuse the parser which would interpret the dtag as another rule. Cheers, Pascal -----Original Message----- From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of weigengyu Sent: vendredi 23 juin 2017 16:26 To: Carles Gomez Montenegro Cc: lp-wan@ietf.org; arun@ackl.io Subject: Re: [lp-wan] Fw: re-order header field request Hi, > I think there are problems with this proposal. If the Rule ID of > successive fragments is suppressed, how does a receiver know whether > those successive data units are actual fragments or not, or how the > data unit has to be processed? The Dtag can be used for knowing "whether those successive data units are actual fragments or not, or how the data unit has to be processed. " For example, if an IPv6 packet is partitioned into two fragments, the first fragment inclues a Rule ID and a Dtag, the second fragment includes the Dtag without the Rule ID. After the first fragment is sent, the Rule ID is binded with a Dtag for this packet. The receiver can know which the Rule ID is used by the Dtag. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carles Gomez Montenegro Sent: Friday, June 23, 2017 6:47 PM To: weigengyu Cc: arun@ackl.io ; lp-wan@ietf.org Subject: Re: [lp-wan] Fw: re-order header field request Hi, > Hi Arun and all, > > After reading through the draft-ietf-lpwan-ipv6-static-context-hc-04, > one point needs to be exiplicit described: how many Rule IDs are used to > fragment one large IPv6 packet? What we currently have in the document is: "The Rule ID in a fragment is set to a value that indicates that the data unit being carried is a fragment." So currently we do not explicitly indicate how many Rule IDs are needed for fragments of a large IPv6 packet. The most efficient solution is to just use one Rule ID to signal "this is a fragment". However, it is probably safe to keep this open in the SCHC document, so that future technology-specific SCHC over foo documents have freedom to specify whatever better suits their needs. > By my understanding, whne one IPv6 packet is fragmented, it adopts only > one Rule ID. > Each fragment contains the same rule ID and Dtag. > Anything wrong? DTag (if present) has to be the same in all fragments carrying the same IPv6 packet. One Rule ID to signal 'this is a fragment' is fine. > Such a way to deliver the repeated Rule ID can be suppressed. > It may be available to have the first fragement only include the Rule ID > while containing the Dtag. > And the following successive fragments have the Dtage without the Rule ID. > The receiver can get the correct Rule ID from the first fragment referred > as the same Dtag. > > The Rule ID is suppressed in fragments from the second to the last. I think there are problems with this proposal. If the Rule ID of successive fragments is suppressed, how does a receiver know whether those successive data units are actual fragments or not, or how the data unit has to be processed? Thanks, Carles _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Mon Jun 26 20:49:21 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25671286D6 for ; Mon, 26 Jun 2017 20:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 QpIXjaY2_-ks for ; Mon, 26 Jun 2017 20:49:12 -0700 (PDT) Received: from smtp-6-46.vip.sina.com.cn (r3-67.sinamail.sina.com.cn [202.108.3.67]) by ietfa.amsl.com (Postfix) with SMTP id 8EAE1128AB0 for ; Mon, 26 Jun 2017 20:49:09 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.246.135.90]) by vip.sina.com with ESMTP 27 Jun 2017 11:49:03 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 718080288960 Message-ID: From: "weigengyu" To: "Charles Eckel \(eckelcu\)" , "Pascal Thubert \(pthubert\)" , "Laurent Toutain" , "lp-wan" , References: In-Reply-To: Date: Tue, 27 Jun 2017 11:48:59 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01D2EF3B.5D845BF0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] [hackathon] SCHC testing X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 03:49:18 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0018_01D2EF3B.5D845BF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,=20 The intention of suppression in the draft is to save bits. Suppose that an IPv6 packet is partioned into N fragments and the length = of Rule ID is R bits.=20 Using/Adding 2 bits in Dtag as an indication.=20 As a result, it can save (N-1)*R bits by costing 2*N bits.=20 I am not sure whether it is worth to save these bits by trading off a = few days. =20 Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Charles Eckel (eckelcu)=20 Sent: Tuesday, June 27, 2017 2:36 AM To: Pascal Thubert (pthubert) ; weigengyu ; Laurent Toutain ; lp-wan ; = hackathon@ietf.org=20 Subject: Re: [lp-wan] [hackathon] SCHC testing Moving that maturity needle forward is one of the primary goals of the = hackathon. It is great to see projects that work with established = standards and produce code and tools that help others use and develop = solutions on top of those standards, but it is even better to have = projects that speed up and improve the quality of emerging standards. =20 Cheers, Charles=20 =20 From: hackathon on behalf of "Pascal = Thubert (pthubert)" Date: Monday, June 26, 2017 at 1:32 AM To: weigengyu , Laurent Toutain = , lp-wan , = "hackathon@ietf.org" Subject: Re: [hackathon] [lp-wan] SCHC testing =20 Hello Gengyu=20 =20 I thing that by =E2=80=9Dmature=E2=80=9D Laurent meant = =E2=80=9Cstable=E2=80=9D. And I agree it is stable. It works. We are now = getting ready for last call. I agree that real maturity will come with = deployment experience. =20 Cheers; =20 Pascal From: lp-wan [mailto:lp-wan-bounces@ietf.org] On Behalf Of weigengyu Sent: vendredi 23 juin 2017 08:15 To: Laurent Toutain ; lp-wan = ; hackathon@ietf.org Subject: Re: [lp-wan] SCHC testing =20 Hi all, The doc is just a draft.=20 =20 > The LPWAN compression mechanism SCHC defined in = draft-ietf-lpwan-ipv6-static-context-hc is mature=20 >From a technical view point, it is not a mature because it can be = optimize apparently. =20 Regards,=20 =20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications =20 From: Laurent Toutain=20 Sent: Friday, June 23, 2017 2:10 AM To: lp-wan ; hackathon@ietf.org=20 Subject: [lp-wan] SCHC testing =20 Hi, =20 The LPWAN compression mechanism SCHC defined in = draft-ietf-lpwan-ipv6-static-context-hc is mature and at least 3 = implementations already exist. During the next Hackathon in Prague, a = LoRaWAN and a Sigfox network will be available to perform test of SCHC = with several objectives: =20 - allow developers to understand SCHC behavior and implement their = own version of the mechanism - test interoperability between the existing implementations - define compression and fragmentation rules related to specific = traffic Come with your own devices or use the pycom devices we will bring to = participate to the real Internet of Things. To participate you need to = register as quickly as possible on = http://ietf.org/hackathon/99-hackathon.html=20 =20 We will provide more technical details on the coming days. =20 Laurent -------------------------------------------------------------------------= ------- _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan -------------------------------------------------------------------------= ------- _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan ------=_NextPart_000_0018_01D2EF3B.5D845BF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
 
The intention of suppression in the draft is to save bits.
Suppose that an IPv6 packet is partioned into N fragments and the = length of=20 Rule ID is R bits.
Using/Adding 2 bits in Dtag as an indication.
As a result, it can save (N-1)*R bits by costing 2*N bits.
 
I am not sure whether it is worth to save these bits by trading off = a few=20 days. 
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
Sent: Tuesday, June 27, 2017 2:36 AM
To: Pascal Thubert (pthubert) ; weigengyu=20 ; Laurent Toutain ; = lp-wan ; hackathon@ietf.org=20
Subject: Re: [lp-wan] [hackathon] SCHC = testing
 

Moving that maturity needle forward is one of the = primary=20 goals of the hackathon. It is great to see projects that work with = established=20 standards and produce code and tools that help others use and develop = solutions=20 on top of those standards, but it is even better to have projects that = speed up=20 and improve the quality of emerging standards.

 

Cheers,

Charles

 

From: = hackathon=20 <hackathon-bounces@ietf.org> on behalf of "Pascal Thubert = (pthubert)"=20 <pthubert@cisco.com>
Date: Monday, June 26, 2017 at 1:32 = AM
To: weigengyu <weigengyu@vip.sina.com>, Laurent = Toutain=20 <laurent.toutain@imt-atlantique.fr>, lp-wan = <lp-wan@ietf.org>,=20 "hackathon@ietf.org" <hackathon@ietf.org>
Subject: Re:=20 [hackathon] [lp-wan] SCHC testing

 

Hello=20 Gengyu

 

I=20 thing that by =E2=80=9Dmature=E2=80=9D Laurent meant = =E2=80=9Cstable=E2=80=9D. And I agree it is stable. It=20 works. We are now getting ready for last call. I agree that real = maturity will=20 come with deployment experience.

 

Cheers;

 

Pascal

From: lp-wan=20 [mailto:lp-wan-bounces@ietf.org] On Behalf Of = weigengyu
Sent:=20 vendredi 23 juin 2017 08:15
To: Laurent Toutain=20 <laurent.toutain@imt-atlantique.fr>; lp-wan = <lp-wan@ietf.org>;=20 hackathon@ietf.org
Subject: Re: [lp-wan] SCHC=20 testing

 

Hi=20 all,

The doc is = just a draft.=20

 

> The LPWAN = compression mechanism SCHC defined in = draft-ietf-lpwan-ipv6-static-context-hc is=20 mature

From a = technical view=20 point, it is not a mature because it can be optimize=20 apparently.

 

Regards,=20

 

Gengyu = WEI
Network=20 Technology Center
School of Computer
Beijing University of Posts = and=20 Telecommunications

 

From: Laurent Toutain=20

Sent: Friday,=20 June 23, 2017 2:10 AM

To: lp-wan ; hackathon@ietf.org=20

Subject:=20 [lp-wan] SCHC testing

 

Hi,

 

The LPWAN = compression=20 mechanism SCHC defined in draft-ietf-lpwan-ipv6-static-context-hc is = mature and=20 at least 3 implementations already exist. During the next Hackathon in = Prague, a=20 LoRaWAN and a Sigfox network will be available to perform test of SCHC = with=20 several objectives:

 

-      =20 allow=20 developers to understand SCHC behavior and implement their own version = of the=20 mechanism

-      =20 test=20 interoperability between the existing = implementations

-      =20 define=20 compression and fragmentation rules related to specific=20 traffic

Come with your = own=20 devices or use the pycom devices we will bring to participate to the = real=20 Internet of Things. To participate you need to register as quickly as = possible=20 on http://ietf.org/hack= athon/99-hackathon.html=20

 

We will = provide more=20 technical details on the coming days.

 

Laurent

_______________________________________________
lp-wan=20 mailing list
lp-wan@ietf.org
https://www.ietf.or= g/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing=20 list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan ------=_NextPart_000_0018_01D2EF3B.5D845BF0-- From nobody Tue Jun 27 00:31:28 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2222A127B57; Tue, 27 Jun 2017 00:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 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 AMJQHp8zm_ul; Tue, 27 Jun 2017 00:31:24 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181CE127869; Tue, 27 Jun 2017 00:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9498; q=dns/txt; s=iport; t=1498548684; x=1499758284; h=from:to:cc:subject:date:message-id:mime-version; bh=FkoTiHXMRHwSOfzsO9bOmloVaCzdGuiR5sTyLVXvDtM=; b=DOUFgIvNLV6aaadvaHjJNKOKnqfkKn7luO7OjR+iZA3GHYHtLGhUIvmd H/o37smi4qODwmBCRPfBJfo86gtu7pU2kc60VDP+DjCR5lgNtgaL2F55E YhFlijNvu39CxWKz0ZaaQQtvcSBIGRZl8d+gLNl/NKp/bvRD0y+hITPLE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuAQD6CFJZ/4wNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9pYoENB41+ojOFK4IRLIV4gnU/GAECAQEBAQEBAWsdC4VMTBIBgQA?= =?us-ascii?q?mAQQODYlEZBCxbYtbAQEBAQEBAQEBAQEBAQEBAQEBAQEZBYMng0yIK4c4BZBFj?= =?us-ascii?q?ioChzSMK4IThUmKQYkri3gBHziBCnQVSYcTdgGIDoENAQEB?= X-IronPort-AV: E=Sophos;i="5.39,399,1493683200"; d="scan'208,217";a="446348413" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jun 2017 07:31:23 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v5R7VN53009370 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 07:31:23 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Jun 2017 02:31:22 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 27 Jun 2017 02:31:22 -0500 From: "Pascal Thubert (pthubert)" To: "lp-wan@ietf.org" CC: "lpwan-chairs@ietf.org" Thread-Topic: Agenda Items for LPWAN F2F Meeting in Prague Thread-Index: AdLvFuF61BfO3GWfTWeWh8Gbtd9Qpg== Date: Tue, 27 Jun 2017 07:30:58 +0000 Deferred-Delivery: Tue, 27 Jun 2017 07:30:08 +0000 Message-ID: <621d7e2bfe3541ccbe86b99bedb2cd69@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_621d7e2bfe3541ccbe86b99bedb2cd69XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Agenda Items for LPWAN F2F Meeting in Prague X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 07:31:26 -0000 --_000_621d7e2bfe3541ccbe86b99bedb2cd69XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear LPWANers, The final agenda for IETF 99 has been published at: https://datatracker.iet= f.org/meeting/99/agenda.html. Keep this link, it's always useful with a num= ber of pointers to meeting needful things. Also consider the IETF applicati= on for your smartphone... There was no option but push LPWAN to the end of the week, so we will be me= eting on Friday July 21st from 9:30 to 11:30, during the Morning session I = in room Karlin I/II. If you'd like a slot to present a draft, please send a request to the chair= s (cc) by Monday July 3rd. Please note that this is also the deadline for d= raft submission. Please provide the following information: - Draft name - Presenter name - Expected duration - Objective of the discussion We kindly request to send your slides for presentations by Wednesday, July = 12th. A template will be provided. Any WG draft not being discussed/presented needs a status update sent to th= e list by July 12th. As always - we would appreciate your help in taking notes and jabber, pleas= e do volunteer! Looking forward to seeing you in all Prague! Cheers, Alexander and Pascal --_000_621d7e2bfe3541ccbe86b99bedb2cd69XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear LPWANers,

 

The final agenda for IETF 99 has been published a= t: https://datatracker.ietf.org/meeting/99/agenda.html. Keep this link, it= 's always useful with a number of pointers to meeting needful things. Also = consider the IETF application for your smartphone...

 

There was no option but push LPWAN to the end of = the week, so we will be meeting on Friday July 21st from 9:30 to= 11:30, during the Morning session I in room Karlin I/II.

 

If you'd like a slot to present a draft, please s= end a request to the chairs (cc) by Monday July 3rd. Please note= that this is also the deadline for draft submission.

 

Please provide the following information:

-       = ;  Draft name

-       = ;  Presenter name

-       = ;  Expected duration

-       = ;  Objective of the discussion

 

We kindly request to send your slides for present= ations by Wednesday, July 12th. A template will be provided.

 

Any WG draft not being discussed/presented needs = a status update sent to the list by July 12th.

 

As always - we would appreciate your help in taki= ng notes and jabber, please do volunteer!

 

Looking forward to seeing you in all Prague!=

 

Cheers,

 

Alexander and Pascal=

 

--_000_621d7e2bfe3541ccbe86b99bedb2cd69XCHRCD001ciscocom_-- From nobody Tue Jun 27 07:22:42 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC10129B40 for ; Tue, 27 Jun 2017 07:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 wR95n1YlQ2AD for ; Tue, 27 Jun 2017 07:22:38 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 9EECD129B35 for ; Tue, 27 Jun 2017 07:22:37 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5REMRXW049027; Tue, 27 Jun 2017 16:22:27 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D126E1D53C1; Tue, 27 Jun 2017 16:22:26 +0200 (CEST) Received: from 83.38.152.35 by webmail.entel.upc.edu with HTTP; Tue, 27 Jun 2017 16:21:55 +0200 Message-ID: <23622a341606ebed36588747e92607b2.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> Date: Tue, 27 Jun 2017 16:21:55 +0200 From: "Carles Gomez Montenegro" To: "weigengyu" Cc: "Pascal Thubert \(pthubert\)" , lp-wan@ietf.org, arun@ackl.io User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at violet X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Tue, 27 Jun 2017 16:22:28 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 14:22:41 -0000 Hi Gengyu, Thanks for your proposal, I see you are trying to reduce header overhead. However, I'm afraid there are still issues with it. In the context of the SCHC specification, an L2 LPWAN frame may carry an unfragmented IPv6 datagram with a compressed header (see Fig. 4). The Rule ID is the first field of the compressed IPv6 datagram. When a compressed IPv6 datagram needs to be fragmented, then some Rule ID space (of size R bits) is 'stolen' and used for fragmentation functionality. So a requirement here is that whatever is defined for fragmentation needs to be consistent with the format used for header compression. Some special Rule ID (or set of Rule IDs in terms of R-bit patterns) needs to be used to signal that a data unit being carried is a fragment. Note that we cannot risk communication failure due to e.g. loss of a first fragment (which in your proposal carries a Rule ID) followed by other fragments (which in your proposal do not carry a Rule ID) that are actually received. In such case, a receiver may process the received data units as e.g. unfragmented (compressed) IPv6 datagrams. Cheers, Carles > Hi Pascal, > >> We need the Rule to say fragment on each fragment, > All framents of a IPv6 packet obey one rule, the Rule ID is included in > the > first fragment is enough for conveying this information. > >> and then the dtag. > All framents of the packet contain the same Dtag as defined. > >> Starting the next fragment with the dtag would confuse the parser which >> would interpret the dtag as another rule. > Put the Dtag at the front. > Defining the first two bits of Dtag as an indication of the first > fragment, > fragments of the minddle and the last fragment. > > 00 the first fragment > 10 fragments of the minddle > 11 the last fragment > > If the first two bits are '00', the Rule ID is followed. > If the first two bits are not '00', the fragment does not contain the Rule > ID. > If the first two bits are 11, it is the last fragment. > > I believe that it is worth to have this two bit to suppress the space of > Rule ID in the successive fragments. > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications From nobody Tue Jun 27 18:50:07 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D014212420B for ; Tue, 27 Jun 2017 18:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 pTLDDcziE4Yq for ; Tue, 27 Jun 2017 18:50:02 -0700 (PDT) Received: from smtp-6-46.vip.sina.com.cn (r3-66.sinamail.sina.com.cn [202.108.3.66]) by ietfa.amsl.com (Postfix) with SMTP id 4A9AC1200CF for ; Tue, 27 Jun 2017 18:50:00 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.255.40.35]) by vip.sina.com with ESMTP 28 Jun 2017 09:49:54 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 393845290089 Message-ID: <63E493F830B247189870EB052E737878@WeiGengyuPC> From: "weigengyu" To: "Carles Gomez Montenegro" Cc: , , "Pascal Thubert \(pthubert\)" References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> <23622a341606ebed36588747e92607b2.squirrel@webmail.entel.upc.edu> In-Reply-To: <23622a341606ebed36588747e92607b2.squirrel@webmail.entel.upc.edu> Date: Wed, 28 Jun 2017 09:49:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 01:50:06 -0000 Hi Carles, > In the context of the SCHC specification, an L2 LPWAN frame may carry an > unfragmented IPv6 datagram with a compressed header (see Fig. 4). This doc is just a draft. The format in Fig.4 can be re-organized to get the suppression optimized. > The Rule ID is the first field of the compressed IPv6 datagram. Defining the first two bits are defined as an indications, these problems ara solved. If it is 00, the fragment is the first and contains a Rule ID. If the Rule ID says this is an unfragment datagram, let it go; If the Rule ID says this is an fragmented one, you then get the Dtag. If it is not 00, you need to get the Dtag for the fragment, and get the Rule ID by the Dtag. > When a compressed IPv6 datagram needs to be fragmented, then some Rule ID > space (of size R bits) is 'stolen' and used for fragmentation > functionality. So a requirement here is that whatever is defined for > fragmentation needs to be consistent with the format used for header > compression. Some special Rule ID (or set of Rule IDs in terms of R-bit > patterns) needs to be used to signal that a data unit being carried is a > fragment. It has been clarified that only one Rule ID is required for an IPv6 packets if it is framennted. Or fragments belonged to one IPv6 packet just needs one Rule ID. The Rule ID can be carried in the frist fragment to the receiver. Only one is enough for conveying this information. > Note that we cannot risk communication failure due to e.g. loss of a first > fragment (which in your proposal carries a Rule ID) followed by other > fragments (which in your proposal do not carry a Rule ID) that are > actually received. In such case, a receiver may process the received data > units as e.g. unfragmented (compressed) IPv6 datagrams. Could you explain how the receiver precesses fragments without getting the first fragment of an fragmented IPv6 packet? No, it cannot by the current draft either. Can you explain how the the current draft avoids the risk of communication failure due to e.g. loss of a first fragment? It is not available to have each fragment processed independently by the current draft. > In such case, a receiver may process the received data units as e.g. > unfragmented (compressed) IPv6 datagrams. What is an unfragmented (compressed) IPv6 datagram? If it is an unfragmented, it is the first, it contain the Rule ID. Do you suppose it lost? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carles Gomez Montenegro Sent: Tuesday, June 27, 2017 10:21 PM To: weigengyu Cc: lp-wan@ietf.org ; arun@ackl.io ; Pascal Thubert (pthubert) Subject: Re: [lp-wan] Fw: re-order header field request Hi Gengyu, Thanks for your proposal, I see you are trying to reduce header overhead. However, I'm afraid there are still issues with it. In the context of the SCHC specification, an L2 LPWAN frame may carry an unfragmented IPv6 datagram with a compressed header (see Fig. 4). The Rule ID is the first field of the compressed IPv6 datagram. When a compressed IPv6 datagram needs to be fragmented, then some Rule ID space (of size R bits) is 'stolen' and used for fragmentation functionality. So a requirement here is that whatever is defined for fragmentation needs to be consistent with the format used for header compression. Some special Rule ID (or set of Rule IDs in terms of R-bit patterns) needs to be used to signal that a data unit being carried is a fragment. Note that we cannot risk communication failure due to e.g. loss of a first fragment (which in your proposal carries a Rule ID) followed by other fragments (which in your proposal do not carry a Rule ID) that are actually received. In such case, a receiver may process the received data units as e.g. unfragmented (compressed) IPv6 datagrams. Cheers, Carles > Hi Pascal, > >> We need the Rule to say fragment on each fragment, > All framents of a IPv6 packet obey one rule, the Rule ID is included in > the > first fragment is enough for conveying this information. > >> and then the dtag. > All framents of the packet contain the same Dtag as defined. > >> Starting the next fragment with the dtag would confuse the parser which >> would interpret the dtag as another rule. > Put the Dtag at the front. > Defining the first two bits of Dtag as an indication of the first > fragment, > fragments of the minddle and the last fragment. > > 00 the first fragment > 10 fragments of the minddle > 11 the last fragment > > If the first two bits are '00', the Rule ID is followed. > If the first two bits are not '00', the fragment does not contain the Rule > ID. > If the first two bits are 11, it is the last fragment. > > I believe that it is worth to have this two bit to suppress the space of > Rule ID in the successive fragments. > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications _______________________________________________ lp-wan mailing list lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan From nobody Wed Jun 28 00:05:59 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFAC12EAAB for ; Wed, 28 Jun 2017 00:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=actility.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 B3Mf63em66gx for ; Wed, 28 Jun 2017 00:05:55 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 2B81812EA55 for ; Wed, 28 Jun 2017 00:05:55 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id w126so43974099wme.0 for ; Wed, 28 Jun 2017 00:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=actility.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=zQRQs3QcCfxMpX7DVRxkBTHz+i5wCKiC6malW7ic7Vc=; b=JvNCTyQ7BpWF9Rzj3oKW+UIvNktdUBsCfzPBxPGiibOO9aJzI94syJG6oNN7nuyb3Y DBtDNbWSYMwZfG2FFAt+u3yPEdxsRDkVqDgLbVGZcjwWLIQjSOyDEa8vMLyVpyuwLgZT KxJX6RJtSHtfCm0F87gcySHOK2Wwv0esSKkuc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=zQRQs3QcCfxMpX7DVRxkBTHz+i5wCKiC6malW7ic7Vc=; b=aI0141+PFhOE++gs9zRZ5I4OV1jewv7yBmuNEgkonL7ddHZyKcaewjShCNDH6zUW5w A3ljj3P5FmOf7Xq1MF5t/GMF65BVfXiUAhhr+HBGVlsEWMsa/wRUJplvVP5RHiXz9fVz xZVJDXPivI4BvMHe2eHru5yMZt/J6k2WK/gtBew4iybxJGBCCeJ6FGSVpGHBfXXnxUpN XY/C9a1MDJburcrF9xPRxFenoYN+2+bISj6ZVEmQvJ0lQRkG9X1fs7iW+LPBMiBMQFNO 81gbKnNOjAzzTzAavTWAEpG4QSq80DOytMb3RnAX4Uz3VEd+64bebomuBN59HqSxii/A nr3g== X-Gm-Message-State: AKS2vOwWshXCE978pJrHsK+5YsOE+yY0wiN+nw+QVRovZnEk/g7nMJNn sX0NE2mvYPLh10TejWnbug== X-Received: by 10.28.51.212 with SMTP id z203mr6334068wmz.103.1498633552980; Wed, 28 Jun 2017 00:05:52 -0700 (PDT) Received: from [192.168.2.182] ([88.235.161.246]) by smtp.gmail.com with ESMTPSA id m63sm3921808wma.18.2017.06.28.00.05.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 00:05:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D51D7893-7AFF-4898-9569-566D9D08CD64" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Alper Yegin X-Priority: 3 In-Reply-To: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> Date: Wed, 28 Jun 2017 10:05:51 +0300 Cc: Stephen Farrell Message-Id: References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> To: lp-wan@ietf.org X-Mailer: Apple Mail (2.3226) Archived-At: Subject: [lp-wan] lpwan-overview comments X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 07:05:57 -0000 --Apple-Mail=_D51D7893-7AFF-4898-9569-566D9D08CD64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear LPWAN WG members and Stephen, I made one more pass over the LoRaWAN section of the I-D and spotted the = following points: A LoRaWAN network has a short network identifier ("NwkID") which is a seven-bit value. A private network (common for LoRaWAN) can use the value zero. =20 If a network wishes to support "foreign" end-devices then the NwkID needs to be registered with the LoRA Alliance, in which case the NwkID is the seven least significant bits of a registered 24-bit NetID. (Note however, that the methods for "roaming" are defined in the upcoming LoRaWAN 1.1 specification.) In order to operate nominally on a LoRaWAN network, a device needs a 32-bit device address, which is the catenation of the NwkID and a 25-bit device-specific network address that is assigned when the device "joins" the network (see below for the join procedure) or that is pre-provisioned into the device. In the LoRa Alliance we made a change to the way DevAddrs are generated = based on the NetIDs. It=E2=80=99s no longer simply using the 7 = least-significant-bits of NetID as the 7 most-significant-bits of the = DevAddr. Even though the generation scheme was already described in the = LoRaWAN 1.0 spec, the end-device always treated the DevAddr as a 32bit = value, hence it did not matter how that value was generated as far as = the end-device is concerned. The new scheme, which allows more efficient = allocation and use of NetIDs, is described in the Backend Interfaces = spec, which is not published yet. What that means is, in this I-D, we better not describe "NwkID=3D7 = bits=E2=80=9D detail.=20 So, I=E2=80=99d propose to rewrite the above 3 paragraphs as follows = (further text massage welcome!): In order to operate nominally on a LoRaWAN network, a device needs a 32-bit device address, that is assigned when the device "joins" the network (see below for the join procedure) or that is pre-provisioned into the device. In case of roaming devices, the = device address is assigned based on the 24-bit NetID that is allocated to the = networks by the LoRa Alliance. Non-roaming devices can be assigned device = addresses by the network without relying on a LoRa Alliance-assigned NetID. End-devices are assumed to work with one or a quite limited number of applications, identified by a 64-bit AppEUI, which is assumed to be a registered IEEE EUI64 value. AppEUI is being renamed as JoinEUI in LoRaWAN 1.1, and in fact it = identifies the JS. JoinEUI and JS terms are not present in LW1.0.x, but nevertheless the = latest definition of the AppEUI in LW1.0.2 is as follows: The AppEUI is a global application ID in IEEE EUI64 address space that = uniquely identifies the entity able to process the JoinReq frame. =20 So, we better not treat it as application identifier, but as identifier = of the entity that can authenticate the Join-request frames. For example, instead of: AppEUI IEEE EUI64 naming the application We better say: AppEUI IEEE EUI64 naming the entity that processes Join-request Thanks Stephen. Alper= --Apple-Mail=_D51D7893-7AFF-4898-9569-566D9D08CD64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear = LPWAN WG members and Stephen,

I made one more pass over the LoRaWAN = section of the I-D and spotted the following points:


   A LoRaWAN network has a short = network identifier ("NwkID") which is a
  =  seven-bit value.  A private network (common for LoRaWAN) can = use the
   value zero.  

   If a = network wishes to support "foreign" end-devices
   then the NwkID needs to be registered with the = LoRA Alliance, in
   which case the NwkID = is the seven least significant bits of a
  =  registered 24-bit NetID.  (Note however, that the methods = for
   "roaming" are defined in the = upcoming LoRaWAN 1.1 specification.)

   In order to operate = nominally on a LoRaWAN network, a device needs a
   32-bit device address, which is the catenation = of the NwkID and a
   25-bit = device-specific network address that is assigned when the
   device "joins" the network (see below for the = join procedure) or that
   is = pre-provisioned into the device.


In = the LoRa Alliance we made a change to the way DevAddrs are generated = based on the NetIDs. It=E2=80=99s no longer simply using the 7 = least-significant-bits of NetID as the 7 most-significant-bits of the = DevAddr. Even though the generation scheme was already described in the = LoRaWAN 1.0 spec, the end-device always treated the DevAddr as a 32bit = value, hence it did not matter how that value was generated as far as = the end-device is concerned. The new scheme, which allows more efficient = allocation and use of NetIDs, is described in the Backend Interfaces = spec, which is not published yet.

What that means is, in this I-D, we = better not describe "NwkID=3D7 bits=E2=80=9D detail. 

So, I=E2=80=99d =  propose to rewrite the above 3 paragraphs as follows (further text = massage welcome!):


   In order to operate nominally on a LoRaWAN = network, a device needs a
   32-bit = device address, that is assigned when the
  =  device "joins" the network (see below for the join procedure) or = that
   is pre-provisioned into the = device.  In case of roaming devices, the device address
   is assigned based on the 24-bit NetID that is = allocated to the networks
   by the LoRa = Alliance. Non-roaming devices can be assigned device addresses
   by the network without relying on a LoRa = Alliance-assigned NetID.







  =  End-devices are assumed to work with one or a quite limited number = of
   applications, identified by a = 64-bit AppEUI, which is assumed to be a
  =  registered IEEE EUI64 value.



AppEUI is being renamed as JoinEUI in = LoRaWAN 1.1, and in fact it identifies the JS.
JoinEUI and JS terms are not present in LW1.0.x, but = nevertheless the latest definition of the AppEUI in LW1.0.2 is as = follows:



  1. The AppEUI is a global application = ID in IEEE EUI64 address space that uniquely = identifies

  2. the entity able to = process the JoinReq frame.

     
So, we better not treat it as application identifier, = but as identifier of the entity that can authenticate the Join-request = frames.

For = example, instead of:

AppEUI= IEEE EUI64 naming the application

We better say:

AppEUI IEEE = EUI64 naming the entity that processes Join-request




Thanks = Stephen.

Alper
= --Apple-Mail=_D51D7893-7AFF-4898-9569-566D9D08CD64-- From nobody Wed Jun 28 00:56:25 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F62812EB9B for ; Wed, 28 Jun 2017 00:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 uQMou4eSazya for ; Wed, 28 Jun 2017 00:56:18 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86CA12EB69 for ; Wed, 28 Jun 2017 00:56:17 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:3c93:6293:46d1:601a] (unknown [IPv6:2001:660:7301:3728:3c93:6293:46d1:601a]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 2158CC5A61; Wed, 28 Jun 2017 09:56:14 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B312A701-1418-4EFD-81BF-97427623EAD1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Alexander Pelov X-Priority: 3 In-Reply-To: Date: Wed, 28 Jun 2017 09:56:10 +0200 Cc: lp-wan@ietf.org, Stephen Farrell Message-Id: <13FF95DD-C195-472D-8DB5-74C9B374FFF2@ackl.io> References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> To: Alper Yegin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lp-wan] lpwan-overview comments X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 07:56:22 -0000 --Apple-Mail=_B312A701-1418-4EFD-81BF-97427623EAD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the comments and the detailed review, Alper! I guess the changes you describe are not likely to be changed until the = specs you describe get published, right? Thanks again, Alexander > Le 28 juin 2017 =C3=A0 09:05, Alper Yegin a = =C3=A9crit : >=20 > Dear LPWAN WG members and Stephen, >=20 > I made one more pass over the LoRaWAN section of the I-D and spotted = the following points: >=20 >=20 > A LoRaWAN network has a short network identifier ("NwkID") which is = a > seven-bit value. A private network (common for LoRaWAN) can use = the > value zero. =20 >=20 > If a network wishes to support "foreign" end-devices > then the NwkID needs to be registered with the LoRA Alliance, in > which case the NwkID is the seven least significant bits of a > registered 24-bit NetID. (Note however, that the methods for > "roaming" are defined in the upcoming LoRaWAN 1.1 specification.) >=20 > In order to operate nominally on a LoRaWAN network, a device needs = a > 32-bit device address, which is the catenation of the NwkID and a > 25-bit device-specific network address that is assigned when the > device "joins" the network (see below for the join procedure) or = that > is pre-provisioned into the device. >=20 >=20 > In the LoRa Alliance we made a change to the way DevAddrs are = generated based on the NetIDs. It=E2=80=99s no longer simply using the 7 = least-significant-bits of NetID as the 7 most-significant-bits of the = DevAddr. Even though the generation scheme was already described in the = LoRaWAN 1.0 spec, the end-device always treated the DevAddr as a 32bit = value, hence it did not matter how that value was generated as far as = the end-device is concerned. The new scheme, which allows more efficient = allocation and use of NetIDs, is described in the Backend Interfaces = spec, which is not published yet. >=20 > What that means is, in this I-D, we better not describe "NwkID=3D7 = bits=E2=80=9D detail.=20 >=20 > So, I=E2=80=99d propose to rewrite the above 3 paragraphs as follows = (further text massage welcome!): >=20 >=20 > In order to operate nominally on a LoRaWAN network, a device needs = a > 32-bit device address, that is assigned when the > device "joins" the network (see below for the join procedure) or = that > is pre-provisioned into the device. In case of roaming devices, = the device address > is assigned based on the 24-bit NetID that is allocated to the = networks > by the LoRa Alliance. Non-roaming devices can be assigned device = addresses > by the network without relying on a LoRa Alliance-assigned NetID. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > End-devices are assumed to work with one or a quite limited number = of > applications, identified by a 64-bit AppEUI, which is assumed to be = a > registered IEEE EUI64 value. >=20 >=20 >=20 > AppEUI is being renamed as JoinEUI in LoRaWAN 1.1, and in fact it = identifies the JS. > JoinEUI and JS terms are not present in LW1.0.x, but nevertheless the = latest definition of the AppEUI in LW1.0.2 is as follows: >=20 >=20 >=20 > The AppEUI is a global application ID in IEEE EUI64 address space that = uniquely identifies >=20 > the entity able to process the JoinReq frame. >=20 > =20 > So, we better not treat it as application identifier, but as = identifier of the entity that can authenticate the Join-request frames. >=20 > For example, instead of: >=20 > AppEUI IEEE EUI64 naming the application >=20 > We better say: >=20 > AppEUI IEEE EUI64 naming the entity that processes Join-request >=20 >=20 >=20 >=20 > Thanks Stephen. >=20 > Alper > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --Apple-Mail=_B312A701-1418-4EFD-81BF-97427623EAD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks for the comments and the detailed = review, Alper!

I= guess the changes you describe are not likely to be changed until the = specs you describe get published, right?

Thanks again,
Alexander


Le = 28 juin 2017 =C3=A0 09:05, Alper Yegin <alper.yegin@actility.com> a =C3=A9crit :

Dear = LPWAN WG members and Stephen,

I made one more pass over the LoRaWAN = section of the I-D and spotted the following points:


   A LoRaWAN network has a short = network identifier ("NwkID") which is a
  =  seven-bit value.  A private network (common for LoRaWAN) can = use the
   value zero.  

   If a = network wishes to support "foreign" end-devices
   then the NwkID needs to be registered with the = LoRA Alliance, in
   which case the NwkID = is the seven least significant bits of a
  =  registered 24-bit NetID.  (Note however, that the methods = for
   "roaming" are defined in the = upcoming LoRaWAN 1.1 specification.)

   In order to operate = nominally on a LoRaWAN network, a device needs a
   32-bit device address, which is the catenation = of the NwkID and a
   25-bit = device-specific network address that is assigned when the
   device "joins" the network (see below for the = join procedure) or that
   is = pre-provisioned into the device.


In = the LoRa Alliance we made a change to the way DevAddrs are generated = based on the NetIDs. It=E2=80=99s no longer simply using the 7 = least-significant-bits of NetID as the 7 most-significant-bits of the = DevAddr. Even though the generation scheme was already described in the = LoRaWAN 1.0 spec, the end-device always treated the DevAddr as a 32bit = value, hence it did not matter how that value was generated as far as = the end-device is concerned. The new scheme, which allows more efficient = allocation and use of NetIDs, is described in the Backend Interfaces = spec, which is not published yet.

What that means is, in this I-D, we = better not describe "NwkID=3D7 bits=E2=80=9D detail. 

So, I=E2=80=99d =  propose to rewrite the above 3 paragraphs as follows (further text = massage welcome!):


   In order to operate nominally on a LoRaWAN = network, a device needs a
   32-bit = device address, that is assigned when the
  =  device "joins" the network (see below for the join procedure) or = that
   is pre-provisioned into the = device.  In case of roaming devices, the device address
   is assigned based on the 24-bit NetID that is = allocated to the networks
   by the LoRa = Alliance. Non-roaming devices can be assigned device addresses
   by the network without relying on a LoRa = Alliance-assigned NetID.







  =  End-devices are assumed to work with one or a quite limited number = of
   applications, identified by a = 64-bit AppEUI, which is assumed to be a
  =  registered IEEE EUI64 value.



AppEUI is being renamed as JoinEUI in = LoRaWAN 1.1, and in fact it identifies the JS.
JoinEUI and JS terms are not present in LW1.0.x, but = nevertheless the latest definition of the AppEUI in LW1.0.2 is as = follows:



  1. The AppEUI is a global application = ID in IEEE EUI64 address space that uniquely = identifies

  2. the entity able to = process the JoinReq frame.

     
So, we better not treat it as application identifier, = but as identifier of the entity that can authenticate the Join-request = frames.

For = example, instead of:

AppEUI= IEEE EUI64 naming the application

We better say:

AppEUI IEEE = EUI64 naming the entity that processes Join-request




Thanks = Stephen.

Alper
______________________________________________= _
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan

= --Apple-Mail=_B312A701-1418-4EFD-81BF-97427623EAD1-- From nobody Wed Jun 28 01:06:05 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481E912EBF3 for ; Wed, 28 Jun 2017 01:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=actility.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 tUNwJmQCnSCX for ; Wed, 28 Jun 2017 01:06:01 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 3337D12EB78 for ; Wed, 28 Jun 2017 01:06:01 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id k67so169647952wrc.2 for ; Wed, 28 Jun 2017 01:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=actility.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ckASVvTp/0kiPy+3tuJSxJW7o/GS5I+C+rMEHeCvUVU=; b=Of69fY/dNqRrUaXJWy4g9zaghXOUJgtJdPWKohYRI0OiT53HbsD8lii8fyqmw1W8Ee WRl0uYFusKG0WeLg2M2M1ubwrKx3ksSXV0rwqx1s34sEzgkQmEc7A3LIGNFycz1/xJw9 ssiRabNslTLeEDVPOwb9pfPZ0d4KdyPMMa3ME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ckASVvTp/0kiPy+3tuJSxJW7o/GS5I+C+rMEHeCvUVU=; b=o4KJ56YDJexZjZeVjYIIRfMUODbLzuDfjtOf3aTabDH4vWjLhm3OOUGBMlRQWahh7J eaMhh+xG9WNKY0p1lKZ1lwa9Pei/X/HZTUP1vhPNms/PHtMbfIKfDewEiwO8eRAEykJX CEURuT4tiF9qMfM1LUiZpZM6YRGZJg9/ue2prucyAbmzO7+skepgbJHXvfY2cOidK/xX Hkh0ggO6YoBJU4OE8lUcr7h8nQljTb2IetkbEm2NzrlJKtBQ6WDWJg5/9HqLUm4ue9wc FiGOlNBztrW41IB0HLjY6R4vLr7hY5d2PGiDjkCgSisRJWnZ5Rd8c+bYCG47WknlRq1c Y1yA== X-Gm-Message-State: AKS2vOxR4bVYkrw5mxh30qix/EKrbtweyU5cJmaNYR1XpVLdOxRItRmt TuDwuk2lueKJRBfb6/7yeg== X-Received: by 10.223.180.67 with SMTP id v3mr13301160wrd.0.1498637159635; Wed, 28 Jun 2017 01:05:59 -0700 (PDT) Received: from [192.168.2.182] ([88.235.161.246]) by smtp.gmail.com with ESMTPSA id o6sm1207585wrc.48.2017.06.28.01.05.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 01:05:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F81A6237-5EBE-46B5-BA38-65C0E01EDD3F" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Alper Yegin X-Priority: 3 In-Reply-To: <13FF95DD-C195-472D-8DB5-74C9B374FFF2@ackl.io> Date: Wed, 28 Jun 2017 11:05:57 +0300 Cc: lp-wan@ietf.org, Stephen Farrell Message-Id: References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <13FF95DD-C195-472D-8DB5-74C9B374FFF2@ackl.io> To: Alexander Pelov X-Mailer: Apple Mail (2.3226) Archived-At: Subject: Re: [lp-wan] lpwan-overview comments X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 08:06:04 -0000 --Apple-Mail=_F81A6237-5EBE-46B5-BA38-65C0E01EDD3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alex, No, they=E2=80=99d not. Btw, the I-D is based on the LoRaWAN 1.0.2. And we are working towards publishing the LoRaWAN 1.1 in September. Depending on the pace of IETF processing this I-D, it may stay with = LoRaWAN 1.0.2 details, or an update may fold in LoRaWAN 1.1 changes as = well. Alper > On Jun 28, 2017, at 10:56 AM, Alexander Pelov wrote: >=20 > Thanks for the comments and the detailed review, Alper! >=20 > I guess the changes you describe are not likely to be changed until = the specs you describe get published, right? >=20 > Thanks again, > Alexander >=20 >=20 >> Le 28 juin 2017 =C3=A0 09:05, Alper Yegin > a =C3=A9crit : >>=20 >> Dear LPWAN WG members and Stephen, >>=20 >> I made one more pass over the LoRaWAN section of the I-D and spotted = the following points: >>=20 >>=20 >> A LoRaWAN network has a short network identifier ("NwkID") which = is a >> seven-bit value. A private network (common for LoRaWAN) can use = the >> value zero. =20 >>=20 >> If a network wishes to support "foreign" end-devices >> then the NwkID needs to be registered with the LoRA Alliance, in >> which case the NwkID is the seven least significant bits of a >> registered 24-bit NetID. (Note however, that the methods for >> "roaming" are defined in the upcoming LoRaWAN 1.1 specification.) >>=20 >> In order to operate nominally on a LoRaWAN network, a device needs = a >> 32-bit device address, which is the catenation of the NwkID and a >> 25-bit device-specific network address that is assigned when the >> device "joins" the network (see below for the join procedure) or = that >> is pre-provisioned into the device. >>=20 >>=20 >> In the LoRa Alliance we made a change to the way DevAddrs are = generated based on the NetIDs. It=E2=80=99s no longer simply using the 7 = least-significant-bits of NetID as the 7 most-significant-bits of the = DevAddr. Even though the generation scheme was already described in the = LoRaWAN 1.0 spec, the end-device always treated the DevAddr as a 32bit = value, hence it did not matter how that value was generated as far as = the end-device is concerned. The new scheme, which allows more efficient = allocation and use of NetIDs, is described in the Backend Interfaces = spec, which is not published yet. >>=20 >> What that means is, in this I-D, we better not describe "NwkID=3D7 = bits=E2=80=9D detail.=20 >>=20 >> So, I=E2=80=99d propose to rewrite the above 3 paragraphs as follows = (further text massage welcome!): >>=20 >>=20 >> In order to operate nominally on a LoRaWAN network, a device needs = a >> 32-bit device address, that is assigned when the >> device "joins" the network (see below for the join procedure) or = that >> is pre-provisioned into the device. In case of roaming devices, = the device address >> is assigned based on the 24-bit NetID that is allocated to the = networks >> by the LoRa Alliance. Non-roaming devices can be assigned device = addresses >> by the network without relying on a LoRa Alliance-assigned NetID. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> End-devices are assumed to work with one or a quite limited number = of >> applications, identified by a 64-bit AppEUI, which is assumed to = be a >> registered IEEE EUI64 value. >>=20 >>=20 >>=20 >> AppEUI is being renamed as JoinEUI in LoRaWAN 1.1, and in fact it = identifies the JS. >> JoinEUI and JS terms are not present in LW1.0.x, but nevertheless the = latest definition of the AppEUI in LW1.0.2 is as follows: >>=20 >>=20 >>=20 >> The AppEUI is a global application ID in IEEE EUI64 address space = that uniquely identifies >>=20 >> the entity able to process the JoinReq frame. >>=20 >> =20 >> So, we better not treat it as application identifier, but as = identifier of the entity that can authenticate the Join-request frames. >>=20 >> For example, instead of: >>=20 >> AppEUI IEEE EUI64 naming the application >>=20 >> We better say: >>=20 >> AppEUI IEEE EUI64 naming the entity that processes Join-request >>=20 >>=20 >>=20 >>=20 >> Thanks Stephen. >>=20 >> Alper >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >=20 --Apple-Mail=_F81A6237-5EBE-46B5-BA38-65C0E01EDD3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alex,

No, they=E2=80=99d not.
Btw, the I-D is = based on the LoRaWAN 1.0.2.
And we are working = towards publishing the LoRaWAN 1.1 in September.
Depending on the pace of IETF processing this I-D, it may = stay with LoRaWAN 1.0.2 details, or an update may fold in LoRaWAN 1.1 = changes as well.

Alper





On = Jun 28, 2017, at 10:56 AM, Alexander Pelov <a@ackl.io> wrote:

Thanks for the comments and the detailed review, = Alper!

I guess = the changes you describe are not likely to be changed until the specs = you describe get published, right?

Thanks again,
Alexander


Le 28 juin 2017 =C3=A0 09:05, Alper Yegin <alper.yegin@actility.com> a =C3=A9crit :

Dear = LPWAN WG members and Stephen,

I made one more pass over the LoRaWAN = section of the I-D and spotted the following points:


   A LoRaWAN network has a short = network identifier ("NwkID") which is a
  =  seven-bit value.  A private network (common for LoRaWAN) can = use the
   value zero.  

   If a = network wishes to support "foreign" end-devices
   then the NwkID needs to be registered with the = LoRA Alliance, in
   which case the NwkID = is the seven least significant bits of a
  =  registered 24-bit NetID.  (Note however, that the methods = for
   "roaming" are defined in the = upcoming LoRaWAN 1.1 specification.)

   In order to operate = nominally on a LoRaWAN network, a device needs a
   32-bit device address, which is the catenation = of the NwkID and a
   25-bit = device-specific network address that is assigned when the
   device "joins" the network (see below for the = join procedure) or that
   is = pre-provisioned into the device.


In = the LoRa Alliance we made a change to the way DevAddrs are generated = based on the NetIDs. It=E2=80=99s no longer simply using the 7 = least-significant-bits of NetID as the 7 most-significant-bits of the = DevAddr. Even though the generation scheme was already described in the = LoRaWAN 1.0 spec, the end-device always treated the DevAddr as a 32bit = value, hence it did not matter how that value was generated as far as = the end-device is concerned. The new scheme, which allows more efficient = allocation and use of NetIDs, is described in the Backend Interfaces = spec, which is not published yet.

What that means is, in this I-D, we = better not describe "NwkID=3D7 bits=E2=80=9D detail. 

So, I=E2=80=99d =  propose to rewrite the above 3 paragraphs as follows (further text = massage welcome!):


   In order to operate nominally on a LoRaWAN = network, a device needs a
   32-bit = device address, that is assigned when the
  =  device "joins" the network (see below for the join procedure) or = that
   is pre-provisioned into the = device.  In case of roaming devices, the device address
   is assigned based on the 24-bit NetID that is = allocated to the networks
   by the LoRa = Alliance. Non-roaming devices can be assigned device addresses
   by the network without relying on a LoRa = Alliance-assigned NetID.







  =  End-devices are assumed to work with one or a quite limited number = of
   applications, identified by a = 64-bit AppEUI, which is assumed to be a
  =  registered IEEE EUI64 value.



AppEUI is being renamed as JoinEUI in = LoRaWAN 1.1, and in fact it identifies the JS.
JoinEUI and JS terms are not present in LW1.0.x, but = nevertheless the latest definition of the AppEUI in LW1.0.2 is as = follows:



  1. The AppEUI is a global application = ID in IEEE EUI64 address space that uniquely = identifies

  2. the entity able to = process the JoinReq frame.

     
So, we better not treat it as application identifier, = but as identifier of the entity that can authenticate the Join-request = frames.

For = example, instead of:

AppEUI= IEEE EUI64 naming the application

We better say:

AppEUI IEEE = EUI64 naming the entity that processes Join-request




Thanks = Stephen.

Alper
______________________________________________= _
lp-wan mailing list
lp-wan@ietf.org
https://www.ietf.org/mailman/listinfo/lp-wan


= --Apple-Mail=_F81A6237-5EBE-46B5-BA38-65C0E01EDD3F-- From nobody Wed Jun 28 02:50:06 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5312EB9A for ; Wed, 28 Jun 2017 02:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 3BnthB7eLQFK for ; Wed, 28 Jun 2017 02:50:02 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B3212942F for ; Wed, 28 Jun 2017 02:50:02 -0700 (PDT) Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 953D141C088; Wed, 28 Jun 2017 11:50:00 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id mISDJwF9jpAw; Wed, 28 Jun 2017 11:49:58 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.157] (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: arun@acklio.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 5273441C0C3; Wed, 28 Jun 2017 11:49:57 +0200 (CEST) To: weigengyu , Carles Gomez Montenegro Cc: lp-wan@ietf.org, "Pascal Thubert (pthubert)" References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> <23622a341606ebed36588747e92607b2.squirrel@webmail.entel.upc.edu> <63E493F830B247189870EB052E737878@WeiGengyuPC> From: Arun Message-ID: Date: Wed, 28 Jun 2017 11:49:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <63E493F830B247189870EB052E737878@WeiGengyuPC> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xXRwSShj23ExDcKfKIoRCaQt7u0BcQS3M" Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 09:50:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xXRwSShj23ExDcKfKIoRCaQt7u0BcQS3M Content-Type: multipart/mixed; boundary="pN2wdBq0WAnXNj2bxxfcoROIJTMLxlsio"; protected-headers="v1" From: Arun To: weigengyu , Carles Gomez Montenegro Cc: lp-wan@ietf.org, "Pascal Thubert (pthubert)" Message-ID: Subject: Re: [lp-wan] Fw: re-order header field request References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> <23622a341606ebed36588747e92607b2.squirrel@webmail.entel.upc.edu> <63E493F830B247189870EB052E737878@WeiGengyuPC> In-Reply-To: <63E493F830B247189870EB052E737878@WeiGengyuPC> --pN2wdBq0WAnXNj2bxxfcoROIJTMLxlsio Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Gengyu, I foresee fragmentation to be used mostly in the following scenarios; - firmware/software upgrade - configuration/device management - anything else ? which might require big packet sizes. these are the scenarios that are occasional and they are'nt going to happen quite often compared to the actual data transmission. IIUYC, we will be consuming two additional bits for transmissions that are more frequent thus negating the idea of suppressing ruleId in due course of time. Right ? regards, Arun On 28/06/2017 03:49, weigengyu wrote: > > Hi Carles, > >> In the context of the SCHC specification, an L2 LPWAN frame may carry = an >> unfragmented IPv6 datagram with a compressed header (see Fig. 4). > > This doc is just a draft. > The format in Fig.4 can be re-organized to get the suppression optimize= d. > >> The Rule ID is the first field of the compressed IPv6 datagram. > Defining the first two bits are defined as an indications, these > problems ara solved. > > If it is 00, the fragment is the first and contains a Rule ID. > If the Rule ID says this is an unfragment datagram, let it go; > If the Rule ID says this is an fragmented one, you then get the > Dtag. > If it is not 00, you need to get the Dtag for the fragment, > and get the Rule ID by the Dtag. > >> When a compressed IPv6 datagram needs to be fragmented, then some >> Rule ID >> space (of size R bits) is 'stolen' and used for fragmentation >> functionality. So a requirement here is that whatever is defined for >> fragmentation needs to be consistent with the format used for header >> compression. Some special Rule ID (or set of Rule IDs in terms of R-bi= t >> patterns) needs to be used to signal that a data unit being carried is= a >> fragment. > > It has been clarified that only one Rule ID is required for an IPv6 > packets if it is framennted. > Or fragments belonged to one IPv6 packet just needs one Rule ID. > The Rule ID can be carried in the frist fragment to the receiver. > Only one is enough for conveying this information. > >> Note that we cannot risk communication failure due to e.g. loss of a >> first >> fragment (which in your proposal carries a Rule ID) followed by other >> fragments (which in your proposal do not carry a Rule ID) that are >> actually received. In such case, a receiver may process the received >> data >> units as e.g. unfragmented (compressed) IPv6 datagrams. > > Could you explain how the receiver precesses fragments without getting > the first fragment of an fragmented IPv6 packet? > No, it cannot by the current draft either. > Can you explain how the the current draft avoids the risk of > communication failure due to e.g. loss of a first fragment? > It is not available to have each fragment processed independently by > the current draft. > >> In such case, a receiver may process the received data units as e.g. >> unfragmented (compressed) IPv6 datagrams. > What is an unfragmented (compressed) IPv6 datagram? > If it is an unfragmented, it is the first, it contain the Rule ID. Do > you suppose it lost? > > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carles Gomez Monte= negro > Sent: Tuesday, June 27, 2017 10:21 PM > To: weigengyu > Cc: lp-wan@ietf.org ; arun@ackl.io ; Pascal Thubert (pthubert) > Subject: Re: [lp-wan] Fw: re-order header field request > > > Hi Gengyu, > > Thanks for your proposal, I see you are trying to reduce header overhea= d. > However, I'm afraid there are still issues with it. > > In the context of the SCHC specification, an L2 LPWAN frame may carry a= n > unfragmented IPv6 datagram with a compressed header (see Fig. 4). The > Rule > ID is the first field of the compressed IPv6 datagram. > > When a compressed IPv6 datagram needs to be fragmented, then some Rule = ID > space (of size R bits) is 'stolen' and used for fragmentation > functionality. So a requirement here is that whatever is defined for > fragmentation needs to be consistent with the format used for header > compression. Some special Rule ID (or set of Rule IDs in terms of R-bit= > patterns) needs to be used to signal that a data unit being carried is = a > fragment. > > Note that we cannot risk communication failure due to e.g. loss of a > first > fragment (which in your proposal carries a Rule ID) followed by other > fragments (which in your proposal do not carry a Rule ID) that are > actually received. In such case, a receiver may process the received da= ta > units as e.g. unfragmented (compressed) IPv6 datagrams. > > Cheers, > > Carles > > > >> Hi Pascal, >> >>> We need the Rule to say fragment on each fragment, >> All framents of a IPv6 packet obey one rule, the Rule ID is included i= n >> the >> first fragment is enough for conveying this information. >> >>> and then the dtag. >> All framents of the packet contain the same Dtag as defined. >> >>> Starting the next fragment with the dtag would confuse the parser whi= ch >>> would interpret the dtag as another rule. >> Put the Dtag at the front. >> Defining the first two bits of Dtag as an indication of the first >> fragment, >> fragments of the minddle and the last fragment. >> >> 00 the first fragment >> 10 fragments of the minddle >> 11 the last fragment >> >> If the first two bits are '00', the Rule ID is followed. >> If the first two bits are not '00', the fragment does not contain the >> Rule >> ID. >> If the first two bits are 11, it is the last fragment. >> >> I believe that it is worth to have this two bit to suppress the space = of >> Rule ID in the successive fragments. >> >> Regards, >> >> Gengyu WEI >> Network Technology Center >> School of Computer >> Beijing University of Posts and Telecommunications > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > > --pN2wdBq0WAnXNj2bxxfcoROIJTMLxlsio-- --xXRwSShj23ExDcKfKIoRCaQt7u0BcQS3M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZU3vBAAoJENe8HNMjzJQR0tMQAJXXW2Cr56igJfWoJhoOH4BK TzzbE+Esw6yOnQc4wKcC84xAKsXLRFjUONPQszC7BCaiEEU+CiBGiNQ6vFtCCn5L lhZmNU9CuaY+TTNbseIXEA0ljhKWudzoj2ABPJztVJMSlzLx5tQ+xRWkGGRnELEF liGwBdvyO+wWJhIDQt6NpFz6VRnWCgMZEB3nuWCVoEalLdUP7ZZWbc4jam1WFcRl tNvMM1wa5BsM6NCHpDuCOokA8zPPP/T8SvdsrRrUh9InZyzbbTzziadCyDWD4s32 K0FRYM8uNVeEh2QxhmAkXFOBx8TZ59SK2Ah1nrw+Wl3+0d0sholn+YwkDYYNhmpw Sz26DOlmsFrDitRU+mOaXjf2BPqYHDOX5eOPmCAl/2vFxWzjc4G3SObjW8zUPuvR uXNyHub6lFN579jevYLtjh+suu7iZFF6rvlOWu/FySxxGS4CeK/VsjQwSbPZ1lDT 6RKpYOzkpN6zmElSAx2/QgbV0FDsegDcx7daABo1Xf7FXYkEQt4yXIRTv/DpXICo TGYdBNXAUSKPWWPEqPbpm4fiBet8Fd7MxYN9BGn5bJbf+XLuXtEGSITI+EzgEKMk ltJfa7Z7ezZ0++oSRAmYZBrfzgGGDNE9D+iblAE739+QUyds34hrotJWQlUvC41V fYaRCOUVkGi/L/oQWCRZ =SxpG -----END PGP SIGNATURE----- --xXRwSShj23ExDcKfKIoRCaQt7u0BcQS3M-- From nobody Wed Jun 28 08:31:12 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45738129B4B for ; Wed, 28 Jun 2017 08:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 57jYjjpMcJms for ; Wed, 28 Jun 2017 08:31:07 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 4F155129B4C for ; Wed, 28 Jun 2017 08:31:07 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v5SFUwdi044762; Wed, 28 Jun 2017 17:30:59 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 0D8661D53C1; Wed, 28 Jun 2017 17:30:58 +0200 (CEST) Received: from 79.158.9.53 by webmail.entel.upc.edu with HTTP; Wed, 28 Jun 2017 17:30:26 +0200 Message-ID: <02bc809a35d6057df366de2cf9d6d5ce.squirrel@webmail.entel.upc.edu> In-Reply-To: <63E493F830B247189870EB052E737878@WeiGengyuPC> References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> <23622a341606ebed36588747e92607b2.squirrel@webmail.entel.upc.edu> <63E493F830B247189870EB052E737878@WeiGengyuPC> Date: Wed, 28 Jun 2017 17:30:26 +0200 From: "Carles Gomez Montenegro" To: "weigengyu" Cc: lp-wan@ietf.org, arun@ackl.io, "Pascal Thubert \(pthubert\)" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: Delayed for 25:08:32 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 28 Jun 2017 17:31:00 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 15:31:10 -0000 Hi Gengyu, Please find inline responses to your questions below: > Hi Carles, > >> In the context of the SCHC specification, an L2 LPWAN frame may carry an >> unfragmented IPv6 datagram with a compressed header (see Fig. 4). > > This doc is just a draft. > The format in Fig.4 can be re-organized to get the suppression optimized. > >> The Rule ID is the first field of the compressed IPv6 datagram. > Defining the first two bits are defined as an indications, these problems > ara solved. > > If it is 00, the fragment is the first and contains a Rule ID. > If the Rule ID says this is an unfragment datagram, let it go; > If the Rule ID says this is an fragmented one, you then get the > Dtag. > If it is not 00, you need to get the Dtag for the fragment, > and get the Rule ID by the Dtag. > >> When a compressed IPv6 datagram needs to be fragmented, then some Rule >> ID >> space (of size R bits) is 'stolen' and used for fragmentation >> functionality. So a requirement here is that whatever is defined for >> fragmentation needs to be consistent with the format used for header >> compression. Some special Rule ID (or set of Rule IDs in terms of R-bit >> patterns) needs to be used to signal that a data unit being carried is a >> fragment. > > It has been clarified that only one Rule ID is required for an IPv6 > packets > if it is framennted. > Or fragments belonged to one IPv6 packet just needs one Rule ID. > The Rule ID can be carried in the frist fragment to the receiver. > Only one is enough for conveying this information. > >> Note that we cannot risk communication failure due to e.g. loss of a >> first >> fragment (which in your proposal carries a Rule ID) followed by other >> fragments (which in your proposal do not carry a Rule ID) that are >> actually received. In such case, a receiver may process the received >> data >> units as e.g. unfragmented (compressed) IPv6 datagrams. > > Could you explain how the receiver precesses fragments without getting the > first fragment of an fragmented IPv6 packet? > No, it cannot by the current draft either. The point is that with the current draft, if the first fragment is lost, subsequent fragments cannot be confused with unfragmented IPv6 datagrams, since all fragments have a Rule ID field that is set to a value that indicates that the data unit being carried is a fragment. > Can you explain how the the current draft avoids the risk of communication > failure due to e.g. loss of a first fragment? > It is not available to have each fragment processed independently by the > current draft. Please see the response above. >> In such case, a receiver may process the received data units as e.g. >> unfragmented (compressed) IPv6 datagrams. > What is an unfragmented (compressed) IPv6 datagram? > If it is an unfragmented, it is the first, it contain the Rule ID. Do you > suppose it lost? An unfragmented (compressed) IPv6 datagram is an IPv6 datagram which, after SCHC header compression, has a size that does not exceed the maximum L2 data unit payload size currently allowed. Therefore, it does not need fragmentation. Greetings, Carles > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications From nobody Wed Jun 28 08:59:27 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBFC129B5C for ; Wed, 28 Jun 2017 08:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74e87xaME4ZA for ; Wed, 28 Jun 2017 08:59:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AB6129B74 for ; Wed, 28 Jun 2017 08:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3139; q=dns/txt; s=iport; t=1498665559; x=1499875159; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=O69/Cb3fIp9iCbebFx4JKgzuHNfkVK8irzgugZV6H0g=; b=bV0QTL+thVYbn00T3HV+o/BZhyi13qxgclvMNMQ3JZ0wWD7wQvdbGY5a mafZ7+K7Thr78+Q3jtTYhq4FMuRHHA4Ad/BngMRGHtBGWLtI8cMKAuEsq KUHd5nVtM2nA7aQ1RwpKJml2iwYQa4OeDwQY6Nspfi3Te84uAfB3AIM2F o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAQCF0VNZ/4QNJK1CGhsBAQEDAQEBC?= =?us-ascii?q?QEBAYNYY4EOjgWRaJBPhSuCESyFcAKDCT8YAQIBAQEBAQEBax0LhRkGDH0CAQw?= =?us-ascii?q?QKwcyFAcKAgQTiUxkEDKzMYtXAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDJ4NMg?= =?us-ascii?q?gyCeYUKFoMNgjEFnnQChzeMN4IKhUqKQpUnAR84gQp0FUkSAYI2hEp2AQGJOAE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.40,276,1496102400"; d="scan'208,217";a="261358455" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2017 15:59:18 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v5SFxI7W003681 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Jun 2017 15:59:18 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 28 Jun 2017 10:59:17 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 28 Jun 2017 10:59:17 -0500 From: "Pascal Thubert (pthubert)" To: "lp-wan@ietf.org" Thread-Topic: Cutoff date for requesting remote presentations support at IETF99 Thread-Index: AQHS8B9KEqa33SkUIkO1J6gI1HIzuaI6br/e Date: Wed, 28 Jun 2017 15:59:17 +0000 Message-ID: <2335C966-BE8E-49CD-9FE6-98FAF9C57DE1@cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_2335C966BE8E49CD9FE698FAF9C57DE1ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Fwd: Cutoff date for requesting remote presentations support at IETF99 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 15:59:23 -0000 --_000_2335C966BE8E49CD9FE698FAF9C57DE1ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all: If you plan to be presenting remotely please let us know ! Regards, Pascal D?but du message transf?r? : Exp?diteur: Meetecho IETF support > Date: 28 juin 2017 ? 17:00:08 UTC+2 Destinataire: wgchairs@ietf.org Objet: Cutoff date for requesting remote presentations support at IETF99 Dear chairs, if you plan to have remote _presentations_ in Prague, you're kindly request= ed to fill out the following form: https://ietf99.conf.meetecho.com/index.php/Remote_presentations *The cutoff date for remote presentations support requests is July 14.* You can also check scheduled remote presentations here: https://ietf99.conf.meetecho.com/list.php Thanks, the Meetecho team --_000_2335C966BE8E49CD9FE698FAF9C57DE1ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all:

If you plan to be presenting remotely please let us know !

Regards,

Pascal

Début du message transféré :

Expéditeur: Meetecho IETF support <ietf@meetecho.com>
Date: 28 juin 2017 à 17:00:08 UTC+2
Destinataire: wgchairs@ietf.org=
Objet: Cutoff date for requesting remote presentations support at= IETF99

Dear chairs,

if you plan to have remote _presentations_ in Prague, you're kindly r= equested to fill out the following form:

https://ietf99.conf.meetecho.com/index.php/Remote_presentations<= /span>

*The cutoff date for remote presentations support requests is July 14= .*

You can also check scheduled remote presentations here:

https://ietf99.= conf.meetecho.com/list.php

Thanks,
the Meetecho team

--_000_2335C966BE8E49CD9FE698FAF9C57DE1ciscocom_-- From nobody Wed Jun 28 13:41:27 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306101270AC for ; Wed, 28 Jun 2017 13:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 izkQ5VJoknCZ for ; Wed, 28 Jun 2017 13:41:24 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A811612EC58 for ; Wed, 28 Jun 2017 13:41:23 -0700 (PDT) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id CC8EAC5A7A for ; Wed, 28 Jun 2017 22:41:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Mj3swXdhyj5A for ; Wed, 28 Jun 2017 22:41:20 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.11] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 29478C5A53 for ; Wed, 28 Jun 2017 22:41:19 +0200 (CEST) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <0CDB3F3C-8825-4206-A029-344203CEBDB5@ackl.io> Date: Wed, 28 Jun 2017 22:41:19 +0200 To: lp-wan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Agenda for LPWAN interim meeting next Wednesday, July 5th, 16h-17h CEST (7-8am US Pacific) X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 20:41:26 -0000 Dear all, Next Wednesday (July 5th) we will have our final interim before the IETF = in Prague. As usual, you=E2=80=99ll find the agenda in the Datatracker ( = https://datatracker.ietf.org/doc/agenda-interim-2017-lpwan-06-lpwan-01/ = ). We will discuss the updates on the WGLC on the LPWAN Overview document. = We will also spend some time reviewing the latest changes in the = fragmentation and compression part, which should very soon be ready for = WGLC.=20 See you next Wednesday! Best, Pascal and Alexander PS. Don=E2=80=99t forget to review the IP/UDP SCHC and the CoAP SCHC = documents and provide feedback on the ML. From nobody Thu Jun 29 00:48:52 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBC8126DD9 for ; Thu, 29 Jun 2017 00:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 nsGEK9SFf3BO for ; Thu, 29 Jun 2017 00:48:47 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.2.193]) by ietfa.amsl.com (Postfix) with ESMTP id 9299012EA52 for ; Thu, 29 Jun 2017 00:48:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 66E5B105667 for ; Thu, 29 Jun 2017 09:48:45 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id MDE-nQTXIpuj for ; Thu, 29 Jun 2017 09:48:44 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 5B8F510566B for ; Thu, 29 Jun 2017 09:48:44 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy120.enst.fr 5B8F510566B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1498722524; bh=LMYWPOlzLiNcBRA3jkXnabO3C1jDeDfrzRmX04jNvMU=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=MTSBu0KGg7psSPpGl9ZOiBTMhi+P6tD5HCaoa9UlZdTi1/OmxD6MGr4TujmGqd6Tv PAosiPkTh/vPI8KezDt4elAY2YITNENqFM/mn42GH4z/budOzTs/tg+Amr65YwSxCP ZL3wDibDu98jIkKYwmfDI3L3k0Az4ut+fDB1sMHY= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id T8Dv6gQZP1Ec for ; Thu, 29 Jun 2017 09:48:44 +0200 (CEST) Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) by zproxy120.enst.fr (Postfix) with ESMTPSA id E2CC7105659 for ; Thu, 29 Jun 2017 09:48:43 +0200 (CEST) Received: by mail-vk0-f42.google.com with SMTP id y70so45203627vky.3 for ; Thu, 29 Jun 2017 00:48:43 -0700 (PDT) X-Gm-Message-State: AKS2vOwUG1EELxZ7sT+jd1Arr8pNpcSJtO0TOXU3FWZWlt4/CXEUgxq3 EkOGa3lgPWR1hx3aQYT5DJGwh/R63Q== X-Received: by 10.31.180.80 with SMTP id d77mr6729970vkf.110.1498722522514; Thu, 29 Jun 2017 00:48:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.61.13 with HTTP; Thu, 29 Jun 2017 00:48:01 -0700 (PDT) In-Reply-To: <63E493F830B247189870EB052E737878@WeiGengyuPC> References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <912c2aab-a69f-355a-f7c5-730bac5eaafa@ackl.io> <341C683FEB8548B4924400501958BEAF@WeiGengyuPC> <42e03b91c6a5e748a0c9d7d81966eef0.squirrel@webmail.entel.upc.edu> <3EE9A684758B44CE9FF891EFDBBF45BA@WeiGengyuPC> <0b52c5cefcbf45b9b3de78d35ae516ad@XCH-RCD-001.cisco.com> <23622a341606ebed36588747e92607b2.squirrel@webmail.entel.upc.edu> <63E493F830B247189870EB052E737878@WeiGengyuPC> From: Laurent Toutain Date: Thu, 29 Jun 2017 09:48:01 +0200 X-Gmail-Original-Message-ID: Message-ID: To: weigengyu Cc: Carles Gomez Montenegro , lp-wan , Arun , "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary="001a114381109253b00553148746" Archived-At: Subject: Re: [lp-wan] Fw: re-order header field request X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 07:48:51 -0000 --001a114381109253b00553148746 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gengyu, The format is the following Rule ID [Data Tag] CFN CFN plays the role you assign to your 2 bits any value between [0, 2^N-2] means more fragment and 2^N-1 no more fragment. It is more optimal than using a specific bit in all frame. Data Tag is not mandatory since in LPWAN you may have only one packet over the air. That's a big difference with IEEE 802.15.4 or mesh networks where a node can transmit several fragments belonging to different packet. In LPWAN with duty cycles, this is not so common. Rule ID is a specific value that tells the receiver this is a fragment. You are right, the packet that have been fragmented contains at the first position different rule ID which tells which rule must be used to decompress the header. The following picture illustrate this. +---+------------------------------------------------------------+ |Rid| compressed header | payload | +---+-----+---------+---------+---------+---------+---------+----+ | | | | | | | | +---+---------+ +---+---------+ +---+---------+ +---+----+ |R' | | |R' | | |R' | | |R' | | +---+---------+ +---+---------+ +---+---------+ +---+----+ | | | | | | +---+---------+ +---+---------+ +---+---------+ |R' | | |R' | | |R' | | +---+---------+ +---+---------+ +---+---------+ Laurent On Wed, Jun 28, 2017 at 3:49 AM, weigengyu wrote: > > Hi Carles, > > In the context of the SCHC specification, an L2 LPWAN frame may carry an >> unfragmented IPv6 datagram with a compressed header (see Fig. 4). >> > > This doc is just a draft. > The format in Fig.4 can be re-organized to get the suppression optimized. > > The Rule ID is the first field of the compressed IPv6 datagram. >> > Defining the first two bits are defined as an indications, these problems > ara solved. > > If it is 00, the fragment is the first and contains a Rule ID. > If the Rule ID says this is an unfragment datagram, let it go; > If the Rule ID says this is an fragmented one, you then get the > Dtag. > If it is not 00, you need to get the Dtag for the fragment, > and get the Rule ID by the Dtag. > > When a compressed IPv6 datagram needs to be fragmented, then some Rule ID >> space (of size R bits) is 'stolen' and used for fragmentation >> functionality. So a requirement here is that whatever is defined for >> fragmentation needs to be consistent with the format used for header >> compression. Some special Rule ID (or set of Rule IDs in terms of R-bit >> patterns) needs to be used to signal that a data unit being carried is a >> fragment. >> > > It has been clarified that only one Rule ID is required for an IPv6 > packets if it is framennted. > Or fragments belonged to one IPv6 packet just needs one Rule ID. > The Rule ID can be carried in the frist fragment to the receiver. > Only one is enough for conveying this information. > > Note that we cannot risk communication failure due to e.g. loss of a firs= t >> fragment (which in your proposal carries a Rule ID) followed by other >> fragments (which in your proposal do not carry a Rule ID) that are >> actually received. In such case, a receiver may process the received dat= a >> units as e.g. unfragmented (compressed) IPv6 datagrams. >> > > Could you explain how the receiver precesses fragments without getting th= e > first fragment of an fragmented IPv6 packet? > No, it cannot by the current draft either. > Can you explain how the the current draft avoids the risk of communicatio= n > failure due to e.g. loss of a first fragment? > It is not available to have each fragment processed independently by the > current draft. > > In such case, a receiver may process the received data units as e.g. >> unfragmented (compressed) IPv6 datagrams. >> > What is an unfragmented (compressed) IPv6 datagram? > If it is an unfragmented, it is the first, it contain the Rule ID. Do yo= u > suppose it lost? > > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carles Gomez Montene= gro > Sent: Tuesday, June 27, 2017 10:21 PM > To: weigengyu > Cc: lp-wan@ietf.org ; arun@ackl.io ; Pascal Thubert (pthubert) > Subject: Re: [lp-wan] Fw: re-order header field request > > > Hi Gengyu, > > Thanks for your proposal, I see you are trying to reduce header overhead. > However, I'm afraid there are still issues with it. > > In the context of the SCHC specification, an L2 LPWAN frame may carry an > unfragmented IPv6 datagram with a compressed header (see Fig. 4). The Rul= e > ID is the first field of the compressed IPv6 datagram. > > When a compressed IPv6 datagram needs to be fragmented, then some Rule ID > space (of size R bits) is 'stolen' and used for fragmentation > functionality. So a requirement here is that whatever is defined for > fragmentation needs to be consistent with the format used for header > compression. Some special Rule ID (or set of Rule IDs in terms of R-bit > patterns) needs to be used to signal that a data unit being carried is a > fragment. > > Note that we cannot risk communication failure due to e.g. loss of a firs= t > fragment (which in your proposal carries a Rule ID) followed by other > fragments (which in your proposal do not carry a Rule ID) that are > actually received. In such case, a receiver may process the received data > units as e.g. unfragmented (compressed) IPv6 datagrams. > > Cheers, > > Carles > > > > Hi Pascal, >> >> We need the Rule to say fragment on each fragment, >>> >> All framents of a IPv6 packet obey one rule, the Rule ID is included in >> the >> first fragment is enough for conveying this information. >> >> and then the dtag. >>> >> All framents of the packet contain the same Dtag as defined. >> >> Starting the next fragment with the dtag would confuse the parser which >>> would interpret the dtag as another rule. >>> >> Put the Dtag at the front. >> Defining the first two bits of Dtag as an indication of the first >> fragment, >> fragments of the minddle and the last fragment. >> >> 00 the first fragment >> 10 fragments of the minddle >> 11 the last fragment >> >> If the first two bits are '00', the Rule ID is followed. >> If the first two bits are not '00', the fragment does not contain the Ru= le >> ID. >> If the first two bits are 11, it is the last fragment. >> >> I believe that it is worth to have this two bit to suppress the space of >> Rule ID in the successive fragments. >> >> Regards, >> >> Gengyu WEI >> Network Technology Center >> School of Computer >> Beijing University of Posts and Telecommunications >> > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > --001a114381109253b00553148746 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gengyu,

The = format is the following

=C2=A0Rule ID=C2=A0 [Data Tag] CFN
=
CFN plays the role you assign to your 2 bits any value between [0= , 2^N-2] means more fragment and 2^N-1 no more fragment. It is more optimal= than using a specific bit in all frame.

Data Tag is not mand= atory since in LPWAN you may have only one packet over the air. That's = a big difference with IEEE 802.15.4 or mesh networks where a node can trans= mit several fragments belonging to different packet. In LPWAN with duty cyc= les, this is not so common.

Rule ID is a specific value that = tells the receiver this is a fragment. You are right, the packet that have = been fragmented contains at the first position different rule ID which tell= s which rule must be used to decompress the header. The following picture i= llustrate this.


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

=C2=A0=C2=A0=C2=A0 |Rid|=C2=A0 compressed header=C2=A0 | =C2=A0 payload = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 |

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

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

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

|R'= ; |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 =C2=A0=C2=A0 |R' |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0 |R' |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |R' |=C2=A0=C2=A0=C2=A0 |

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

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

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

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |R' |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 =C2=A0= =C2=A0 |R' |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |R' |=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2= =A0=C2=A0

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



Laurent

On Wed, Jun 28, 2017 at 3:49 AM, = weigengyu <weigengyu@vip.sina.com> wrote:

Hi Carles,

In the context of the SCHC specification, an L2 LPWAN frame may carry an unfragmented IPv6 datagram with a compressed header (see Fig. 4).

 This doc is just a draft.
The format in Fig.4 can be re-organized to get the suppression optimized.

The Rule ID is the first field of the compressed IPv6 datagram.
Defining the first two bits are defined as an indications, these problems a= ra solved.

If it is 00, the fragment is the first and contains a Rule ID.
=C2=A0 =C2=A0 =C2=A0 =C2=A0If the Rule ID says this is an unfragment datagr= am, let it go;
=C2=A0 =C2=A0 =C2=A0 =C2=A0If the Rule ID says this is an fragmented one, y= ou then get the Dtag.
If it is not 00, you need to get the Dtag for the fragment,
=C2=A0 =C2=A0 =C2=A0 =C2=A0and get the Rule ID by the Dtag.

When a compressed IPv6 datagram needs to be fragmented, then some Rule ID space (of size R bits) is 'stolen' and used for fragmentation
functionality. So a requirement here is that whatever is defined for
fragmentation needs to be consistent with the format used for header
compression. Some special Rule ID (or set of Rule IDs in terms of R-bit
patterns) needs to be used to signal that a data unit being carried is a fragment.

 It has been clarified that only one Rule ID is required for an IPv6 packets= if it is framennted.
Or fragments belonged to one IPv6 packet just needs one Rule ID.
The Rule ID can be carried in the frist fragment to the receiver.
Only one is enough for conveying this information.

Note that we cannot risk communication failure due to e.g. loss of a first<= br> fragment (which in your proposal carries a Rule ID) followed by other
fragments (which in your proposal do not carry a Rule ID) that are
actually received. In such case, a receiver may process the received data units as e.g. unfragmented (compressed) IPv6 datagrams.

 Could you explain how the receiver precesses fragments without getting the = first fragment of an fragmented IPv6 packet?
No, it cannot by the current draft either.
Can you explain how the the current draft avoids the risk of communication = failure due to e.g. loss of a first fragment?
It is not available to have each fragment processed independently by the cu= rrent draft.

In such case, a receiver may process the received data units as e.g. unfrag= mented (compressed) IPv6 datagrams.
 What is an unfragmented (compressed) IPv6 datagram?
If it is an unfragmented, it is the first, it contain the Rule ID.=C2=A0 Do= you suppose it lost?


Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
 -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carles Gomez Montenegr= o
 Sent: Tuesday, June 27, 2017 10:21 PM
To: weigengyu
Cc: lp-wan@ietf.org ; arun@ackl.io ; Pa= scal Thubert (pthubert)
Subject: Re: [lp-wan] Fw: re-order header field request


Hi Gengyu,

Thanks for your proposal, I see you are trying to reduce header overhead. However, I'm afraid there are still issues with it.

In the context of the SCHC specification, an L2 LPWAN frame may carry an unfragmented IPv6 datagram with a compressed header (see Fig. 4). The Rule<= br> ID is the first field of the compressed IPv6 datagram.

When a compressed IPv6 datagram needs to be fragmented, then some Rule ID space (of size R bits) is 'stolen' and used for fragmentation
functionality. So a requirement here is that whatever is defined for
fragmentation needs to be consistent with the format used for header
compression. Some special Rule ID (or set of Rule IDs in terms of R-bit
patterns) needs to be used to signal that a data unit being carried is a fragment.

Note that we cannot risk communication failure due to e.g. loss of a first<= br> fragment (which in your proposal carries a Rule ID) followed by other
fragments (which in your proposal do not carry a Rule ID) that are
actually received. In such case, a receiver may process the received data units as e.g. unfragmented (compressed) IPv6 datagrams.

Cheers,

Carles



Hi Pascal,

We need the Rule to say fragment on each fragment,
All framents of a IPv6 packet obey one rule, the Rule ID is included in
the
first fragment is enough for conveying this information.

and then the dtag.
All framents of the packet contain the same Dtag as defined.

Starting the next fragment with the dtag would confuse the parser which
would interpret the dtag as another rule.
Put the Dtag at the front.
Defining the first two bits of Dtag as an indication of the first
fragment,
fragments of the minddle and=C2=A0 the last fragment.

00 the first fragment
10 fragments of the minddle
11 the last fragment

If the first two bits are '00', the Rule ID is followed.
If the first two bits are not '00', the fragment does not contain t= he Rule
ID.
If the first two bits are 11, it is the last fragment.

I believe that it is worth to have this two bit to suppress the space of Rule ID in the successive fragments.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan

_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan

--001a114381109253b00553148746-- From nobody Thu Jun 29 04:27:36 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724C112EB13 for ; Thu, 29 Jun 2017 04:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.274 X-Spam-Level: X-Spam-Status: No, score=-12.274 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, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os86rYtSEgjl for ; Thu, 29 Jun 2017 04:27:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8531E126C0F for ; Thu, 29 Jun 2017 04:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35348; q=dns/txt; s=iport; t=1498735653; x=1499945253; h=from:to:cc:subject:date:message-id:mime-version; bh=BMAqvMab16yMNuZTawCdwCbAI2cuZPmLVEpX0CXsH6E=; b=jZ3r7ypib9PHMo5XTLdRneSXs3enf849+dy5j/6Zg9CwqZ5pW0hchW5k iy8z/BbMuSZjN0CEZeKI40yVXjdLqbU81l0uAj3LT64g5dU0v+yi/0yK3 oTrlsCIkMTI5pqwk8xUw6ZgE8BbNhjwxp4NNdNKFCkoxm4TC3zAGCT/Ch Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAADk4lRZ/4QNJK1DFwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCb2pjgQ4HjX6nYYEpBWMuhDWBORyCdD8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhR0lCjkTEgE0BAgBAwYCBDAkAgEEDgUIiUNkEDKyE4Img1OHdgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2DJ4NMgWGEYAGBQyaBNRsLCh0JB4IIFieCRxoFnnYCgV+?= =?us-ascii?q?FW4cGhSmCExk9gm+CBYpDih2LDAEfOIEKdBWDE4JHHIEXT3YBiDOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,280,1496102400"; d="scan'208,217";a="261999420" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2017 11:27:32 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v5TBRWFp020492 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Jun 2017 11:27:32 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 29 Jun 2017 06:27:31 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Thu, 29 Jun 2017 06:27:31 -0500 From: "Pascal Thubert (pthubert)" To: "lp-wan@ietf.org" CC: "lp-wan-chairs@ietf.org" Thread-Topic: Webex info for the LPWAN Interim, July 5th 2017 Thread-Index: AdLwymjirInR0VClTOGDx5IpklnU3g== Date: Thu, 29 Jun 2017 11:27:27 +0000 Deferred-Delivery: Thu, 29 Jun 2017 11:26:29 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_b22094939a33467d89a77b212f82cff0XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Webex info for the LPWAN Interim, July 5th 2017 X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 11:27:35 -0000 --_000_b22094939a33467d89a77b212f82cff0XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTFBXQU5lcnMsDQoNCg0KDQpUaGUgY2hhaXJzIGludml0ZXMgeW91IHRvIGpvaW4gb3Vy IG5leHQgaW50ZXJpbSBtZWV0aW5nDQoNCi4NCg0KDQoNCg0KDQpMUFdBTiBJbnRlcmltDQoNCldl ZG5lc2RheSA1IEp1bHkgMjAxNw0KDQoxNjowMCAgfCAgRXVyb3BlIFN1bW1lciBUaW1lIChQYXJp cywgR01UKzAyOjAwKSAgfCAgMSBocg0KDQoNCg0KDQoNCkpvaW4gV2ViRXggbWVldGluZyA8aHR0 cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBocD9NVElEPW0yMDE0Y2EyZGQxODFi MWE1YjZlMjdmOTQxODBiZDBkZT4NCg0KDQpNZWV0aW5nIG51bWJlcjoNCg0KMjA3IDUxNCAyMjcN Cg0KTWVldGluZyBwYXNzd29yZDoNCg0KVG1DRUN0U0sgKDg2MjMyODc1IGZyb20gcGhvbmVzKQ0K DQoNCkpvaW4gZnJvbSBhIHZpZGVvIGNvbmZlcmVuY2luZyBzeXN0ZW0gb3IgYXBwbGljYXRpb24N Cg0KRGlhbCAyMDc1MTQyMjdAY2lzY28ud2ViZXguY29tPCUyMHNpcDoyMDc1MTQyMjdAY2lzY28u d2ViZXguY29tPg0KDQpGcm9tIHRoZSBDaXNjbyBpbnRlcm5hbCBuZXR3b3JrLCBkaWFsICoyNjcq IGFuZCB0aGUgOS1kaWdpdCBtZWV0aW5nIG51bWJlci4gSWYgeW91IGFyZSB0aGUgaG9zdCwgZW50 ZXIgeW91ciBQSU4gd2hlbiBwcm9tcHRlZC4NCg0KDQoNCg0KDQpKb2luIGJ5IHBob25lDQoNCisx LTg2Ni00MzItOTkwMyBDYWxsLWluIHRvbGwtZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkNCg0KKzEt NDA4LTUyNS02ODAwIENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCg0KQWNjZXNzIGNv ZGU6IDIwNyA1MTQgMjI3DQoNCkdsb2JhbCBjYWxsLWluIG51bWJlcnM8aHR0cHM6Ly9jaXNjby53 ZWJleC5jb20vY2lzY29zYWxlcy9nbG9iYWxjYWxsaW4ucGhwP3NlcnZpY2VUeXBlPU1DJkVEPTM5 MjE3NzI0NyZ0b2xsRnJlZT0xPiAgfCAgVG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPGh0 dHBzOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZj4NCg0KDQoN Cg0KDQpBZGQgdGhpcyBtZWV0aW5nPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMv ai5waHA/TVRJRD1tNjFmOTYxZDU2YjdlZDQ0OTgyMzQwMTAyZmY0NGFkNmU+IHRvIHlvdXIgY2Fs ZW5kYXIuIChDYW5ub3QgYWRkIGZyb20gbW9iaWxlIGRldmljZXMuKQ0KDQoNCg0KDQoNCkNhbid0 IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydC48aHR0cHM6Ly9jaXNjby53ZWJleC5j b20vY2lzY29zYWxlcy9tYz4NCg0KDQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90 ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0 aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUg ZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwg eW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBu b3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGgg dGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uDQoNCg0KDQoNCg== --_000_b22094939a33467d89a77b212f82cff0XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJB cmlhbCIsc2Fucy1zZXJpZjsNCgljb2xvcjojNjY2NjY2Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzY2NjY2NjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiM2 NjY2NjYiIHZsaW5rPSIjNjY2NjY2Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhlbGxvIExQV0FO ZXJzLDwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSI1JSIg c3R5bGU9IndpZHRoOjUuMSUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjMu NzVwdCAwY20gMGNtIDBjbSI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSIw IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQ7bWFyZ2luLWxlZnQ6My43NXB0Ij4NCjx0Ym9keT4NCjx0 cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+ DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5 bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgY2hhaXJzIGludml0 ZXMgeW91IHRvIGpvaW4gb3VyIG5leHQgaW50ZXJpbSBtZWV0aW5nPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzRENEQ0RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ny41cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNEQ0RDREIj4uIDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv cmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9 IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6 MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9u ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxU YWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIx MDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6 MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+TFBXQU4gSW50ZXJpbTwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzRENEQ0RCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N Cjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2 NjY2Ij5XZWRuZXNkYXkgNSBKdWx5IDIwMTcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZy YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM2NjY2NjYiPjE2OjAwJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwO0V1cm9wZSBT dW1tZXIgVGltZSAoUGFyaXMsIEdNVCYjNDM7MDI6MDApJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNw OzEgaHINCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVu dC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1l bGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDoz OTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVs ZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJv cmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9 IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEFGRjkiPjxhIGhyZWY9Imh0dHBzOi8vY2lz Y28ud2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/TVRJRD1tMjAxNGNhMmRkMTgxYjFhNWI2ZTI3 Zjk0MTgwYmQwZGUiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlv bjpub25lIj5Kb2luIFdlYkV4IG1lZXRpbmc8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj4NCjwvc3Bhbj48L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVs ZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxw YWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTt3aWR0aDphdXRvIWltcG9ydGFu dCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDMuNzVwdCAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+TWVldGluZyBudW1iZXI6DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM2NjY2NjYiPjIwNyA1MTQgMjI3DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMy43NXB0IDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5NZWV0aW5nIHBhc3N3b3JkOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+VG1DRUN0U0sgKDg2MjMyODc1IGZyb20gcGhvbmVzKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFj aW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+ DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOjE1LjBwdDtsaW5lLWhlaWdodDox NS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkpvaW4gZnJvbSBhIHZpZGVvIGNvbmZlcmVuY2luZyBz eXN0ZW0gb3IgYXBwbGljYXRpb248L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkRpYWwgPGEgaHJlZj0iJTIwc2lwOjIw NzUxNDIyN0BjaXNjby53ZWJleC5jb20iPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjIwNzUxNDIyN0BjaXNjby53ZWJleC5jb208L3NwYW4+PC9i PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHls ZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1o c3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5Gcm9t IHRoZSBDaXNjbyBpbnRlcm5hbCBuZXR3b3JrLCBkaWFsICoyNjcqIGFuZCB0aGUgOS1kaWdpdCBt ZWV0aW5nIG51bWJlci4gSWYgeW91IGFyZSB0aGUgaG9zdCwgZW50ZXIgeW91ciBQSU4gd2hlbiBw cm9tcHRlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0 aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi IGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5 bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzow Y20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Sm9pbiBieSBwaG9uZTwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2 NjY2NiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12 ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21z by1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+ JiM0MzsxLTg2Ni00MzItOTkwMzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2 Ij4mbmJzcDtDYWxsLWluIHRvbGwtZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mIzQzOzEtNDA4LTUyNS02ODAw PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwO0NhbGwtaW4gdG9s bCBudW1iZXIgKFVTL0NhbmFkYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4N Cjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNjY2NjY2Ij5BY2Nlc3MgY29kZTombmJzcDsyMDcgNTE0IDIyNzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVu dC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1l bGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2Vi ZXguY29tL2Npc2Nvc2FsZXMvZ2xvYmFsY2FsbGluLnBocD9zZXJ2aWNlVHlwZT1NQyZhbXA7RUQ9 MzkyMTc3MjQ3JmFtcDt0b2xsRnJlZT0xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5HbG9iYWwgY2FsbC1pbg0KIG51bWJl cnM8L3NwYW4+PC9hPiZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3 dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlRvbGwt ZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2 NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5n PSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHls ZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hl aWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1 LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNSIgY2Vs bHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1l bGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxl bWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9u dGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM2NjY2NjYiPjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvai5w aHA/TVRJRD1tNjFmOTYxZDU2YjdlZDQ0OTgyMzQwMTAyZmY0NGFkNmUiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5BZGQgdGhpcyBtZWV0aW5nPC9zcGFu PjwvYT4gdG8geW91ciBjYWxlbmRhci4NCiAoQ2Fubm90IGFkZCBmcm9tIG1vYmlsZSBkZXZpY2Vz Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iNSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1 cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFk ZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50 LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2 NjYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0 aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz8N CjxhIGhyZWY9Imh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvbWMiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5Db250YWN0IHN1cHBvcnQu PC9zcGFuPjwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3 aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo3LjVwdCI+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDo3LjVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDo3LjVwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6 bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0EwQTBBMCI+SU1QT1JUQU5U IE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlv IGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNv cmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9p bmluZw0KIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJl Y29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3Vz cyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_b22094939a33467d89a77b212f82cff0XCHRCD001ciscocom_-- From nobody Fri Jun 30 20:31:06 2017 Return-Path: X-Original-To: lp-wan@ietfa.amsl.com Delivered-To: lp-wan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FBB131515 for ; Fri, 30 Jun 2017 20:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.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 pKRpH4vusfRw for ; Fri, 30 Jun 2017 20:31:01 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 ACDD412EAF5 for ; Fri, 30 Jun 2017 20:31:01 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id s15so9135773ybe.2 for ; Fri, 30 Jun 2017 20:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+gokpHcHi3eozcCiRmaXSJGWHjmelUcDO/ePQHkiBJ0=; b=HJZarLG1JhSh5//UTUsBU607i5ni1QXRTZr5A8ZxF/TmvoSa2H7DbuLu12eGbZbN0Y tRdcXlBvTT223lCt28lHlSUutg5+O9nCMop56jWgoVbFIuAErULGdy0FOATFBvbZOLmD +0LkhFr7WdjAJSn8/AhmN9TpeBEz7hWv1wdq3oNWz7tCg4KMh9fU0t13J+OVJ16sAj/r C94vOneCP7B59C+JpcW6Lg8zYrhT8TuLs98pofaMNlTXz7wJUKvN9mddnDv6XbMASK+7 X/fRjhx7h1kksufxPSQpswCwNGsJH1iVa9B5lPKKP9DrDzoyWPBmiGVnydF8Zu5VgBJO gvzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+gokpHcHi3eozcCiRmaXSJGWHjmelUcDO/ePQHkiBJ0=; b=Mq/FjrIh0FOctsjwwSFj3xMwjXVs5L1Nl1W4ERLC6YJLrk36J4Bo58rRKa+V5qrySN lX/mpEbXIhYBuD9euDcy89OAazTuA2Gocww3N3SginphaOtSn3GVw4bSil1cBjAHns3X 5061QoePqNO+WtQFBjjtI+qMmQ1OS+nMAT3VKEhdSMSkvAaenPeCdrMJ0QPFjpLjskui Y97gQ8aFiM9RF5riUxAyUzWkTQuqEPiEKlDTnf8CU2MD/yTNPqNOu0JdftwtjGkJ/ts0 eaK4g2l1CuvaXDmvTaRxcZjUQ+YJeVvGh6xGLHMZs9i3ym4bfMvuwOLmFp8O8hOjDF8G i/0g== X-Gm-Message-State: AKS2vOzvP9/FzML8Hvi7GB7nxRMHWSPpoM/2z24Y3/uHjhGhIBLsCK4G P/VYAZF9uuDZYWGG3i2A008S1lFnJ3Ci X-Received: by 10.37.175.209 with SMTP id d17mr19947968ybj.9.1498879860304; Fri, 30 Jun 2017 20:31:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.175.19 with HTTP; Fri, 30 Jun 2017 20:30:39 -0700 (PDT) In-Reply-To: <149885518063.4596.11853717187549933541.idtracker@ietfa.amsl.com> References: <149885518063.4596.11853717187549933541.idtracker@ietfa.amsl.com> From: "Prof. Diego Dujovne" Date: Fri, 30 Jun 2017 23:30:39 -0400 Message-ID: To: lp-wan Content-Type: multipart/alternative; boundary="089e08245e7ca283d3055339290b" Archived-At: Subject: [lp-wan] Fwd: New Version Notification for draft-lagos-lpwan-icmpv6-static-context-hc-00.txt X-BeenThere: lp-wan@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 03:31:04 -0000 --089e08245e7ca283d3055339290b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, We have submitted a new draft to propose ICMPv6 using SCHC. Regards, Diego Dujovne A new version of I-D, draft-lagos-lpwan-icmpv6-static-context-hc-00.txt has been successfully submitted by Tom=C3=A1s Lagos and posted to the IETF repository. Name: draft-lagos-lpwan-icmpv6-static-context-hc Revision: 00 Title: LPWAN Static Context Header Compression (SCHC) for ICMPv6 Document date: 2017-06-29 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-lagos-lpwan- icmpv6-static-context-hc-00.txt Status: https://datatracker.ietf.org/doc/draft-lagos-lpwan-icmpv6- static-context-hc/ Htmlized: https://tools.ietf.org/html/draft-lagos-lpwan-icmpv6- static-context-hc-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-lagos-lpwan- icmpv6-static-context-hc-00 Abstract: This document provides the implementation of the LPWAN static context header compression (SCHC) for the Internet Control Message Protocol version 6 (ICMPv6) on networks with star topology. SCHC is a header compression technique which uses RoHC concepts and the flexibility of 6LoWPAN to avoid fields that are known by all network devices and compress the remaining header fields. The ICMPv6 messages considered in this draft are Echo Request, Echo Reply and Neighbor Discovery. --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --089e08245e7ca283d3055339290b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0We have submitted a new draft to propose
= ICMPv6 using SCHC.
Regards,

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diego Dujovne

=

A new version of I-D, draft-lagos-lpwan-icmpv6-static-context-hc-00.tx= t
has been successfully submitted by Tom=C3=A1s Lagos and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-lagos-lpwan-icmpv6-static-context-hc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LPWAN Static Context Header Compre= ssion (SCHC) for ICMPv6
Document date:=C2=A0 2017-06-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts= /draft-lagos-lpwan-icmpv6-static-context-hc-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-lagos-lpwan-ic= mpv6-static-context-hc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-lagos-lpwan-icmpv6-sta= tic-context-hc-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-lagos-l= pwan-icmpv6-static-context-hc-00


Abstract:
=C2=A0 =C2=A0This document provides the implementation of the LPWAN static = context
=C2=A0 =C2=A0header compression (SCHC) for the Internet Control Message Pro= tocol
=C2=A0 =C2=A0version 6 (ICMPv6) on networks with star topology.=C2=A0 SCHC = is a header
=C2=A0 =C2=A0compression technique which uses RoHC concepts and the flexibi= lity of
=C2=A0 =C2=A06LoWPAN to avoid fields that are known by all network devices = and
=C2=A0 =C2=A0compress the remaining header fields.=C2=A0 The ICMPv6 message= s considered
=C2=A0 =C2=A0in this draft are Echo Request, Echo Reply and Neighbor Discov= ery.









--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica= y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Universidad Diego Po= rtales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
<= /div>
--089e08245e7ca283d3055339290b--