From nobody Sat Jul 1 10:04:39 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 587F4128896; Sat, 1 Jul 2017 10:04:37 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149892867732.532.13514525150008761783@ietfa.amsl.com> Date: Sat, 01 Jul 2017 10:04:37 -0700 Archived-At: Subject: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.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: Sat, 01 Jul 2017 17:04:37 -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-05.txt Pages : 37 Date : 2017-07-01 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 these kind of networks. A common context stored in a LPWAN device and in the network is used. This context keeps 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 mechanisms will not be enough to send the compressed packet in one L2 PDU, so the SCHC Fragmentation protocol must be used when needed. This document describes SCHC compression/decompression mechanism framework and applies it to IPv6/UDP headers. Similar solutions for other protocols such as CoAP will be described in separate documents. Moreover, this document specifies fragmentation and reassembly mechanim for SCHC compressed packets exceeding the L2 PDU size and for the case where the SCHC compression is not possible then the 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context-hc-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-ipv6-static-context-hc-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 1 11:04:43 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 D3C05127342 for ; Sat, 1 Jul 2017 11:04:01 -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 T2axjQ5I8n2z for ; Sat, 1 Jul 2017 11:03:59 -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 DBD13127136 for ; Sat, 1 Jul 2017 11:03:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 82F70BE74; Sat, 1 Jul 2017 19:03:56 +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 l_5pWvFEO5RW; Sat, 1 Jul 2017 19:03:50 +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 C0081BE64; Sat, 1 Jul 2017 19:03:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498932230; bh=W6uUI7N/Pw1P5uvtVWEXKGMeKSv/a0vePWQlDo4VpPM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=y5RqXX1wwtznA2//EmfszlOJHa4sIleBDrYXdHSa03Hbve14Gblbv2eZVvgKXdloD vefi3v4BrVW1WwMD3oMsR93mvrwQnL0DUamFqUUVYgI2LmcmpC4BysALqEYjBn+HfZ yuZz3mmDaFn461EiK1zKSUNNk+NmnnDzwHkwNPqs= To: Russ Housley , lp-wan@ietf.org References: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sat, 1 Jul 2017 19:03:49 +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="UcBNRxOVcB8sdbN600W0BPwHMX9gDcfwT" 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: Sat, 01 Jul 2017 18:04:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UcBNRxOVcB8sdbN600W0BPwHMX9gDcfwT Content-Type: multipart/mixed; boundary="UIcQiLU2gm18IABk50v0mmPmQ8EcXmPKI"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , lp-wan@ietf.org Message-ID: 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> --UIcQiLU2gm18IABk50v0mmPmQ8EcXmPKI Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Russ, I'm updating the draft for now as described below. I'll shoot out version -05 soon but in the meantime these changes are visible in the repo [1] as always. [1] https://github.com/sftcd/lpwan-ov The WG have a virtual interim on Wednesday if you wanted to follow up via voice. 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 Done. >=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 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. Agreed and I can't answer that one myself. OTOH, my assumption has always been that, for LPWAN purposes, nbIoT keying could be considered to the same as LTE. I don't think there're differences that'd be visible or meaningful for the WG, do you? If not, then I think it's ok to omit that detail, as LTE is fairly well-known, even if extremely complex;-) >=20 > Section 2.3.2 does not talk about encryption, so I assume that the > messages are always in the clear.=20 IIUC confidentiality is left to applications yes and is not supported by sigfox. I added a note making saying that. > 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. I took a look about and didn't find details so it looks like those aren't public as of now. I guess Juan-Carlos can correct that if it's incorrect. >=20 > 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?=20 I added the ciphersuite detail provided by Paul to table 5. > Does 802.11i mean that AES-CCM is used for > encryption and integrity? I added the CCM* info to table 5 too. >=20 > 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 us= e > 802.1X with EAP-TLS. This is quite different than the other three > example LP WANs. How does the gap analysis address this situation? I added a note as per Paul's mail. >=20 > Nits >=20 > Section 2.1.2: s/described below../described below./ s/AEs-encrypt > operation/AES-encrypt operation/ Thanks for the review, Cheers, S. >=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 >>=20 >> Dear all, >>=20 >> As discussed during the last interim, we are starting a WGLC on the >> 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, DO review the document now and DO provide your comments and >> remarks if you see any issues. >>=20 >> The WGCL will end in two weeks, on July 3rd, 2017, 23h55 CEST. >>=20 >> Best, Pascal and Alexander >=20 > _______________________________________________ lp-wan mailing list=20 > lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan >=20 --UIcQiLU2gm18IABk50v0mmPmQ8EcXmPKI-- --UcBNRxOVcB8sdbN600W0BPwHMX9gDcfwT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZV+QFAAoJEC88hzaAX42ijYcH/3B0U9Klt+FWfA5Wc0fN3DNG dej2RV6ADP4E5i4CaPQxjkNiPpnqB3FhPnSuh+SNXafphrweer2sOETJGTfGjWeP AnThv1YbKlyv+yMrPjfTFS47cgfrc6qervpWzouovxCTEBKkRAqGG84rOH9DIARD WA398epjlIjTHG74hSTjKdqn2+oQsRb2KZ0Qy984XCg6dzghZAhjkFkqG13yStZ4 BHYpLPUU4MYf5e3Sz6dXbTZu3uQjQWxXH+Rlg8VfkHAAFTZ2xTLdKxHcobZBY8wT DDZub1EZGpyxBBIDiLKocgjSwsZBf6yFEOWvE6ciqFTtLzF9zDbBr753rlLECGU= =Drrp -----END PGP SIGNATURE----- --UcBNRxOVcB8sdbN600W0BPwHMX9gDcfwT-- From nobody Sat Jul 1 11:07: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 020F3127136 for ; Sat, 1 Jul 2017 11:07:49 -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 chkh5tQDDLAy for ; Sat, 1 Jul 2017 11:07:47 -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 054D51201F8 for ; Sat, 1 Jul 2017 11:07:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B13F5BE77; Sat, 1 Jul 2017 19:07:45 +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 PFgU_OpKNRL6; Sat, 1 Jul 2017 19:07:43 +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 3F8EDBE74; Sat, 1 Jul 2017 19:07:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498932463; bh=FGOiOGq2dJsQFv92mhJZY/MyLMsvPM3p5sv9cqQfgqM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ebHBiFAQRqD487RQgofn4Vlavtq9O/xJQjkhSFGlRjzukkGjrpSluQKCDJDYyNPWO ctqTfO9GxLCZguyKWO6abSOTsvDyk6j3OvQQJZ60Icq6UxWA327mdcGAClxb50TwSc hfojucBg66b8eYb7f3ZrTOp5dvX7gJ1jn0ZN0Ah4= To: Alper Yegin , Alexander Pelov Cc: lp-wan@ietf.org References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <13FF95DD-C195-472D-8DB5-74C9B374FFF2@ackl.io> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <4bbee41f-c70a-afa4-3504-436db5ae74b5@cs.tcd.ie> Date: Sat, 1 Jul 2017 19:07:42 +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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sqkeQ5o3u0tBiuxMFrWPhxml4e5cjnSP7" 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: Sat, 01 Jul 2017 18:07:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sqkeQ5o3u0tBiuxMFrWPhxml4e5cjnSP7 Content-Type: multipart/mixed; boundary="uSMK7OWo2uvpE1uSa9aHtjKucB2hO2jR7"; protected-headers="v1" From: Stephen Farrell To: Alper Yegin , Alexander Pelov Cc: lp-wan@ietf.org Message-ID: <4bbee41f-c70a-afa4-3504-436db5ae74b5@cs.tcd.ie> Subject: Re: [lp-wan] lpwan-overview comments References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <13FF95DD-C195-472D-8DB5-74C9B374FFF2@ackl.io> In-Reply-To: --uSMK7OWo2uvpE1uSa9aHtjKucB2hO2jR7 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 28/06/17 09:05, Alper Yegin wrote: > Hi Alex, >=20 > 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 LoR= aWAN 1.0.2 details, or an update may fold in LoRaWAN 1.1 changes as well.= >=20 Given the stated milestones I guess that we should stick with describing 1.0.2 in the WG overview draft. Cheers, S. PS: I'll respond to the other mail in a bit. > Alper >=20 >=20 >=20 >=20 >=20 >> On Jun 28, 2017, at 10:56 AM, Alexander Pelov wrote: >> >> Thanks for the comments and the detailed review, Alper! >> >> I guess the changes you describe are not likely to be changed until th= e specs you describe get published, right? >> >> Thanks again, >> Alexander >> >> >>> Le 28 juin 2017 =C3=A0 09:05, Alper Yegin > 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 i= s a >>> seven-bit value. A private network (common for LoRaWAN) can use t= he >>> 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 t= hat >>> is pre-provisioned into the device. >>> >>> >>> In the LoRa Alliance we made a change to the way DevAddrs are generat= ed based on the NetIDs. It=E2=80=99s no longer simply using the 7 least-s= ignificant-bits of NetID as the 7 most-significant-bits of the DevAddr. E= ven 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 i= s concerned. The new scheme, which allows more efficient allocation and u= se of NetIDs, is described in the Backend Interfaces spec, which is not p= ublished yet. >>> >>> What that means is, in this I-D, we better not describe "NwkID=3D7 bi= ts=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 t= hat >>> is pre-provisioned into the device. In case of roaming devices, t= he device address >>> is assigned based on the 24-bit NetID that is allocated to the net= works >>> by the LoRa Alliance. Non-roaming devices can be assigned device a= ddresses >>> 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 b= e a >>> registered IEEE EUI64 value. >>> >>> >>> >>> AppEUI is being renamed as JoinEUI in LoRaWAN 1.1, and in fact it ide= ntifies 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 tha= t uniquely identifies >>> >>> the entity able to process the JoinReq frame. >>> >>> =20 >>> So, we better not treat it as application identifier, but as identifi= er 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 >> >=20 >=20 >=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >=20 --uSMK7OWo2uvpE1uSa9aHtjKucB2hO2jR7-- --sqkeQ5o3u0tBiuxMFrWPhxml4e5cjnSP7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZV+TuAAoJEC88hzaAX42i1/EH/RzV6aA2L8YKorH1863bkbha dSuevINEKm6Ma0q0QrcGOY39mzKOXquAAEicKp96GkJTrsNFB+Mp9QU2IdTravqV 6GN/nPc2Tk2zPHMqr1tkZowp2EFuLnhmuVK7wFA6Vy2hVpr292dJEjDEh0sbaapC 7a8XRY2/0lreOFjeLHWIYUUpZhW+U0r9ZmlCG0ML85HiwBh68BJYKWIH5zpAi9+p E6a/MgvUBBE/h8c+BBPe8mHVoONNJwtGAq9Y8azF4P/LSOAIeD8OcXWdsF9GyYM3 PIk+dYO8M1bfeyQI9FyVPMG143Q+Mo2vzcfd/oGlvkB0D/9Ec1mYCJFQofg5y80= =Zso2 -----END PGP SIGNATURE----- --sqkeQ5o3u0tBiuxMFrWPhxml4e5cjnSP7-- From nobody Sat Jul 1 11:15: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 A2B57127136 for ; Sat, 1 Jul 2017 11:15:39 -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 K02tQ72isn4m for ; Sat, 1 Jul 2017 11:15:37 -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 2F13C120454 for ; Sat, 1 Jul 2017 11:15:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EB938BE77; Sat, 1 Jul 2017 19:15:35 +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 AhLT3SIuKoZ8; Sat, 1 Jul 2017 19:15:34 +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 DEFF4BE64; Sat, 1 Jul 2017 19:15:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498932934; bh=0sObFrasZwCHJdH4Q9lTF5deFcG4TUV4DBHY3ST+Eo4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VAAJ8E+21cHRfX77B3DilrF5cPPHPgVLju5zr6S0ct99xmbT659qo/YmdQ4aA4GvK 68cxdyPGCAxSaQ/llnMEHW2IPXMJNGEniQr2P8ZP6X0I7JnQvmbzChNoV0O74OuGnx 25mpZu3OuHU8yVRH3w7paHw4etdLi9MH/swd8tdQ= To: Alper Yegin , lp-wan@ietf.org References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie> Date: Sat, 1 Jul 2017 19:15:33 +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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sfjvKCuKjL7gQX5XOTNoWNmI8XSwupnKI" 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: Sat, 01 Jul 2017 18:15:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sfjvKCuKjL7gQX5XOTNoWNmI8XSwupnKI Content-Type: multipart/mixed; boundary="DhKt1GX1K5FoKAg4BGtXloH2Fw7QTXURP"; protected-headers="v1" From: Stephen Farrell To: Alper Yegin , lp-wan@ietf.org Message-ID: <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie> Subject: Re: [lp-wan] lpwan-overview comments References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> In-Reply-To: --DhKt1GX1K5FoKAg4BGtXloH2Fw7QTXURP Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 28/06/17 08:05, Alper Yegin wrote: > Dear LPWAN WG members and Stephen, >=20 > I made one more pass over the LoRaWAN section of the I-D and spotted th= e 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 tha= t > 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-sig= nificant-bits of NetID as the 7 most-significant-bits of the DevAddr. Eve= n though the generation scheme was already described in the LoRaWAN 1.0 s= pec, 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 pub= lished 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 tha= t > 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 netwo= rks > by the LoRa Alliance. Non-roaming devices can be assigned device add= resses > by the network without relying on a LoRa Alliance-assigned NetID. >=20 I made that change. >=20 >=20 >=20 >=20 >=20 > End-devices are assumed to work with one or a quite limited number o= f > 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 ident= ifies the JS. > JoinEUI and JS terms are not present in LW1.0.x, but nevertheless the l= atest 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 So I just don't understand how that can be correct, sorry;-) A join-request is processed by a NS (or, in 1.1 a JS). There are very few of those, maybe 1 per n/w. There are many more device-types, which do mostly map 1:1 with AppEUIs. And the same device-types can be found in many networks. So the suggested text just seems incorrect to me. I'd say we're better to just stick with 1.0.2 terms tbh. Cheers, S. >=20 >=20 >=20 >=20 > Thanks Stephen. >=20 > Alper >=20 >=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >=20 --DhKt1GX1K5FoKAg4BGtXloH2Fw7QTXURP-- --sfjvKCuKjL7gQX5XOTNoWNmI8XSwupnKI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZV+bFAAoJEC88hzaAX42inBIIAIpzBS8Hl5H4oAXkcs/JsHqM oIQfUebT+GBGQ/7iwLfpW/PhN7eY2jeot/RWX9+MYjyWgPv57ii/uldo5mtHBiza b7ufKcYsyLDAUMlbneIxmBnuLi/4l0K0OVzOKs1+cQotmg3Q5Gx8Eb9C/QvOweAA ivpRWCf3nzA/ycjdb+9QNbc+qQY3Qo5VyFVLlk+shgJ2isBvBpb+7hRxVqqwjt25 3gNpEWyQiaKTbE2LuQlAKh6D8DgZD980+t5wK6ao5jv3+AKMeGCLKEo1ApmQAxIz Rih1DlTcH5/SX3JbK7QGwFMFS+at+iA41LMbvH9G58fcCDmYMBr1j4iPhaKmpc0= =pFYs -----END PGP SIGNATURE----- --sfjvKCuKjL7gQX5XOTNoWNmI8XSwupnKI-- From nobody Sat Jul 1 11:22:25 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 61CD91201F8; Sat, 1 Jul 2017 11:22:23 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149893334336.489.9442381469735966027@ietfa.amsl.com> Date: Sat, 01 Jul 2017 11:22:23 -0700 Archived-At: Subject: [lp-wan] I-D Action: draft-ietf-lpwan-overview-05.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: Sat, 01 Jul 2017 18:22:23 -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-05.txt Pages : 41 Date : 2017-07-01 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-overview-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 1 12:18:44 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 5EA0B1201F8 for ; Sat, 1 Jul 2017 12:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 wxBCj_zFK6RB for ; Sat, 1 Jul 2017 12:18:40 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 8B2C91200B9 for ; Sat, 1 Jul 2017 12:18:40 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id r103so217639827wrb.0 for ; Sat, 01 Jul 2017 12:18:40 -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 :content-transfer-encoding:message-id:references:to; bh=1Ms6l4PgUxjy95iMGXarQOxiqty3BSHM2h8AMn6PwdI=; b=NXbuqLqYOlBFtwAu2HkLFcDEqiCA/a/x84eeLtCOfk1l4BxvxkGXAxvr79/W9TS9e2 BDAP3d8pl3yMn/8SbqquWnWhVZQ9MOxs4hUl0h1qFi/i1RG4PAIsFC58rs4I126xOBBJ MGdJ7y5xFaUwTCuaYNCLBAYKguBMza0d8C8z8= 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 :content-transfer-encoding:message-id:references:to; bh=1Ms6l4PgUxjy95iMGXarQOxiqty3BSHM2h8AMn6PwdI=; b=GApx43PqjFsO60iaGMVQp4Nb/F51QCdU1ByQ4NiuncB+NVvm9CPzlEwENFP3ligzFc w81FUjERAHSgA1ZMfH3/ebVwsCA+Y3jhMLUH1r9ipBR68oUVfttjC28llX+KZI75lgYH AuBMJ89yZJTsHarSQUsMIF2KHyN1vayWGgsP15J0WnE+SYMcmzqrJElRVT2EpugmCcd2 /7685u84NCi9ukb2cGPbM7uOLfNrU4bHYj3rHsNKY322vt6z0yI0d0vSHKf3pQ6Nun2/ j/c/CIRKhPJT8W+Vrz2O7BuZg7n1aG/jsnvuyzfBmEnvURh1SIX9wKO65wyMZs0LE4Om 0Jtg== X-Gm-Message-State: AKS2vOw/UsE+ez1NDs+ZOtFXUO4/2OVcX0Zh6EYXkfPC8ZZ3LdtqEPk4 pKlj5tcZ9hjGoiAPLt3Ieg== X-Received: by 10.223.143.77 with SMTP id p71mr28485952wrb.3.1498936718928; Sat, 01 Jul 2017 12:18:38 -0700 (PDT) Received: from [10.119.8.17] (178-211-44-68.turkrdns.com. [178.211.44.68]) by smtp.gmail.com with ESMTPSA id 137sm16040278wmm.29.2017.07.01.12.18.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Jul 2017 12:18:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Alper Yegin In-Reply-To: <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie> Date: Sat, 1 Jul 2017 22:18:35 +0300 Cc: lp-wan@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie> To: Stephen Farrell 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: Sat, 01 Jul 2017 19:18:43 -0000 Hi Stephen, >>=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 > So I just don't understand how that can be correct, sorry;-) >=20 > A join-request is processed by a NS (or, in 1.1 a JS). There are very > few of those, maybe 1 per n/w. There are many more device-types, which > do mostly map 1:1 with AppEUIs. And the same device-types can be found > in many networks. >=20 > So the suggested text just seems incorrect to me. >=20 > I'd say we're better to just stick with 1.0.2 terms tbh. >=20 If we want to strictly stick with the LW1.0.2 definition, than it=E2=80=99= d be: AppEUI IEEE EUI64 application id that identifies the entity = processesing Join-request In practice, it identifies the JS. Note that: - NS and JS may be co-located or separated. This is true for both = LW1.0.x and LW1.1 specs. - The entity that processes the Join-request and generates Join-accept = is the JS. - Single NS may be connected to multiple JSs. - Spec is based on 1:1 relationship between the end-device and JS. = (Obviously, implementations can extend that). - If the NS knows the identify of the JS to process an incoming = Join-request based on the DevEUI, then AppEUI (which is later renamed to = JoinEUI in LW1.1) has no significance. Otherwise, the NS relies on the = AppEUI (JoinEUI) to identify the JS to process the request. I just elaborated on these details, not to suggest including in the = draft, but to point out that the significance of the AppEUI is to =E2=80=9C= identify(ies) the entity able to process the JoinReq frame.=E2=80=9D as = stated in the LW1.0.2 spec. As long as we capture that, it is OK if the = draft also refers to it as =E2=80=9Capplication id=E2=80=9D. (The reason = name of the Join-request field morphed from AppEUI into JoniEUI in LW1.1 = is basically this.) Regards, Alper > Cheers, > S. >=20 >>=20 >>=20 >>=20 >>=20 >> Thanks Stephen. >>=20 >> Alper >>=20 >>=20 >>=20 >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >>=20 >=20 From nobody Sat Jul 1 12:41: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 55792129AB0 for ; Sat, 1 Jul 2017 12:41:04 -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 NzPa9L3BLydJ for ; Sat, 1 Jul 2017 12:41:01 -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 ABC6C126CC7 for ; Sat, 1 Jul 2017 12:41:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52F61BE77; Sat, 1 Jul 2017 20:40:59 +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 WDwLEROlTWnv; Sat, 1 Jul 2017 20:40:57 +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 49794BE74; Sat, 1 Jul 2017 20:40:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1498938057; bh=69kX/ibosMyFyw1v6uht/+aXXa6nDTSjHWzX5N2sAio=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jZbWRUJ0ZRkDjaV3VSW1rBojjinezX5iXB7G3R/v2wWZG42u4JxP7/sBbbqZIlalq 6dYhEJ3FuAcaoHgcKzHZno8WC5abXcjcSAiy10+K+/LdeDNtamaMeFu0DTS0/iQdvx CjFCZ531TLrrHC7XL2yK6nC2BZvMlBpjXGk/mVKI= To: Alper Yegin Cc: lp-wan@ietf.org References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie> <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <88a4a10c-6abf-efeb-0430-da9cbf24b5a9@cs.tcd.ie> Date: Sat, 1 Jul 2017 20:40:56 +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: <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EvmGVa7oCpNvVxeTnDcEL3iWftx4ivhsv" 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: Sat, 01 Jul 2017 19:41:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EvmGVa7oCpNvVxeTnDcEL3iWftx4ivhsv Content-Type: multipart/mixed; boundary="OC1seMeibUk3Qsx4pKdmUOWvP0UxLaprj"; protected-headers="v1" From: Stephen Farrell To: Alper Yegin Cc: lp-wan@ietf.org Message-ID: <88a4a10c-6abf-efeb-0430-da9cbf24b5a9@cs.tcd.ie> Subject: Re: [lp-wan] lpwan-overview comments References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie> <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> In-Reply-To: <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> --OC1seMeibUk3Qsx4pKdmUOWvP0UxLaprj Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, I suspect this is one of those where we'll only understand one another f2f, but... On 01/07/17 20:18, Alper Yegin wrote: > Hi Stephen, >=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. >>> >>> >>> >>> AppEUI is being renamed as JoinEUI in LoRaWAN 1.1, and in fact it ide= ntifies 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 tha= t uniquely identifies >>> >>> the entity able to process the JoinReq frame. >>> >>> >>> So, we better not treat it as application identifier, but as identifi= er 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 >> >> So I just don't understand how that can be correct, sorry;-) >> >> A join-request is processed by a NS (or, in 1.1 a JS). There are very >> few of those, maybe 1 per n/w. There are many more device-types, which= >> do mostly map 1:1 with AppEUIs. And the same device-types can be found= >> in many networks. >> >> So the suggested text just seems incorrect to me. >> >> I'd say we're better to just stick with 1.0.2 terms tbh. >> >=20 > If we want to strictly stick with the LW1.0.2 definition, than it=E2=80= =99d be: >=20 > AppEUI IEEE EUI64 application id that identifies the entity processesin= g Join-request >=20 Just to note: the above doesn't help me. I read it as the same as your previous suggested text, and hence, for me, it just reads like a false statement. (I don't mean badly worded, I mean untrue:-) > In practice, it identifies the JS. Let me try explain why I don't get that. Each instance of some class of device will have the same AppEUI, call that "X." Let's say there are 10^5 instances of devices like that. Let's say there are 2 LoRaWAN networks, each with an NS that has a co-located NS. With half the "X" type devices in each. Both networks (call them N1, N2) have devices of the type that uses AppEUI X. There is a 5000:1 ratio between instances of X and NS's/JS's in each network. X therefore does not identify an NS or JS or anything like that. Do you see why I'm confused if you want to say that X identifies or names the JS? Cheers, S. >=20 > Note that: > - NS and JS may be co-located or separated. This is true for both LW1.0= =2Ex and LW1.1 specs. > - The entity that processes the Join-request and generates Join-accept = is the JS. > - Single NS may be connected to multiple JSs. > - Spec is based on 1:1 relationship between the end-device and JS. (Obv= iously, implementations can extend that). > - If the NS knows the identify of the JS to process an incoming Join-re= quest based on the DevEUI, then AppEUI (which is later renamed to JoinEUI= in LW1.1) has no significance. Otherwise, the NS relies on the AppEUI (J= oinEUI) to identify the JS to process the request. >=20 > I just elaborated on these details, not to suggest including in the dra= ft, but to point out that the significance of the AppEUI is to =E2=80=9C = identify(ies) the entity able to process the JoinReq frame.=E2=80=9D as s= tated in the LW1.0.2 spec. As long as we capture that, it is OK if the dr= aft also refers to it as =E2=80=9Capplication id=E2=80=9D. (The reason na= me of the Join-request field morphed from AppEUI into JoniEUI in LW1.1 is= basically this.) >=20 > Regards, >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> Cheers, >> S. >> >>> >>> >>> >>> >>> Thanks Stephen. >>> >>> Alper >>> >>> >>> >>> _______________________________________________ >>> 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 >=20 --OC1seMeibUk3Qsx4pKdmUOWvP0UxLaprj-- --EvmGVa7oCpNvVxeTnDcEL3iWftx4ivhsv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZV/rIAAoJEC88hzaAX42iFLoIAKx3FMyvFCpOcgRqh8j5yWIb BTZKsIkV3qaE3tPe8Mg+LwkLepiB72herV2FGUgx5Tc1eMYv/bI7ilKfJDR0v1lz 8mA4N6vhI3YWKocI9mdrVTV7DhcF/E0hK44SMVox/L5K5p2hIWvyu+l+GoJnBol+ c8Af0jKJlAj2vj4EgyQyiHpO1rnASUBp07vDB2uTz/uISNurijfcFWnJ4zYJhulH C9j35KOcYQ9G23nZzr075wFXnyVvha/eioJnwGnEAR+jO99oufCt/AEwj8IsZ4lL 9cGngKsUEan7RjEXr0vCpuLhZ7cAeWZ+V50AojANjn6b492n6YzNmTGf51V4uRw= =HEWM -----END PGP SIGNATURE----- --EvmGVa7oCpNvVxeTnDcEL3iWftx4ivhsv-- From nobody Sat Jul 1 13:54: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 9F471129ADF for ; Sat, 1 Jul 2017 13:54:16 -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 lakDFHBMLdyJ for ; Sat, 1 Jul 2017 13:54:15 -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 E8B3E129ADE for ; Sat, 1 Jul 2017 13:54:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 52BD3300564 for ; Sat, 1 Jul 2017 16:54:14 -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 EXvUkTdbU3MH for ; Sat, 1 Jul 2017 16:54:13 -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 24A22300278; Sat, 1 Jul 2017 16:54:13 -0400 (EDT) From: Russ Housley Message-Id: <92B79447-F487-4F4F-82F5-2A6622DE022C@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6F3E6BA6-FC4C-400D-A76A-3E852F891F52"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 1 Jul 2017 16:54:09 -0400 In-Reply-To: Cc: lp-wan@ietf.org To: Stephen Farrell References: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> 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: Sat, 01 Jul 2017 20:54:17 -0000 --Apple-Mail=_6F3E6BA6-FC4C-400D-A76A-3E852F891F52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Stephen: It seems only one comment still needs any discussion, so I dropped the = others. >> 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. >=20 > Agreed and I can't answer that one myself. OTOH, my assumption has > always been that, for LPWAN purposes, nbIoT keying could be considered > to the same as LTE. I don't think there're differences that'd be = visible > or meaningful for the WG, do you? If not, then I think it's ok to omit > that detail, as LTE is fairly well-known, even if extremely complex;-) I was hoping that someone on the mail list would volunteer the answers. = If we do not have anyone that knows the answers, then we cannot include = them. Russ --Apple-Mail=_6F3E6BA6-FC4C-400D-A76A-3E852F891F52 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAllYC/QACgkQiuTu0PWcEcsnSgCgySgoJ089StNlP2yMHEzqjm4J +mMAoKlXPjg9vwniFqWfL/frKaV4GSVI =FgFU -----END PGP SIGNATURE----- --Apple-Mail=_6F3E6BA6-FC4C-400D-A76A-3E852F891F52-- From nobody Sun Jul 2 10:04: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 A3B0712783A for ; Sun, 2 Jul 2017 10:04:22 -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 N65xe5cRhjXE for ; Sun, 2 Jul 2017 10:04:21 -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 2BC6D120227 for ; Sun, 2 Jul 2017 10:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2615; q=dns/txt; s=iport; t=1499015061; x=1500224661; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GeOMn0b/u5SBFe1URhYarWaOUC81X20gtfSd+QA02Yo=; b=meUr2C8lcP9UYAdfb3NoUF2CGBJhOQK8GPT+HinVP0LxXKwGyKD+YsfX 2BZBM8b5DMcrrQHCq94ByqQp6zB5N6b68QTI1Rwp5NJ5gU/yypb0CfgNm KIDS2r/amjixJLAaECYuDUMsMHYbqD6+Rhz2XooMMt6KrW3aS707UHLbr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQB2JllZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1mBcQe3dYYcAoMZQhUBAgEBAQEBAQFrKIUZBjotEhACAQg2EDI?= =?us-ascii?q?lAgQBDQWKL7Qvi0kBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyeDTIFhgySEOhMBA?= =?us-ascii?q?YYPAQSefwKTf4IMiTuGVpUvATUigQp1FUmHFXaGUIEjgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,298,1496102400"; d="scan'208";a="265035444" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2017 17:04:20 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v62H4KON030594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 2 Jul 2017 17:04:20 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 2 Jul 2017 12:04:19 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Sun, 2 Jul 2017 12:04:19 -0500 From: "Sri Gundavelli (sgundave)" To: Russ Housley , Stephen Farrell CC: "lp-wan@ietf.org" Thread-Topic: [lp-wan] WGLC on LPWAN Overview draft Thread-Index: AQHS6tb/Uf8AoLGwD0a01uj34/pWKaI/puuAgAAvl4CAANzDgA== Date: Sun, 2 Jul 2017 17:04:19 +0000 Message-ID: References: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> <92B79447-F487-4F4F-82F5-2A6622DE022C@vigilsec.com> In-Reply-To: <92B79447-F487-4F4F-82F5-2A6622DE022C@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.59] Content-Type: text/plain; charset="us-ascii" Content-ID: <8C96BC2A917CAB469B650167F3A789CA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sun, 02 Jul 2017 17:04:23 -0000 On 7/1/17, 1:54 PM, "lp-wan on behalf of Russ Housley" wrote: >Stephen: > >It seems only one comment still needs any discussion, so I dropped the >others. > >>> 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. >>=20 >> Agreed and I can't answer that one myself. OTOH, my assumption has >> always been that, for LPWAN purposes, nbIoT keying could be considered >> to the same as LTE. I don't think there're differences that'd be visible >> or meaningful for the WG, do you? If not, then I think it's ok to omit >> that detail, as LTE is fairly well-known, even if extremely complex;-) > >I was hoping that someone on the mail list would volunteer the answers. >If we do not have anyone that knows the answers, then we cannot include >them. >From my reading, the text in NBIOT section is just stating that there is security with integrity protection in the user plane protocol stack. The challenge with this document is that its attempts to summarize some complex system architectures defined outside IETF and present it in few paragraphs. This is the case with all the LPWAN protocols included in this document and not just with NBIOT. As long as there are pointers to all the key specifications, it should be sufficient IMO. It is not trivial to cover all the protocol/security aspects in sufficient detail in few paragraphs and that may not even be needed. If I want to understand a specific LPWAN technology in detail, I will review those system specs and the last thing I will read is this document. I always wondered why this document was even needed. The document would have carried some value if it had drawn some commonalities between various LPWAN system architectures and made the case for standardized protocol interfaces between network elements. So far any such attempts resulted in folks saying a given SDO has already defined that interface. So, I view this as a very high level document that tells me what are all the LPWAN technologies that are out there; that may be useful for some folks and so its fine.=20 Sri From nobody Sun Jul 2 10:14: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 5EF7F120227 for ; Sun, 2 Jul 2017 10:14:50 -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 jgou3rys4lGE for ; Sun, 2 Jul 2017 10:14:48 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C0C128DF2 for ; Sun, 2 Jul 2017 10:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2863; q=dns/txt; s=iport; t=1499015687; x=1500225287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9vFdvcLPxzUjtKEb62kuaso6eOfHMFvJNSXSFu6RfCo=; b=fdQ9eMsmqx1HjMHZTfexXR6jHoOZusIUw5nDkbPJwUrNi6VyFeQf+/MF uW/fsk74vEPeUdXgCkG034Vsr1p8IFvLTl3adPtEXZtBAsF2vr0C0rX8/ or/+1ba7+Ha0KgBFzv6NDcUNQDZOVMW0wGcyD4wgiEPNIQpUSAyj3AVFk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQCqKVlZ/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1mBYBEHn2eVfYIRhhwCgxlBFgECAQEBAQEBAWsohRkBBWcSEAI?= =?us-ascii?q?BCBguMiUCBAENBYovtCKLSQEBAQEBAQEBAQEBAQEBAQEBAQEfgyeDTIFhgySEO?= =?us-ascii?q?gERAgGGDwEEnn8Ck3+CDIk7hlaVLwEmBit/C3UVSYcVdodzgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,298,1496102400"; d="scan'208";a="447345478" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2017 17:14:46 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v62HEkrh011173 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 2 Jul 2017 17:14:47 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 2 Jul 2017 12:14:46 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Sun, 2 Jul 2017 12:14:46 -0500 From: "Sri Gundavelli (sgundave)" To: "Sri Gundavelli (sgundave)" , Russ Housley , Stephen Farrell CC: "lp-wan@ietf.org" Thread-Topic: [lp-wan] WGLC on LPWAN Overview draft Thread-Index: AQHS6tb/Uf8AoLGwD0a01uj34/pWKaI/puuAgAAvl4CAANzDgIAAAuyA Date: Sun, 2 Jul 2017 17:14:46 +0000 Message-ID: References: <69152223-0503-4A52-A637-7A5FBAA5A41D@vigilsec.com> <92B79447-F487-4F4F-82F5-2A6622DE022C@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.59] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8AA9B7E925DAA742B1B0D4776DA5EB4A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sun, 02 Jul 2017 17:14:50 -0000 (formatting error in my prev email.. resending this=8A) On 7/2/17, 10:04 AM, "lp-wan on behalf of Sri Gundavelli (sgundave)" wrote: > > >On 7/1/17, 1:54 PM, "lp-wan on behalf of Russ Housley" > wrote: > >>Stephen: >> >>It seems only one comment still needs any discussion, so I dropped the >>others. >> >>>> 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. >>>=20 >>> Agreed and I can't answer that one myself. OTOH, my assumption has >>> always been that, for LPWAN purposes, nbIoT keying could be considered >>> to the same as LTE. I don't think there're differences that'd be >>>visible >>> or meaningful for the WG, do you? If not, then I think it's ok to omit >>> that detail, as LTE is fairly well-known, even if extremely complex;-) >> >>I was hoping that someone on the mail list would volunteer the answers. >>If we do not have anyone that knows the answers, then we cannot include >>them. >From my reading, the text in NBIOT section is just stating that there is security with integrity protection in the user plane protocol stack. The challenge with this document is that its attempts to summarize some complex system architectures defined outside IETF and present it in few paragraphs. This is the case with all the LPWAN protocols included in this document and not just with NBIOT. As long as there are pointers to all the key specifications, it should be sufficient IMO. It is not trivial to cover all the protocol/security aspects in sufficient detail in few paragraphs and that may not even be needed. If I want to understand a specific LPWAN technology in detail, I will review those system specs and the last thing I will read is this document. I always wondered why this document was even needed. The document would have carried some value if it had drawn some commonalities between various LPWAN system architectures and made the case for standardized protocol interfaces between network elements. So far any such attempts resulted in folks saying a given SDO has already defined that interface. So, I view this as a very high level document that tells me what are all the LPWAN technologies that are out there; that may be useful for some folks and so its fine.=20 Sri > From nobody Tue Jul 4 01:17:02 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 E43C01286D6; Tue, 4 Jul 2017 01:17:00 -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 w0O43-xv_vxY; Tue, 4 Jul 2017 01:16:59 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00741126B6E; Tue, 4 Jul 2017 01:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12310; q=dns/txt; s=iport; t=1499156219; x=1500365819; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C28t93x7Tehj24Ap6MHhEuNK5REdAxaV3pRiHaWYhvo=; b=GQXA9e1dQyy06gyY/0Cr2K9TjuQpfoa6n1HAd4BsqfX5TUep6DlN7p2N /w3PkP+0fx/j360dBRefVW7xSpHslM4Boj+OShpNL6eLKTpq8Gef8fj2k ilzocuBUjUlGxZMSC+q40OrrFlyVxpZxHqSRGhrN6ibEDpPhfPbFmzzw+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAADXTVtZ/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9qY4EOB41/kXOQU4UsghEshXACgwE/GAECAQEBAQEBAWsdC4U?= =?us-ascii?q?YAQEBAQMtTBACAQgRBAEBLzIdCAEBBA4FCIlDZBCyX4tIAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWDJ4NMhQWDJoEnAQGGDwWQSI48AodFjDSCFYVKikiJNIt9AR8?= =?us-ascii?q?4gQp1FUmHFXYBhnmBI4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,307,1496102400"; d="scan'208,217";a="449270716" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jul 2017 08:16:57 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v648GvAV016297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Jul 2017 08:16:57 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; Tue, 4 Jul 2017 03:16:57 -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, 4 Jul 2017 03:16:56 -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: AdLvFuF61BfO3GWfTWeWh8Gbtd9QpgFhoFWA Date: Tue, 4 Jul 2017 08:16:33 +0000 Deferred-Delivery: Tue, 4 Jul 2017 08:16:26 +0000 Message-ID: References: <621d7e2bfe3541ccbe86b99bedb2cd69@XCH-RCD-001.cisco.com> In-Reply-To: <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.228.216.20] Content-Type: multipart/alternative; boundary="_000_a71dcb7955ae45349fec21311784a30fXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [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, 04 Jul 2017 08:17:01 -0000 --_000_a71dcb7955ae45349fec21311784a30fXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gentle reminder : ) We need to publish the WG agendas for IETF 99 by tomorrow. Please answer this mail today if - you have not done so yet and - you wish = to present in Prague. Cheers; The chairs From: Pascal Thubert (pthubert) Sent: mardi 27 juin 2017 09:31 To: lp-wan@ietf.org Cc: lpwan-chairs@ietf.org Subject: Agenda Items for LPWAN F2F Meeting in Prague 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_a71dcb7955ae45349fec21311784a30fXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gentle reminder := )

 

We need to publish the= WG agendas for IETF 99 by tomorrow.

Please answer this mai= l today if – you have not done so yet and - you wish to present in Pr= ague.

 

Cheers;

 

The chairs<= /span>

 

From: Pascal Thu= bert (pthubert)
Sent: mardi 27 juin 2017 09:31
To: lp-wan@ietf.org
Cc: lpwan-chairs@ietf.org
Subject: Agenda Items for LPWAN F2F Meeting in Prague

 

Dear LPWANers,<= /o:p>

 

The final agenda for= IETF 99 has been published at: https://dat= atracker.ietf.org/meeting/99/agenda.html. Keep this link, it's always u= seful with a number of pointers to meeting needful things. Also consider th= e 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 send a request to the chairs (cc) by Monday Jul= y 3rd. Please note that this is also the deadline for draft subm= ission.

 

Please provide the f= ollowing 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 t= emplate will be provided.

 

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

 

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

 

Looking forward to s= eeing you in all Prague!

 

Ch= eers,

 

Al= exander and Pascal

=  

--_000_a71dcb7955ae45349fec21311784a30fXCHRCD001ciscocom_-- From nobody Tue Jul 4 04:20: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 C7CFD131F11; Tue, 4 Jul 2017 04:20:04 -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, 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] 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 csc-U5E6k7PS; Tue, 4 Jul 2017 04:20:02 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1051A131F0F; Tue, 4 Jul 2017 04:20:02 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 867F8100169; Tue, 4 Jul 2017 13:20:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 623C540074; Tue, 4 Jul 2017 13:20:00 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0352.000; Tue, 4 Jul 2017 13:20:00 +0200 From: To: "Pascal Thubert (pthubert)" , "lp-wan@ietf.org" CC: "lpwan-chairs@ietf.org" Thread-Topic: [lp-wan] Agenda Items for LPWAN F2F Meeting in Prague Thread-Index: AQHS9Ld5c65c20XF7ky2E5aPrWDpFw== Date: Tue, 4 Jul 2017 11:19:59 +0000 Message-ID: <26340_1499167200_595B79E0_26340_30_1_D58145E2.457A7%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.1] Content-Type: multipart/alternative; boundary="_000_D58145E2457A7dominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [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, 04 Jul 2017 11:20:05 -0000 --_000_D58145E2457A7dominiquebarthelorangecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello esteemed chairs, How about a slot to present the results of the SCHC work at the Hackathon? = A 10mn slot would be fine, I think. We won't have a draft by July 3rd nor slides by July 12th, but we can make = them during the week in Prague. Thanks Dominique De : lp-wan > on be= half of Pascal Thubert > Date : Tuesday 4 July 2017 10:16 =C0 : "lp-wan@ietf.org" > Cc : "lpwan-chairs@ietf.org" > Objet : Re: [lp-wan] Agenda Items for LPWAN F2F Meeting in Prague Gentle reminder : ) We need to publish the WG agendas for IETF 99 by tomorrow. Please answer this mail today if =96 you have not done so yet and - you wis= h to present in Prague. Cheers; The chairs From: Pascal Thubert (pthubert) Sent: mardi 27 juin 2017 09:31 To: lp-wan@ietf.org Cc: lpwan-chairs@ietf.org Subject: Agenda Items for LPWAN F2F Meeting in Prague 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 ___________________________________________________________________________= ______________________________________________ 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_D58145E2457A7dominiquebarthelorangecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello esteemed chairs,

How about a slot to present the results of the SCHC work at the Hackat= hon? A 10mn slot would be fine, I think.
We won't have a draft by July 3rd nor slides by July 12th, but we can = make them during the week in Prague.
Thanks

Dominique

De : lp-wan <lp-wan-bounces@ietf.org> on behalf of P= ascal Thubert <pthubert@cisco.com<= /a>>
Date : Tuesday 4 July 2017 10:= 16
=C0 : "lp-wan@ietf.org" <lp-wan@ietf.org>
Cc : "lpwan-chairs@ietf.org" <lpwan-chairs@ietf.org>
Objet : Re: [lp-wan] Agenda It= ems for LPWAN F2F Meeting in Prague

Gentle reminder := )

 

We need to publish the= WG agendas for IETF 99 by tomorrow.

Please answer this mai= l today if =96 you have not done so yet and - you wish to present in Prague= .

 

Cheers;

 

The chairs<= /span>

 

From: Pascal Thu= bert (pthubert)
Sent: mardi 27 juin 2017 09:31
To: lp-wan@ietf.org
Cc: lpwan-chairs@ietf.org
Subject: Agenda Items for LPWAN F2F Meeting in Prague

 

Dear LPWANers,<= /o:p>

 

The final agenda for= IETF 99 has been published at: https://dat= atracker.ietf.org/meeting/99/agenda.html. Keep this link, it's always u= seful with a number of pointers to meeting needful things. Also consider th= e 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 send a request to the chairs (cc) by Monday Jul= y 3rd. Please note that this is also the deadline for draft subm= ission.

 

Please provide the f= ollowing information:

-   &= nbsp;     Draft name

-   &= nbsp;     Presenter name

-   &= nbsp;     Expected duration

-   &= nbsp;     Objective of the discussion

 

We kindly request to= send your slides for presentations by Wednesday, July 12th. A t= emplate will be provided.

 

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

 

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

 

Looking forward to s= eeing you in all Prague!

 

Ch= eers,

 

Al= exander and Pascal

=  

 
______________________________________________________________________=
___________________________________________________

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_D58145E2457A7dominiquebarthelorangecom_-- From nobody Tue Jul 4 04:39:33 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 8D68F131F78 for ; Tue, 4 Jul 2017 04:39:32 -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 EcM0FiTa4vin for ; Tue, 4 Jul 2017 04:39:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CD7131F73 for ; Tue, 4 Jul 2017 04:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7546; q=dns/txt; s=iport; t=1499168370; x=1500377970; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RAftU+5jTif/mCEjwG6KLeV51MIcXRJmjuw4rEJvByk=; b=RKC07sMNIRj+tY7Nzgvye869OcHRZXNt1IucEvMlq+0wodxVEIflqOqD LBqle6Vc4g3hQr2b2HILMqjOf9ANQcWS+mF7FnBph70dsVtbDaL6A9Lzh hMHIjAvAoGJmkSWBpXMphnfxwRYpdF4B4fW9OOW2kZ1TCr3oeBu4JN7R/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAQCNfVtZ/4YNJK1cDgwBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYNZY4EQB4NmihmRdZYAghEhC4VwAhqCbj8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAQEBIREzBwsFBwQCAQYCEQQBAQMCIwMCAgIlCxQBCAgCBAENBQgTiXwDD?= =?us-ascii?q?QgQkj6dY4ImhzUcg3YBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELghyDTIFhgjF?= =?us-ascii?q?zgSSGWYJhBZ8GAosKiHCSJ4QXkRsBHzg/S3UVSYZWP3aIHYENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,307,1496102400"; d="scan'208";a="263882883" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jul 2017 11:39:29 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v64BdT6C013731 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Jul 2017 11:39:29 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, 4 Jul 2017 06:39:28 -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, 4 Jul 2017 06:39:28 -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+wgAGM1QCACzlGoA== Date: Tue, 4 Jul 2017 11:39:12 +0000 Deferred-Delivery: Tue, 4 Jul 2017 11:39:10 +0000 Message-ID: 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: 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.20] 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: Tue, 04 Jul 2017 11:39:32 -0000 V2UgYXJlIGRlZmluaXRlbHkgbm90IGNvbW11bmljYXRpbmcsIEdlbmd5dS4NCg0KSWYgeW91IGVs aWRlIHRoZSBydWxlSUQgYXQgdGhlIGJlZ2lubmluZyBvZiBhIGZyYWdtZW50IGFuZCBzdGFydCB3 aXRoIHRoZSBkdGFnLCB0aGVuIHRoZSBwYXJzZXIgd2lsbCBpbnRlcnByZXQgdGhlIGR0YWcgYXMg YSBydWxlSUQuDQoNCk1heWJlIHlvdSBhcmUgbm90IGNvbnNpZGVyaW5nIHRoYXQgYSBub24tZnJh Z21lbnRlZCBwYWNrZXQgbWF5YmUgaW50ZXJsZWF2ZWQgYmV0d2VlbiBmcmFnbWVudHM/IA0KDQpQ YXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHdlaWdlbmd5dSBbbWFp bHRvOndlaWdlbmd5dUB2aXAuc2luYS5jb21dIA0KU2VudDogbWFyZGkgMjcganVpbiAyMDE3IDA1 OjEyDQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPjsg Q2FybGVzIEdvbWV6IE1vbnRlbmVncm8gPGNhcmxlc2dvQGVudGVsLnVwYy5lZHU+DQpDYzogbHAt d2FuQGlldGYub3JnOyBhcnVuQGFja2wuaW8NClN1YmplY3Q6IFJlOiBbbHAtd2FuXSBGdzogcmUt b3JkZXIgaGVhZGVyIGZpZWxkIHJlcXVlc3QNCg0KDQpIaSBQYXNjYWwsDQoNCj4gV2UgbmVlZCB0 aGUgUnVsZSB0byBzYXkgZnJhZ21lbnQgb24gZWFjaCBmcmFnbWVudCwNCkFsbCBmcmFtZW50cyBv ZiBhIElQdjYgcGFja2V0IG9iZXkgb25lIHJ1bGUsIHRoZSBSdWxlIElEIGlzIGluY2x1ZGVkIGlu IHRoZSBmaXJzdCBmcmFnbWVudCBpcyBlbm91Z2ggZm9yIGNvbnZleWluZyB0aGlzIGluZm9ybWF0 aW9uLg0KDQo+IGFuZCB0aGVuIHRoZSBkdGFnLg0KQWxsIGZyYW1lbnRzIG9mIHRoZSBwYWNrZXQg Y29udGFpbiB0aGUgc2FtZSBEdGFnIGFzIGRlZmluZWQuDQoNCj4gU3RhcnRpbmcgdGhlIG5leHQg ZnJhZ21lbnQgd2l0aCB0aGUgZHRhZyB3b3VsZCBjb25mdXNlIHRoZSBwYXJzZXIgDQo+IHdoaWNo IHdvdWxkIGludGVycHJldCB0aGUgZHRhZyBhcyBhbm90aGVyIHJ1bGUuDQpQdXQgdGhlIER0YWcg YXQgdGhlIGZyb250Lg0KRGVmaW5pbmcgdGhlIGZpcnN0IHR3byBiaXRzIG9mIER0YWcgYXMgYW4g aW5kaWNhdGlvbiBvZiB0aGUgZmlyc3QgZnJhZ21lbnQsIGZyYWdtZW50cyBvZiB0aGUgbWluZGRs ZSBhbmQgIHRoZSBsYXN0IGZyYWdtZW50Lg0KDQowMCB0aGUgZmlyc3QgZnJhZ21lbnQNCjEwIGZy YWdtZW50cyBvZiB0aGUgbWluZGRsZQ0KMTEgdGhlIGxhc3QgZnJhZ21lbnQNCg0KSWYgdGhlIGZp cnN0IHR3byBiaXRzIGFyZSAnMDAnLCB0aGUgUnVsZSBJRCBpcyBmb2xsb3dlZC4NCklmIHRoZSBm aXJzdCB0d28gYml0cyBhcmUgbm90ICcwMCcsIHRoZSBmcmFnbWVudCBkb2VzIG5vdCBjb250YWlu IHRoZSBSdWxlIElELg0KSWYgdGhlIGZpcnN0IHR3byBiaXRzIGFyZSAxMSwgaXQgaXMgdGhlIGxh c3QgZnJhZ21lbnQuDQoNCkkgYmVsaWV2ZSB0aGF0IGl0IGlzIHdvcnRoIHRvIGhhdmUgdGhpcyB0 d28gYml0IHRvIHN1cHByZXNzIHRoZSBzcGFjZSBvZiBSdWxlIElEIGluIHRoZSBzdWNjZXNzaXZl IGZyYWdtZW50cy4NCg0KUmVnYXJkcywNCg0KR2VuZ3l1IFdFSQ0KTmV0d29yayBUZWNobm9sb2d5 IENlbnRlcg0KU2Nob29sIG9mIENvbXB1dGVyDQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMg YW5kIFRlbGVjb21tdW5pY2F0aW9ucw0KLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQ0KRnJvbTogUGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KU2VudDogTW9uZGF5LCBKdW5lIDI2LCAyMDE3IDQ6MzMg UE0NClRvOiB3ZWlnZW5neXUgOyBDYXJsZXMgR29tZXogTW9udGVuZWdybw0KQ2M6IGxwLXdhbkBp ZXRmLm9yZyA7IGFydW5AYWNrbC5pbw0KU3ViamVjdDogUmU6IFtscC13YW5dIEZ3OiByZS1vcmRl ciBoZWFkZXIgZmllbGQgcmVxdWVzdA0KDQpIZWxsbyBHZW5neXUNCg0KV2UgbmVlZCB0aGUgUnVs ZSB0byBzYXkgZnJhZ21lbnQgb24gZWFjaCBmcmFnbWVudCwgYW5kIHRoZW4gdGhlIGR0YWcuIA0K U3RhcnRpbmcgdGhlIG5leHQgZnJhZ21lbnQgd2l0aCB0aGUgZHRhZyB3b3VsZCBjb25mdXNlIHRo ZSBwYXJzZXIgd2hpY2ggd291bGQgaW50ZXJwcmV0IHRoZSBkdGFnIGFzIGFub3RoZXIgcnVsZS4N Cg0KQ2hlZXJzLA0KDQpQYXNjYWwNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBs cC13YW4gW21haWx0bzpscC13YW4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHdlaWdl bmd5dQ0KU2VudDogdmVuZHJlZGkgMjMganVpbiAyMDE3IDE2OjI2DQpUbzogQ2FybGVzIEdvbWV6 IE1vbnRlbmVncm8gPGNhcmxlc2dvQGVudGVsLnVwYy5lZHU+DQpDYzogbHAtd2FuQGlldGYub3Jn OyBhcnVuQGFja2wuaW8NClN1YmplY3Q6IFJlOiBbbHAtd2FuXSBGdzogcmUtb3JkZXIgaGVhZGVy IGZpZWxkIHJlcXVlc3QNCg0KDQpIaSwNCg0KPiBJIHRoaW5rIHRoZXJlIGFyZSBwcm9ibGVtcyB3 aXRoIHRoaXMgcHJvcG9zYWwuIElmIHRoZSBSdWxlIElEIG9mIA0KPiBzdWNjZXNzaXZlIGZyYWdt ZW50cyBpcyBzdXBwcmVzc2VkLCBob3cgZG9lcyBhIHJlY2VpdmVyIGtub3cgd2hldGhlciANCj4g dGhvc2Ugc3VjY2Vzc2l2ZSBkYXRhIHVuaXRzIGFyZSBhY3R1YWwgZnJhZ21lbnRzIG9yIG5vdCwg b3IgaG93IHRoZSANCj4gZGF0YSB1bml0IGhhcyB0byBiZSBwcm9jZXNzZWQ/DQoNClRoZSBEdGFn IGNhbiBiZSB1c2VkIGZvciBrbm93aW5nICJ3aGV0aGVyIHRob3NlIHN1Y2Nlc3NpdmUgZGF0YSB1 bml0cyBhcmUgYWN0dWFsIGZyYWdtZW50cyBvciBub3QsIG9yIGhvdyB0aGUgZGF0YSB1bml0IGhh cyB0byBiZSBwcm9jZXNzZWQuICINCg0KRm9yIGV4YW1wbGUsIGlmIGFuIElQdjYgcGFja2V0IGlz IHBhcnRpdGlvbmVkIGludG8gdHdvIGZyYWdtZW50cywgdGhlIGZpcnN0IGZyYWdtZW50IGluY2x1 ZXMgYSBSdWxlIElEIGFuZCBhIER0YWcsIHRoZSBzZWNvbmQgZnJhZ21lbnQgaW5jbHVkZXMgdGhl IER0YWcgd2l0aG91dCB0aGUgUnVsZSBJRC4NCg0KQWZ0ZXIgdGhlIGZpcnN0IGZyYWdtZW50IGlz IHNlbnQsIHRoZSBSdWxlIElEIGlzIGJpbmRlZCB3aXRoIGEgRHRhZyBmb3IgdGhpcyBwYWNrZXQu DQpUaGUgcmVjZWl2ZXIgY2FuIGtub3cgd2hpY2ggdGhlIFJ1bGUgSUQgaXMgdXNlZCBieSB0aGUg RHRhZy4NCg0KDQpSZWdhcmRzLA0KDQpHZW5neXUgV0VJDQpOZXR3b3JrIFRlY2hub2xvZ3kgQ2Vu dGVyDQpTY2hvb2wgb2YgQ29tcHV0ZXINCkJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQg VGVsZWNvbW11bmljYXRpb25zDQotLS0tLeWOn+Wni+mCruS7ti0tLS0tIA0KRnJvbTogQ2FybGVz IEdvbWV6IE1vbnRlbmVncm8NClNlbnQ6IEZyaWRheSwgSnVuZSAyMywgMjAxNyA2OjQ3IFBNDQpU bzogd2VpZ2VuZ3l1DQpDYzogYXJ1bkBhY2tsLmlvIDsgbHAtd2FuQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2xwLXdhbl0gRnc6IHJlLW9yZGVyIGhlYWRlciBmaWVsZCByZXF1ZXN0DQoNCg0KSGks DQoNCj4gSGkgQXJ1biBhbmQgYWxsLA0KPg0KPiBBZnRlciByZWFkaW5nIHRocm91Z2ggdGhlIGRy YWZ0LWlldGYtbHB3YW4taXB2Ni1zdGF0aWMtY29udGV4dC1oYy0wNCwNCj4gb25lIHBvaW50IG5l ZWRzIHRvIGJlIGV4aXBsaWNpdCBkZXNjcmliZWQ6IGhvdyBtYW55IFJ1bGUgSURzIGFyZSB1c2Vk IHRvDQo+IGZyYWdtZW50IG9uZSBsYXJnZSBJUHY2IHBhY2tldD8NCg0KV2hhdCB3ZSBjdXJyZW50 bHkgaGF2ZSBpbiB0aGUgZG9jdW1lbnQgaXM6DQoNCiAgICJUaGUgUnVsZSBJRCBpbiBhIGZyYWdt ZW50IGlzIHNldCB0byBhIHZhbHVlIHRoYXQgaW5kaWNhdGVzIHRoYXQgdGhlIGRhdGENCiAgIHVu aXQgYmVpbmcgY2FycmllZCBpcyBhIGZyYWdtZW50LiINCg0KU28gY3VycmVudGx5IHdlIGRvIG5v dCBleHBsaWNpdGx5IGluZGljYXRlIGhvdyBtYW55IFJ1bGUgSURzIGFyZSBuZWVkZWQNCmZvciBm cmFnbWVudHMgb2YgYSBsYXJnZSBJUHY2IHBhY2tldC4gVGhlIG1vc3QgZWZmaWNpZW50IHNvbHV0 aW9uIGlzIHRvDQpqdXN0IHVzZSBvbmUgUnVsZSBJRCB0byBzaWduYWwgInRoaXMgaXMgYSBmcmFn bWVudCIuIEhvd2V2ZXIsIGl0IGlzDQpwcm9iYWJseSBzYWZlIHRvIGtlZXAgdGhpcyBvcGVuIGlu IHRoZSBTQ0hDIGRvY3VtZW50LCBzbyB0aGF0IGZ1dHVyZQ0KdGVjaG5vbG9neS1zcGVjaWZpYyBT Q0hDIG92ZXIgZm9vIGRvY3VtZW50cyBoYXZlIGZyZWVkb20gdG8gc3BlY2lmeQ0Kd2hhdGV2ZXIg YmV0dGVyIHN1aXRzIHRoZWlyIG5lZWRzLg0KDQo+IEJ5IG15IHVuZGVyc3RhbmRpbmcsIHdobmUg b25lIElQdjYgcGFja2V0IGlzIGZyYWdtZW50ZWQsIGl0IGFkb3B0cyBvbmx5DQo+IG9uZSBSdWxl IElELg0KPiBFYWNoIGZyYWdtZW50IGNvbnRhaW5zIHRoZSBzYW1lIHJ1bGUgSUQgYW5kIER0YWcu DQo+IEFueXRoaW5nIHdyb25nPw0KDQpEVGFnIChpZiBwcmVzZW50KSBoYXMgdG8gYmUgdGhlIHNh bWUgaW4gYWxsIGZyYWdtZW50cyBjYXJyeWluZyB0aGUgc2FtZQ0KSVB2NiBwYWNrZXQuDQoNCk9u ZSBSdWxlIElEIHRvIHNpZ25hbCAndGhpcyBpcyBhIGZyYWdtZW50JyBpcyBmaW5lLg0KDQo+IFN1 Y2ggYSB3YXkgdG8gZGVsaXZlciB0aGUgcmVwZWF0ZWQgUnVsZSBJRCBjYW4gYmUgc3VwcHJlc3Nl ZC4NCj4gSXQgbWF5IGJlIGF2YWlsYWJsZSB0byBoYXZlIHRoZSBmaXJzdCBmcmFnZW1lbnQgb25s eSBpbmNsdWRlIHRoZSBSdWxlIElEDQo+IHdoaWxlIGNvbnRhaW5pbmcgdGhlIER0YWcuDQo+IEFu ZCB0aGUgZm9sbG93aW5nIHN1Y2Nlc3NpdmUgZnJhZ21lbnRzIGhhdmUgdGhlIER0YWdlIHdpdGhv dXQgdGhlIFJ1bGUgSUQuDQo+IFRoZSByZWNlaXZlciBjYW4gZ2V0IHRoZSBjb3JyZWN0IFJ1bGUg SUQgZnJvbSB0aGUgZmlyc3QgZnJhZ21lbnQgcmVmZXJyZWQNCj4gYXMgdGhlIHNhbWUgRHRhZy4N Cj4NCj4gVGhlIFJ1bGUgSUQgaXMgc3VwcHJlc3NlZCBpbiBmcmFnbWVudHMgZnJvbSB0aGUgc2Vj b25kIHRvIHRoZSBsYXN0Lg0KDQpJIHRoaW5rIHRoZXJlIGFyZSBwcm9ibGVtcyB3aXRoIHRoaXMg cHJvcG9zYWwuIElmIHRoZSBSdWxlIElEIG9mDQpzdWNjZXNzaXZlIGZyYWdtZW50cyBpcyBzdXBw cmVzc2VkLCBob3cgZG9lcyBhIHJlY2VpdmVyIGtub3cgd2hldGhlciB0aG9zZQ0Kc3VjY2Vzc2l2 ZSBkYXRhIHVuaXRzIGFyZSBhY3R1YWwgZnJhZ21lbnRzIG9yIG5vdCwgb3IgaG93IHRoZSBkYXRh IHVuaXQNCmhhcyB0byBiZSBwcm9jZXNzZWQ/DQoNClRoYW5rcywNCg0KQ2FybGVzDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbHAtd2FuIG1h aWxpbmcgbGlzdA0KbHAtd2FuQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xwLXdhbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCmxwLXdhbiBtYWlsaW5nIGxpc3QNCmxwLXdhbkBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13YW4gDQoNCg0K From nobody Wed Jul 5 01:40: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 9E1BD131B7E; Wed, 5 Jul 2017 01:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 HSS8VooAPqQJ; Wed, 5 Jul 2017 01:40:01 -0700 (PDT) Received: from smtp1.enst.fr (smtp1.enst.fr [IPv6:2001:660:330f:2::8a]) by ietfa.amsl.com (Postfix) with ESMTP id 96852131B7B; Wed, 5 Jul 2017 01:40:00 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.2.193]) by smtp1.enst.fr (Postfix) with ESMTP id 73E38216DA; Wed, 5 Jul 2017 10:39:53 +0200 (CEST) Authentication-Results: smtp1.enst.fr; dkim=pass reason="1024-bit key; unprotected key" header.d=imt-atlantique.fr header.i=@imt-atlantique.fr header.b=kAh9Nvqx; dkim-adsp=pass; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 55725100593; Wed, 5 Jul 2017 10:39:53 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id nrMYZNDjg9E7; Wed, 5 Jul 2017 10:39:52 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 99988100588; Wed, 5 Jul 2017 10:39:52 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy120.enst.fr 99988100588 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1499243992; bh=im+FXTeec7XuQpoMIKHZFVBnTEU40MY9c+xF4OF9JWA=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=kAh9NvqxsV458A25LKt/vAcyFuOQOuAwXJFmp8Y8HuF14pL3URiAsmKrUNaj0xrEA 6gRHX09NFlK3OtmZSA1tnIu+Daiz+HoM6ZVfY8OVbA0wUFl73jIE+Yj2LR5bGx8BL0 tdD3krZFVBUvt4/3b7yiqBf1vKOFqA/Ihwn7lvSs= 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 5GDxVvE4Dj-e; Wed, 5 Jul 2017 10:39:52 +0200 (CEST) Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 39305100593; Wed, 5 Jul 2017 10:39:52 +0200 (CEST) Received: by mail-vk0-f54.google.com with SMTP id 191so120844345vko.2; Wed, 05 Jul 2017 01:39:52 -0700 (PDT) X-Gm-Message-State: AKS2vOxi9T4f+71d6gvMIKHHRjljj6OwIrW+rvk+pRbkLmQP0cBMMhKh gmzLG3iW0swwPZxiTv7+SafE5OXp3w== X-Received: by 10.31.180.80 with SMTP id d77mr23296752vkf.110.1499243990858; Wed, 05 Jul 2017 01:39:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.61.13 with HTTP; Wed, 5 Jul 2017 01:39:10 -0700 (PDT) In-Reply-To: <26340_1499167200_595B79E0_26340_30_1_D58145E2.457A7%dominique.barthel@orange.com> References: <26340_1499167200_595B79E0_26340_30_1_D58145E2.457A7%dominique.barthel@orange.com> From: Laurent Toutain Date: Wed, 5 Jul 2017 10:39:10 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "lpwan-chairs@ietf.org" Cc: "Pascal Thubert (pthubert)" , "lp-wan@ietf.org" Content-Type: multipart/alternative; boundary="001a1143811081c1c105538df1d5" Archived-At: Subject: Re: [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: Wed, 05 Jul 2017 08:40:05 -0000 --001a1143811081c1c105538df1d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear chairs, I would like to have the opportunity to talk on CoAP compression rules for 15 min Laurent On Tue, Jul 4, 2017 at 1:19 PM, wrote: > Hello esteemed chairs, > > How about a slot to present the results of the SCHC work at the Hackathon= ? > A 10mn slot would be fine, I think. > We won't have a draft by July 3rd nor slides by July 12th, but we can mak= e > them during the week in Prague. > Thanks > > Dominique > > De : lp-wan on behalf of Pascal Thubert < > pthubert@cisco.com> > Date : Tuesday 4 July 2017 10:16 > =C3=80 : "lp-wan@ietf.org" > Cc : "lpwan-chairs@ietf.org" > Objet : Re: [lp-wan] Agenda Items for LPWAN F2F Meeting in Prague > > Gentle reminder : ) > > > > We need to publish the WG agendas for IETF 99 by tomorrow. > > Please answer this mail today if =E2=80=93 you have not done so yet and -= you wish > to present in Prague. > > > > Cheers; > > > > The chairs > > > > *From:* Pascal Thubert (pthubert) > *Sent:* mardi 27 juin 2017 09:31 > *To:* lp-wan@ietf.org > *Cc:* lpwan-chairs@ietf.org > *Subject:* Agenda Items for LPWAN F2F Meeting in Prague > > > > Dear LPWANers, > > > > The final agenda for IETF 99 has been published at: > 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 send 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 presentations by Wednesday, Jul= y > 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 taking notes and jabber, > please do volunteer! > > > > Looking forward to seeing you in all Prague! > > > > Cheers, > > > > Alexander and Pascal > > > > _________________________________________________________________________= ________________________________________________ > > 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 > > --001a1143811081c1c105538df1d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear chairs,

I would like to have t= he opportunity to talk on CoAP compression rules for 15 min

La= urent

On= Tue, Jul 4, 2017 at 1:19 PM, <dominique.barthel@orange.com> wrote:
Hello esteemed chairs,

How about a slot to present the results of the SCHC work at the Hackat= hon? A 10mn slot would be fine, I think.
We won't have a draft by July 3rd nor slides by July 12th, but we = can make them during the week in Prague.
Thanks

Dominique

De=C2=A0: lp-wan <lp-wan-bounces@ietf.org&= gt; on behalf of Pascal Thubert <pthubert@cisco.com>
Date=C2=A0: Tuesday 4 July 2017 10:= 16
=C3=80=C2=A0: "lp-wan@ietf.org" <lp-wan@ietf.org>
Cc=C2=A0: "lpwan-chairs@ietf.org" <= ;lpwan-chairs@ie= tf.org>
Objet=C2=A0: Re: [lp-wan] Agenda It= ems for LPWAN F2F Meeting in Prague

Gentle reminder=C2=A0:= )

=C2=A0

We need to publish the= WG agendas for IETF 99 by tomorrow.

Please answer this mai= l today if =E2=80=93 you have not done so yet and - you wish to present in = Prague.

=C2=A0

Cheers;<= /span>

=C2=A0

The chairs

=C2=A0

From: Pascal Thu= bert (pthubert)
Sent: mardi 27 juin 2017 09:31
To: lp-wan@ietf= .org
Cc: lpwan= -chairs@ietf.org
Subject: Agenda Items for LPWAN F2F Meeting in Prague<= /p>

=C2=A0

= Dear LPWANers,

= =C2=A0

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

= =C2=A0

= 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.

= =C2=A0

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

= =C2=A0

= Please provide the following information:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Draft name

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Presenter name

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Expected duration

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Objective of the discussion

= =C2=A0

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

= =C2=A0

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

= =C2=A0

= As always - we would appreciate your help in taking notes and jabber, pleas= e do volunteer!

= =C2=A0

= Looking forward to seeing you in all Prague!

= =C2=A0

= Cheers,

= =C2=A0

= Alexander and Pascal

=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

--001a1143811081c1c105538df1d5-- From nobody Wed Jul 5 02:11: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 58D8B131C16 for ; Wed, 5 Jul 2017 02:11:36 -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, FREEMAIL_FROM=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_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 2z1HJ0CDd1vk for ; Wed, 5 Jul 2017 02:11:33 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D60131B18 for ; Wed, 5 Jul 2017 02:11:33 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 83FE560614 for ; Wed, 5 Jul 2017 11:11:31 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 669F8C0069 for ; Wed, 5 Jul 2017 11:11:31 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0352.000; Wed, 5 Jul 2017 11:11:31 +0200 From: To: "lp-wan@ietf.org" Thread-Topic: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.txt Thread-Index: AQHS9W6wCRlBhTGDw0mH0i2C57Dn2g== Date: Wed, 5 Jul 2017 09:11:30 +0000 Message-ID: <18126_1499245891_595CAD43_18126_64_1_D58186B6.457FB%dominique.barthel@orange.com> References: <149892867732.532.13514525150008761783@ietfa.amsl.com> In-Reply-To: <149892867732.532.13514525150008761783@ietfa.amsl.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.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.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: Wed, 05 Jul 2017 09:11:36 -0000 Hello all, I have reviewed the "Fragmentation" part (Section 9, Appendices A and B) of this draft and I have the following comments. "highest CFN in the window" This notion is introduced in 9.5.2, in the subsection that describes the CFN field. At this point in the text, it is not clear who picks the value of "highest CFN in the window", if it is a constant or how it is conveyed to the receiver if it is variable. Only when reading section 9.7 does one understand that it is a constant that is known as part of the context and that multiple values may be supported by ways of different rule Ids. However, "highest CFN in the window" is not listed at the bottom of 9.5.2 along with R, N, T and M that are constants to be defined in other documents. I think "highest CFN in the window" deserves a short name and a notation, and it should be listed along with R, N, T and M at the bottom of 9.5.2. The explanation at the bottom of 9.5.3 as to why one could want a "highest CFN in the window" value that is not CFN=3D2^N-2 (56 bits in the example) is very useful. Furthermore, I think that it would be advantageous that, in the examples, at least one example use a "highest CFN in the window" value that is not CFN=3D2^N-2. Correction : in Section 9.6, replace OLD TEXT "Note that, in Window mode, the first fragment of the window is the one with CFN=3D2^N-2." NEW TEXT "Note that, in Window mode, the first fragment of the window is the one with "highest CFN in the window"". Section 9.6, Baseline mechanism, description of reassembly buffer "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 order to place fragment at the appropriate location in the reassembly buffer, how does one know the size of preceding fragments that have been lost? Are fragments supposed to be all of the same size? Does a specific rule Id mandate a fragment size? Is this behaviour to be specified in "other documents"? "It uses the CFN and the order of arrival of each fragment to determine the location" Maybe an explanation of why the CFN *and* the order or arrival? I guess you are referring to the No ACK mode where CFN is constant but for the last fragment? Do we agree that in Window mode, CFN and W unambiguously determine location in the reassembly buffer? Section 9.6, Baseline mechanism, description of Window mode - ACK on error "Upon expiration of the "ACK on Error Timer", if the receiver knows that at least one fragment of the current window has been lost =8A=B2 If the "ACK on Error Timer" expires at the receiver, then it knows that at least the last fragment is assumed to have been lost, correct? Therefore, the "if the receiver knows that at least one fragment of the current window has been lost" clause is irrelevant and can be removed from the text. The description of =B3Window mode - ACK on error=B2 does not mention MAX_FRAG_RETRIES. My understanding of =B3Window mode - Ack on error=B2 is t= hat it would benefit from the same MAX_FRAG_RETRIES mechanism. In =B3Window mode - ACK on error=B2, the ACK cannot be used for flow contro= l. The draft does not provide recommendations on when a sender can forget about a window that it has sent, and reallocate the window number (1 bit) to a new window. Nor does it provide recommendation about forgetting about the last window of an IPv6 packet. See for example Figures 17 and 18 in Appendix A. I=B9m assuming that a sender implementation would want to wait for a reasonable time before forgetting about a window, just in case an ACK on error would be received shortly. Should this be described here? Section 9.6, Baseline mechanism, description of MIC processing at the end of reassembly =B3In 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.=B2 The following sentences state that in either Window mode, the ACK conveys information about fragments of the last window that have been correctly received or not received. (Incidentally, these sentences are redundant with the same text in the third and fifth paragraphs of the same section 9.6. Do we need both?) Nothing is said about what to do, in Window mode, when the MIC does not match. For completeness, I suggest we write that the reassembled IPv6 datagram MUST be discarded, and simply state that an ACK is sent with the same behaviour than for any other window. Appendix B, allocation of Rule IDs for fragmentation I suggest to modify the section title to =B3Allocation of Rule IDs for fragmentation=B2. This section should be rewritten. I suggest: =B3A set of Rule IDs are allocated to support different aspects of fragmentation functionality as per this document. The allocation of IDs is to be defined in other documents. The set MAY include: o one ID or a subset of IDs to identify a fragment as well as its reliability option and its window size, if multiple of these are supported o one ID to identify the ACK message. o one ID to identify the Abort message as per Section 9.8.=B2 Do we agree with the =B3one ID=B2 in the last two items, or are there use cases that I don=B9t see that would justify for multiple IDs ? Various nits * Section 3, Terminology. CFN is not listed. Also add the other acronyms (DTag, MIC, etc.) used in the fragmentation section. * Section 9.2: MAX_FRAG_RETRIES is described for the Window mode - ACK =B3always=B2. For completeness, the same text should be repeated for the Window mode - ACK on error. * Section 9.4: Rule ID description. Add the use of Rule ID for conveying the window size if multiple sizes are supported. OLD TEXT =B3Rule ID may also be used to signal which reliability option is in use for the IPv6 packet being carried.=B2 NEW TEXT =B3Rule ID may also be used to signal which reliability option is in use for the IPv6 packet being carried. Rule ID may also be used to signal the window size if multiple sizes are supported (see 9.7).=B2 * Section 9.4: =B3Compressed Fragment Number=B2. =B3Compressed=B2 refers to= the number, not to the fragment, since uncompressed packet can also be fragmented with this mechanism. To remove this ambiguity, rename CFN to Fragment Compressed Number (FCN)?=20 CFN/FCN should be listed in the Terminology section. The part of the sentence =B3, and does not necessarily carry an absolute fragment number.=B2 should be rewritten as =B3, and does not carry an absol= ute fragment number.=B2. Indeed, CFN counts down from "highest CFN in the window" anyway, so the chances that it corresponds to an absolute fragment number are null. See as well my comment on text regarding CFN in 9.5.2 * Section 9.5.2: Remove =B3, and thus the CFN does not strictly correspond to the N least significant bits of the actual absolute fragment number.=B2. It does not strictly correspond, nor loosely. * Section 9.5.3: =B2Absence of the bitmap in an ACK confirms correct reception of all fragments to be acknowledged by means of the ACK." For the wondering soul, maybe explain that the absence is noticed by looking at the L2 size, since it doesn't immediately show from Figure 13. * Section 9.6: "if no ACK has been received since the timer start, the sender retransmits the last fragment sent =8A". Could refer to the last in time or the last in order. I guess the correct answer is the latter, i.e. the last fragment of the IPv6 packet. * Section 9.6: =B3Similarly, when a node first receives =8A =B3. =B3node=B2= is not part of the terminology. Do you mean a Device, or either end of the LPWAN link ? * Section 9.8, fragm/reassbly abortion OLD TEXT =B3The 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.=B2 NEW TEXT =B3The entity (either the fragment sender or the fragment receiver) that triggers abortion transmits to the other endpoint a packet that only comprises a unique Rule ID (of size R bits), which signals abortion of all on-going fragmented IPv6 packet transmissions.=B2 * Section 10.2, security considerations for fragmentation =B3If 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.=B2 This is true of all LPWAN technologies. For example, LoRaWAN has source authentication that allows a receiver distinguishing a random-payload spoofed fragment from a legitimate one. Il also has a frame counter mechanism that allows a receiver to discard later replay by an attacker of a strictly identical message as send earlier by a legitimate node. Therefore, the attack described here and its mitigation only applies to certain LPWAN technologies. * Appendix A: =B3Note: in Window mode, an additional bit will be needed to number windows.=B2. This comment is correct, but it is oddly placed in the middle of the description of Figure 19 as if it didn=B9t apply to the =B3ACK on error=B2 mode as well. Best regards, Dominique Le 01/07/17 19:04, =AB lp-wan on behalf of internet-drafts@ietf.org =BB a =E9crit : > >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-05.txt > Pages : 37 > Date : 2017-07-01 > >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 > these kind of networks. A common context stored in a LPWAN device > and in the network is used. This context keeps 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 mechanisms will not be enough to send the compressed > packet in one L2 PDU, so the SCHC Fragmentation protocol must be used > when needed. > > This document describes SCHC compression/decompression mechanism > framework and applies it to IPv6/UDP headers. Similar solutions for > other protocols such as CoAP will be described in separate documents. > Moreover, this document specifies fragmentation and reassembly > mechanim for SCHC compressed packets exceeding the L2 PDU size and > for the case where the SCHC compression is not possible then the > 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-05 >https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-ipv6-static-context >-hc-05 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lpwan-ipv6-static-context-h= c- >05 > > >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/ > >_______________________________________________ >lp-wan mailing list >lp-wan@ietf.org >https://www.ietf.org/mailman/listinfo/lp-wan ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Jul 5 02:25: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 C153E131CC4 for ; Wed, 5 Jul 2017 02:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oidVJhHKrcEb for ; Wed, 5 Jul 2017 02:25:01 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F1D131C9C for ; Wed, 5 Jul 2017 02:25:01 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id BF411C0636 for ; Wed, 5 Jul 2017 11:24:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 995571A005C for ; Wed, 5 Jul 2017 11:24:59 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0352.000; Wed, 5 Jul 2017 11:24:59 +0200 From: To: "lp-wan@ietf.org" Thread-Topic: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.txt Thread-Index: AQHS9W6wCRlBhTGDw0mH0i2C57Dn2qJE9kYA Date: Wed, 5 Jul 2017 09:24:59 +0000 Message-ID: <11933_1499246699_595CB06B_11933_348_1_D5827C90.459A4%dominique.barthel@orange.com> References: <149892867732.532.13514525150008761783@ietfa.amsl.com> <18126_1499245891_595CAD43_18126_64_1_D58186B6.457FB%dominique.barthel@orange.com> In-Reply-To: <18126_1499245891_595CAD43_18126_64_1_D58186B6.457FB%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.1] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.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: Wed, 05 Jul 2017 09:25:05 -0000 U29ycnkgYWJvdXQgYSB0eXBvIGluIG15IGNvbW1lbnRzDQoNCiogU2VjdGlvbiAxMC4yLCBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgZnJhZ21lbnRhdGlvbg0KPDw8c25pcD4+DQo+IFRoaXMg aXMgdHJ1ZSBvZiBhbGwgTFBXQU4gdGVjaG5vbG9naWVzLg0KSSBtZWFudCA6IFRoaXMgaXMgKm5v dCogdHJ1ZSBvZiBhbGwgTFBXQU4gdGVjaG5vbG9naWVzLg0KDQoNCkRvbWluaXF1ZQ0KDQpMZSAw NS8wNy8xNyAxMToxMSwgwqsgbHAtd2FuIG9uIGJlaGFsZiBvZiBkb21pbmlxdWUuYmFydGhlbEBv cmFuZ2UuY29tIMK7DQo8bHAtd2FuLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGRvbWlu aXF1ZS5iYXJ0aGVsQG9yYW5nZS5jb20+IGENCsOpY3JpdCA6DQoNCj5IZWxsbyBhbGwsDQo+DQo+ SSBoYXZlIHJldmlld2VkIHRoZSAiRnJhZ21lbnRhdGlvbiIgcGFydCAoU2VjdGlvbiA5LCBBcHBl bmRpY2VzIEEgYW5kIEIpDQo+b2YgdGhpcyBkcmFmdCBhbmQgSSBoYXZlIHRoZSBmb2xsb3dpbmcg Y29tbWVudHMuDQo+DQo+ImhpZ2hlc3QgQ0ZOIGluIHRoZSB3aW5kb3ciDQo+ICBUaGlzIG5vdGlv biBpcyBpbnRyb2R1Y2VkIGluIDkuNS4yLCBpbiB0aGUgc3Vic2VjdGlvbiB0aGF0IGRlc2NyaWJl cyB0aGUNCj5DRk4gZmllbGQuDQo+ICBBdCB0aGlzIHBvaW50IGluIHRoZSB0ZXh0LCBpdCBpcyBu b3QgY2xlYXIgd2hvIHBpY2tzIHRoZSB2YWx1ZSBvZg0KPiJoaWdoZXN0IENGTiBpbiB0aGUgd2lu ZG93IiwgaWYgaXQgaXMgYSBjb25zdGFudCBvciBob3cgaXQgaXMgY29udmV5ZWQgdG8NCj50aGUg cmVjZWl2ZXIgaWYgaXQgaXMgdmFyaWFibGUuDQo+ICBPbmx5IHdoZW4gcmVhZGluZyBzZWN0aW9u IDkuNyBkb2VzIG9uZSB1bmRlcnN0YW5kIHRoYXQgaXQgaXMgYSBjb25zdGFudA0KPnRoYXQgaXMg a25vd24gYXMgcGFydCBvZiB0aGUgY29udGV4dCBhbmQgdGhhdCBtdWx0aXBsZSB2YWx1ZXMgbWF5 IGJlDQo+c3VwcG9ydGVkIGJ5IHdheXMgb2YgZGlmZmVyZW50IHJ1bGUgSWRzLg0KPiAgSG93ZXZl ciwgImhpZ2hlc3QgQ0ZOIGluIHRoZSB3aW5kb3ciIGlzIG5vdCBsaXN0ZWQgYXQgdGhlIGJvdHRv bSBvZg0KPjkuNS4yIGFsb25nIHdpdGggUiwgTiwgVCBhbmQgTSB0aGF0IGFyZSBjb25zdGFudHMg dG8gYmUgZGVmaW5lZCBpbiBvdGhlcg0KPmRvY3VtZW50cy4NCj4gIEkgdGhpbmsgImhpZ2hlc3Qg Q0ZOIGluIHRoZSB3aW5kb3ciIGRlc2VydmVzIGEgc2hvcnQgbmFtZSBhbmQgYQ0KPm5vdGF0aW9u LCBhbmQgaXQgc2hvdWxkIGJlIGxpc3RlZCBhbG9uZyB3aXRoIFIsIE4sIFQgYW5kIE0gYXQgdGhl IGJvdHRvbQ0KPm9mIDkuNS4yLg0KPiAgVGhlIGV4cGxhbmF0aW9uIGF0IHRoZSBib3R0b20gb2Yg OS41LjMgYXMgdG8gd2h5IG9uZSBjb3VsZCB3YW50IGENCj4iaGlnaGVzdCBDRk4gaW4gdGhlIHdp bmRvdyIgdmFsdWUgdGhhdCBpcyBub3QgQ0ZOPTJeTi0yICg1NiBiaXRzIGluIHRoZQ0KPmV4YW1w bGUpIGlzIHZlcnkgdXNlZnVsLg0KPiAgRnVydGhlcm1vcmUsIEkgdGhpbmsgdGhhdCBpdCB3b3Vs ZCBiZSBhZHZhbnRhZ2VvdXMgdGhhdCwgaW4gdGhlDQo+ZXhhbXBsZXMsIGF0IGxlYXN0IG9uZSBl eGFtcGxlIHVzZSBhICJoaWdoZXN0IENGTiBpbiB0aGUgd2luZG93IiB2YWx1ZQ0KPnRoYXQgaXMg bm90IENGTj0yXk4tMi4NCj4gIENvcnJlY3Rpb24gOiBpbiBTZWN0aW9uIDkuNiwgcmVwbGFjZQ0K PiAgT0xEIFRFWFQNCj4gICAgIk5vdGUgdGhhdCwgaW4gV2luZG93IG1vZGUsIHRoZSBmaXJzdCBm cmFnbWVudCBvZiB0aGUgd2luZG93IGlzIHRoZQ0KPm9uZSB3aXRoIENGTj0yXk4tMi4iDQo+ICBO RVcgVEVYVA0KPiAgICJOb3RlIHRoYXQsIGluIFdpbmRvdyBtb2RlLCB0aGUgZmlyc3QgZnJhZ21l bnQgb2YgdGhlIHdpbmRvdyBpcyB0aGUgb25lDQo+d2l0aCAiaGlnaGVzdCBDRk4gaW4gdGhlIHdp bmRvdyIiLg0KPg0KPlNlY3Rpb24gOS42LCBCYXNlbGluZSBtZWNoYW5pc20sIGRlc2NyaXB0aW9u IG9mIHJlYXNzZW1ibHkgYnVmZmVyDQo+IkZvciBleGFtcGxlLCBpdCBtYXkgcGxhY2UgdGhlIGRh dGEgcGF5bG9hZCBvZiB0aGUgZnJhZ21lbnRzIHdpdGhpbiBhDQo+cGF5bG9hZCBkYXRhZ3JhbSBy ZWFzc2VtYmx5IGJ1ZmZlciBhdCB0aGUgbG9jYXRpb24gZGV0ZXJtaW5lZCBmcm9tIHRoZSBDRk4N Cj5hbmQgb3JkZXIgb2YgYXJyaXZhbCBvZiB0aGUgZnJhZ21lbnRzLCBhbmQgdGhlIGZyYWdtZW50 IHBheWxvYWQgc2l6ZXMuIg0KPiAgSW4gb3JkZXIgdG8gcGxhY2UgZnJhZ21lbnQgYXQgdGhlIGFw cHJvcHJpYXRlIGxvY2F0aW9uIGluIHRoZSByZWFzc2VtYmx5DQo+YnVmZmVyLCBob3cgZG9lcyBv bmUga25vdyB0aGUgc2l6ZSBvZiBwcmVjZWRpbmcgZnJhZ21lbnRzIHRoYXQgaGF2ZSBiZWVuDQo+ bG9zdD8gQXJlIGZyYWdtZW50cyBzdXBwb3NlZCB0byBiZSBhbGwgb2YgdGhlIHNhbWUgc2l6ZT8N Cj4gIERvZXMgYSBzcGVjaWZpYyBydWxlIElkIG1hbmRhdGUgYSBmcmFnbWVudCBzaXplPyBJcyB0 aGlzIGJlaGF2aW91ciB0byBiZQ0KPnNwZWNpZmllZCBpbiAib3RoZXIgZG9jdW1lbnRzIj8NCj4i SXQgdXNlcyB0aGUgQ0ZOIGFuZCB0aGUgb3JkZXIgb2YgYXJyaXZhbCBvZiBlYWNoIGZyYWdtZW50 IHRvIGRldGVybWluZQ0KPnRoZSBsb2NhdGlvbiINCj4gIE1heWJlIGFuIGV4cGxhbmF0aW9uIG9m IHdoeSB0aGUgQ0ZOICphbmQqIHRoZSBvcmRlciBvciBhcnJpdmFsPyBJIGd1ZXNzDQo+eW91IGFy ZSByZWZlcnJpbmcgdG8gdGhlIE5vIEFDSyBtb2RlIHdoZXJlIENGTiBpcyBjb25zdGFudCBidXQg Zm9yIHRoZQ0KPmxhc3QgZnJhZ21lbnQ/DQo+ICBEbyB3ZSBhZ3JlZSB0aGF0IGluIFdpbmRvdyBt b2RlLCBDRk4gYW5kIFcgdW5hbWJpZ3VvdXNseSBkZXRlcm1pbmUNCj5sb2NhdGlvbiBpbiB0aGUg cmVhc3NlbWJseSBidWZmZXI/DQo+DQo+U2VjdGlvbiA5LjYsIEJhc2VsaW5lIG1lY2hhbmlzbSwg ZGVzY3JpcHRpb24gb2YgV2luZG93IG1vZGUgLSBBQ0sgb24gZXJyb3INCj4iVXBvbiBleHBpcmF0 aW9uIG9mIHRoZSAiQUNLIG9uIEVycm9yIFRpbWVyIiwgaWYgdGhlIHJlY2VpdmVyIGtub3dzIHRo YXQNCj5hdCBsZWFzdCBvbmUgZnJhZ21lbnQgb2YgdGhlIGN1cnJlbnQgd2luZG93IGhhcyBiZWVu IGxvc3QgxaDCsg0KPiAgSWYgdGhlICJBQ0sgb24gRXJyb3IgVGltZXIiIGV4cGlyZXMgYXQgdGhl IHJlY2VpdmVyLCB0aGVuIGl0IGtub3dzIHRoYXQNCj5hdCBsZWFzdCB0aGUgbGFzdCBmcmFnbWVu dCBpcyBhc3N1bWVkIHRvIGhhdmUgYmVlbiBsb3N0LCBjb3JyZWN0Pw0KPlRoZXJlZm9yZSwgdGhl ICJpZiB0aGUgcmVjZWl2ZXIga25vd3MgdGhhdCBhdCBsZWFzdCBvbmUgZnJhZ21lbnQgb2YgdGhl DQo+Y3VycmVudCB3aW5kb3cgaGFzIGJlZW4gbG9zdCIgY2xhdXNlIGlzIGlycmVsZXZhbnQgYW5k IGNhbiBiZSByZW1vdmVkIGZyb20NCj50aGUgdGV4dC4NCj5UaGUgZGVzY3JpcHRpb24gb2YgwrNX aW5kb3cgbW9kZSAtIEFDSyBvbiBlcnJvcsKyIGRvZXMgbm90IG1lbnRpb24NCj5NQVhfRlJBR19S RVRSSUVTLiBNeSB1bmRlcnN0YW5kaW5nIG9mIMKzV2luZG93IG1vZGUgLSBBY2sgb24gZXJyb3LC siBpcyB0aGF0DQo+aXQgd291bGQgYmVuZWZpdCBmcm9tIHRoZSBzYW1lIE1BWF9GUkFHX1JFVFJJ RVMgbWVjaGFuaXNtLg0KPkluIMKzV2luZG93IG1vZGUgLSBBQ0sgb24gZXJyb3LCsiwgdGhlIEFD SyBjYW5ub3QgYmUgdXNlZCBmb3IgZmxvdyBjb250cm9sLg0KPlRoZSBkcmFmdCBkb2VzIG5vdCBw cm92aWRlIHJlY29tbWVuZGF0aW9ucyBvbiB3aGVuIGEgc2VuZGVyIGNhbiBmb3JnZXQNCj5hYm91 dCBhIHdpbmRvdyB0aGF0IGl0IGhhcyBzZW50LCBhbmQgcmVhbGxvY2F0ZSB0aGUgd2luZG93IG51 bWJlciAoMSBiaXQpDQo+dG8gYSBuZXcgd2luZG93LiBOb3IgZG9lcyBpdCBwcm92aWRlIHJlY29t bWVuZGF0aW9uIGFib3V0IGZvcmdldHRpbmcgYWJvdXQNCj50aGUgbGFzdCB3aW5kb3cgb2YgYW4g SVB2NiBwYWNrZXQuIFNlZSBmb3IgZXhhbXBsZSBGaWd1cmVzIDE3IGFuZCAxOCBpbg0KPkFwcGVu ZGl4IEEuIEnCuW0gYXNzdW1pbmcgdGhhdCBhIHNlbmRlciBpbXBsZW1lbnRhdGlvbiB3b3VsZCB3 YW50IHRvIHdhaXQNCj5mb3IgYSByZWFzb25hYmxlIHRpbWUgYmVmb3JlIGZvcmdldHRpbmcgYWJv dXQgYSB3aW5kb3csIGp1c3QgaW4gY2FzZSBhbg0KPkFDSyBvbiBlcnJvciB3b3VsZCBiZSByZWNl aXZlZCBzaG9ydGx5LiBTaG91bGQgdGhpcyBiZSBkZXNjcmliZWQgaGVyZT8NCj4NCj5TZWN0aW9u IDkuNiwgQmFzZWxpbmUgbWVjaGFuaXNtLCBkZXNjcmlwdGlvbiBvZiBNSUMgcHJvY2Vzc2luZyBh dCB0aGUgZW5kDQo+b2YgcmVhc3NlbWJseQ0KPiAgwrNJbiBObyBBQ0sgbW9kZSwgaWYgdGhlIGlu dGVncml0eSBjaGVjayBpbmRpY2F0ZXMgdGhhdCB0aGUgcmVhc3NlbWJsZWQNCj5JUHY2IGRhdGFn cmFtIGRvZXMgbm90IG1hdGNoIHRoZSBvcmlnaW5hbCBJUHY2IGRhdGFncmFtIChwcmlvciB0bw0K PmZyYWdtZW50YXRpb24pLCB0aGUgcmVhc3NlbWJsZWQgSVB2NiBkYXRhZ3JhbSBNVVNUIGJlIGRp c2NhcmRlZC7Csg0KPiAgVGhlIGZvbGxvd2luZyBzZW50ZW5jZXMgc3RhdGUgdGhhdCBpbiBlaXRo ZXIgV2luZG93IG1vZGUsIHRoZSBBQ0sNCj5jb252ZXlzIGluZm9ybWF0aW9uIGFib3V0IGZyYWdt ZW50cyBvZiB0aGUgbGFzdCB3aW5kb3cgdGhhdCBoYXZlIGJlZW4NCj5jb3JyZWN0bHkgcmVjZWl2 ZWQgb3Igbm90IHJlY2VpdmVkLiAoSW5jaWRlbnRhbGx5LCB0aGVzZSBzZW50ZW5jZXMgYXJlDQo+ cmVkdW5kYW50IHdpdGggdGhlIHNhbWUgdGV4dCBpbiB0aGUgdGhpcmQgYW5kIGZpZnRoIHBhcmFn cmFwaHMgb2YgdGhlIHNhbWUNCj5zZWN0aW9uIDkuNi4gRG8gd2UgbmVlZCBib3RoPykNCj4gIE5v dGhpbmcgaXMgc2FpZCBhYm91dCB3aGF0IHRvIGRvLCBpbiBXaW5kb3cgbW9kZSwgd2hlbiB0aGUg TUlDIGRvZXMgbm90DQo+bWF0Y2guIEZvciBjb21wbGV0ZW5lc3MsIEkgc3VnZ2VzdCB3ZSB3cml0 ZSB0aGF0IHRoZSByZWFzc2VtYmxlZCBJUHY2DQo+ZGF0YWdyYW0gTVVTVCBiZSBkaXNjYXJkZWQs IGFuZCBzaW1wbHkgc3RhdGUgdGhhdCBhbiBBQ0sgaXMgc2VudCB3aXRoIHRoZQ0KPnNhbWUgYmVo YXZpb3VyIHRoYW4gZm9yIGFueSBvdGhlciB3aW5kb3cuDQo+DQo+QXBwZW5kaXggQiwgYWxsb2Nh dGlvbiBvZiBSdWxlIElEcyBmb3IgZnJhZ21lbnRhdGlvbg0KPiAgSSBzdWdnZXN0IHRvIG1vZGlm eSB0aGUgc2VjdGlvbiB0aXRsZSB0byDCs0FsbG9jYXRpb24gb2YgUnVsZSBJRHMgZm9yDQo+ZnJh Z21lbnRhdGlvbsKyLg0KPiAgVGhpcyBzZWN0aW9uIHNob3VsZCBiZSByZXdyaXR0ZW4uIEkgc3Vn Z2VzdDoNCj4gIMKzQSBzZXQgb2YgUnVsZSBJRHMgYXJlIGFsbG9jYXRlZCB0byBzdXBwb3J0IGRp ZmZlcmVudCBhc3BlY3RzIG9mDQo+ZnJhZ21lbnRhdGlvbg0KPiAgIGZ1bmN0aW9uYWxpdHkgYXMg cGVyIHRoaXMgZG9jdW1lbnQuIFRoZSBhbGxvY2F0aW9uIG9mIElEcyBpcyB0byBiZQ0KPmRlZmlu ZWQgaW4gb3RoZXIgZG9jdW1lbnRzLiBUaGUgc2V0IE1BWSBpbmNsdWRlOg0KPg0KPiAgIG8gIG9u ZSBJRCBvciBhIHN1YnNldCBvZiBJRHMgdG8gaWRlbnRpZnkgYSBmcmFnbWVudCBhcyB3ZWxsIGFz IGl0cw0KPnJlbGlhYmlsaXR5IG9wdGlvbiBhbmQgaXRzIHdpbmRvdyBzaXplLCBpZiBtdWx0aXBs ZSBvZiB0aGVzZSBhcmUgc3VwcG9ydGVkDQo+DQo+ICAgbyAgb25lIElEIHRvIGlkZW50aWZ5IHRo ZSBBQ0sgbWVzc2FnZS4NCj4NCj4gICBvICBvbmUgSUQgdG8gaWRlbnRpZnkgdGhlIEFib3J0IG1l c3NhZ2UgYXMgcGVyIFNlY3Rpb24gOS44LsKyDQo+ICBEbyB3ZSBhZ3JlZSB3aXRoIHRoZSDCs29u ZSBJRMKyIGluIHRoZSBsYXN0IHR3byBpdGVtcywgb3IgYXJlIHRoZXJlIHVzZQ0KPmNhc2VzIHRo YXQgSSBkb27CuXQgc2VlIHRoYXQgd291bGQganVzdGlmeSBmb3IgbXVsdGlwbGUgSURzID8NCj4N Cj4NCj4NCj5WYXJpb3VzIG5pdHMNCj4qIFNlY3Rpb24gMywgVGVybWlub2xvZ3kuIENGTiBpcyBu b3QgbGlzdGVkLiBBbHNvIGFkZCB0aGUgb3RoZXIgYWNyb255bXMNCj4oRFRhZywgTUlDLCBldGMu KSB1c2VkIGluIHRoZSBmcmFnbWVudGF0aW9uIHNlY3Rpb24uDQo+KiBTZWN0aW9uIDkuMjogTUFY X0ZSQUdfUkVUUklFUyBpcyBkZXNjcmliZWQgZm9yIHRoZSBXaW5kb3cgbW9kZSAtIEFDSw0KPsKz YWx3YXlzwrIuIEZvciBjb21wbGV0ZW5lc3MsIHRoZSBzYW1lIHRleHQgc2hvdWxkIGJlIHJlcGVh dGVkIGZvciB0aGUNCj5XaW5kb3cgbW9kZSAtIEFDSyBvbiBlcnJvci4NCj4qIFNlY3Rpb24gOS40 OiBSdWxlIElEIGRlc2NyaXB0aW9uLiBBZGQgdGhlIHVzZSBvZiBSdWxlIElEIGZvciBjb252ZXlp bmcNCj50aGUgd2luZG93IHNpemUgaWYgbXVsdGlwbGUgc2l6ZXMgYXJlIHN1cHBvcnRlZC4NCj4g IE9MRCBURVhUDQo+ICDCs1J1bGUgSUQgbWF5IGFsc28gYmUgdXNlZCB0byBzaWduYWwgd2hpY2gg cmVsaWFiaWxpdHkgb3B0aW9uIGlzIGluIHVzZQ0KPmZvciB0aGUgSVB2NiBwYWNrZXQgYmVpbmcg Y2FycmllZC7Csg0KPiAgTkVXIFRFWFQNCj4gIMKzUnVsZSBJRCBtYXkgYWxzbyBiZSB1c2VkIHRv IHNpZ25hbCB3aGljaCByZWxpYWJpbGl0eSBvcHRpb24gaXMgaW4gdXNlDQo+Zm9yIHRoZSBJUHY2 IHBhY2tldCBiZWluZyBjYXJyaWVkLiBSdWxlIElEIG1heSBhbHNvIGJlIHVzZWQgdG8gc2lnbmFs IHRoZQ0KPndpbmRvdyBzaXplIGlmIG11bHRpcGxlIHNpemVzIGFyZSBzdXBwb3J0ZWQgKHNlZSA5 LjcpLsKyDQo+KiBTZWN0aW9uIDkuNDogwrNDb21wcmVzc2VkIEZyYWdtZW50IE51bWJlcsKyLiDC s0NvbXByZXNzZWTCsiByZWZlcnMgdG8gdGhlDQo+bnVtYmVyLCBub3QgdG8gdGhlIGZyYWdtZW50 LCBzaW5jZSB1bmNvbXByZXNzZWQgcGFja2V0IGNhbiBhbHNvIGJlDQo+ZnJhZ21lbnRlZCB3aXRo IHRoaXMgbWVjaGFuaXNtLg0KPiAgVG8gcmVtb3ZlIHRoaXMgYW1iaWd1aXR5LCByZW5hbWUgQ0ZO IHRvIEZyYWdtZW50IENvbXByZXNzZWQgTnVtYmVyDQo+KEZDTik/IA0KPiAgQ0ZOL0ZDTiBzaG91 bGQgYmUgbGlzdGVkIGluIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uLg0KPiAgVGhlIHBhcnQgb2Yg dGhlIHNlbnRlbmNlIMKzLCBhbmQgZG9lcyBub3QgbmVjZXNzYXJpbHkgY2FycnkgYW4gYWJzb2x1 dGUNCj5mcmFnbWVudCBudW1iZXIuwrIgc2hvdWxkIGJlIHJld3JpdHRlbiBhcyDCsywgYW5kIGRv ZXMgbm90IGNhcnJ5IGFuIGFic29sdXRlDQo+ZnJhZ21lbnQgbnVtYmVyLsKyLiBJbmRlZWQsIENG TiBjb3VudHMgZG93biBmcm9tICJoaWdoZXN0IENGTiBpbiB0aGUNCj53aW5kb3ciIGFueXdheSwg c28gdGhlIGNoYW5jZXMgdGhhdCBpdCBjb3JyZXNwb25kcyB0byBhbiBhYnNvbHV0ZSBmcmFnbWVu dA0KPm51bWJlciBhcmUgbnVsbC4NCj4gIFNlZSBhcyB3ZWxsIG15IGNvbW1lbnQgb24gdGV4dCBy ZWdhcmRpbmcgQ0ZOIGluIDkuNS4yDQo+KiBTZWN0aW9uIDkuNS4yOiBSZW1vdmUgwrMsIGFuZCB0 aHVzIHRoZSBDRk4gZG9lcyBub3Qgc3RyaWN0bHkgY29ycmVzcG9uZA0KPnRvIHRoZSBOIGxlYXN0 IHNpZ25pZmljYW50IGJpdHMgb2YgdGhlIGFjdHVhbCBhYnNvbHV0ZSBmcmFnbWVudCBudW1iZXIu wrIuDQo+SXQgZG9lcyBub3Qgc3RyaWN0bHkgY29ycmVzcG9uZCwgbm9yIGxvb3NlbHkuDQo+KiBT ZWN0aW9uIDkuNS4zOiDCskFic2VuY2Ugb2YgdGhlIGJpdG1hcCBpbiBhbiBBQ0sgY29uZmlybXMg Y29ycmVjdA0KPnJlY2VwdGlvbiBvZiBhbGwgZnJhZ21lbnRzIHRvIGJlIGFja25vd2xlZGdlZCBi eSBtZWFucyBvZiB0aGUgQUNLLiINCj4gIEZvciB0aGUgd29uZGVyaW5nIHNvdWwsIG1heWJlIGV4 cGxhaW4gdGhhdCB0aGUgYWJzZW5jZSBpcyBub3RpY2VkIGJ5DQo+bG9va2luZyBhdCB0aGUgTDIg c2l6ZSwgc2luY2UgaXQgZG9lc24ndCBpbW1lZGlhdGVseSBzaG93IGZyb20gRmlndXJlIDEzLg0K PiogU2VjdGlvbiA5LjY6ICJpZiBubyBBQ0sgaGFzIGJlZW4gcmVjZWl2ZWQgc2luY2UgdGhlIHRp bWVyIHN0YXJ0LCB0aGUNCj5zZW5kZXIgcmV0cmFuc21pdHMgdGhlIGxhc3QgZnJhZ21lbnQgc2Vu dCDFoCIuIENvdWxkIHJlZmVyIHRvIHRoZSBsYXN0IGluDQo+dGltZSBvciB0aGUgbGFzdCBpbiBv cmRlci4NCj4gIEkgZ3Vlc3MgdGhlIGNvcnJlY3QgYW5zd2VyIGlzIHRoZSBsYXR0ZXIsIGkuZS4g dGhlIGxhc3QgZnJhZ21lbnQgb2YgdGhlDQo+SVB2NiBwYWNrZXQuDQo+KiBTZWN0aW9uIDkuNjog wrNTaW1pbGFybHksIHdoZW4gYSBub2RlIGZpcnN0IHJlY2VpdmVzIMWgIMKzLiDCs25vZGXCsiBp cyBub3QNCj5wYXJ0IG9mIHRoZSB0ZXJtaW5vbG9neS4gRG8geW91IG1lYW4gYSBEZXZpY2UsIG9y IGVpdGhlciBlbmQgb2YgdGhlIExQV0FODQo+bGluayA/DQo+KiBTZWN0aW9uIDkuOCwgZnJhZ20v cmVhc3NibHkgYWJvcnRpb24NCj4gIE9MRCBURVhUDQo+ICDCs1RoZSBlbnRpdHkgKGVpdGhlciB0 aGUgZnJhZ21lbnQgc2VuZGVyIG9yIHRoZSBmcmFnbWVudCByZWNlaXZlcikgdGhhdA0KPnRyaWdn ZXJzIGFib3J0aW9uIHRyYW5zbWl0cyB0byB0aGUgb3RoZXIgZW5kcG9pbnQgYSBmb3JtYXQgdGhh dCBvbmx5DQo+Y29tcHJpc2VzIGEgUnVsZSBJRCAob2Ygc2l6ZSBSIGJpdHMpLCB3aGljaCBzaWdu YWxzIGFib3J0aW9uIG9mIGFsbA0KPm9uLWdvaW5nIGZyYWdtZW50ZWQgSVB2NiBwYWNrZXQgdHJh bnNtaXNzaW9ucy7Csg0KPiAgTkVXIFRFWFQNCj4gIMKzVGhlIGVudGl0eSAoZWl0aGVyIHRoZSBm cmFnbWVudCBzZW5kZXIgb3IgdGhlIGZyYWdtZW50IHJlY2VpdmVyKSB0aGF0DQo+dHJpZ2dlcnMg YWJvcnRpb24gdHJhbnNtaXRzIHRvIHRoZSBvdGhlciBlbmRwb2ludCBhIHBhY2tldCB0aGF0IG9u bHkNCj5jb21wcmlzZXMgYSB1bmlxdWUgUnVsZSBJRCAob2Ygc2l6ZSBSIGJpdHMpLCB3aGljaCBz aWduYWxzIGFib3J0aW9uIG9mIGFsbA0KPm9uLWdvaW5nIGZyYWdtZW50ZWQgSVB2NiBwYWNrZXQg dHJhbnNtaXNzaW9ucy7Csg0KPiogU2VjdGlvbiAxMC4yLCBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBmb3IgZnJhZ21lbnRhdGlvbg0KPiAgwrNJZiBhbiBhdHRhY2tlciBjYW4gb3ZlcmhlYXIgYSBm cmFnbWVudCwgaXQgY2FuIHNlbmQgYSBzcG9vZmVkIGR1cGxpY2F0ZQ0KPihlLmcuIHdpdGggcmFu ZG9tIHBheWxvYWQpIHRvIHRoZSBkZXN0aW5hdGlvbi4gQSByZWNlaXZlciBjYW5ub3QNCj5kaXN0 aW5ndWlzaCBsZWdpdGltYXRlIGZyb20gc3Bvb2ZlZCBmcmFnbWVudHMuwrINCj4gIFRoaXMgaXMg dHJ1ZSBvZiBhbGwgTFBXQU4gdGVjaG5vbG9naWVzLiBGb3IgZXhhbXBsZSwgTG9SYVdBTiBoYXMg c291cmNlDQo+YXV0aGVudGljYXRpb24gdGhhdCBhbGxvd3MgYSByZWNlaXZlciBkaXN0aW5ndWlz aGluZyBhIHJhbmRvbS1wYXlsb2FkDQo+c3Bvb2ZlZCBmcmFnbWVudCBmcm9tIGEgbGVnaXRpbWF0 ZSBvbmUuIElsIGFsc28gaGFzIGEgZnJhbWUgY291bnRlcg0KPm1lY2hhbmlzbSB0aGF0IGFsbG93 cyBhIHJlY2VpdmVyIHRvIGRpc2NhcmQgbGF0ZXIgcmVwbGF5IGJ5IGFuIGF0dGFja2VyIG9mDQo+ YSBzdHJpY3RseSBpZGVudGljYWwgbWVzc2FnZSBhcyBzZW5kIGVhcmxpZXIgYnkgYSBsZWdpdGlt YXRlIG5vZGUuDQo+ICBUaGVyZWZvcmUsIHRoZSBhdHRhY2sgZGVzY3JpYmVkIGhlcmUgYW5kIGl0 cyBtaXRpZ2F0aW9uIG9ubHkgYXBwbGllcyB0bw0KPmNlcnRhaW4gTFBXQU4gdGVjaG5vbG9naWVz Lg0KPiogQXBwZW5kaXggQTogwrNOb3RlOiBpbiBXaW5kb3cgbW9kZSwgYW4gYWRkaXRpb25hbCBi aXQgd2lsbCBiZSBuZWVkZWQgdG8NCj5udW1iZXIgd2luZG93cy7Csi4gVGhpcyBjb21tZW50IGlz IGNvcnJlY3QsIGJ1dCBpdCBpcyBvZGRseSBwbGFjZWQgaW4gdGhlDQo+bWlkZGxlIG9mIHRoZSBk ZXNjcmlwdGlvbiBvZiBGaWd1cmUgMTkgYXMgaWYgaXQgZGlkbsK5dCBhcHBseSB0byB0aGUgwrNB Q0sNCj5vbiBlcnJvcsKyIG1vZGUgYXMgd2VsbC4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+DQo+RG9t aW5pcXVlDQo+DQo+TGUgMDEvMDcvMTcgMTk6MDQsIMKrIGxwLXdhbiBvbiBiZWhhbGYgb2YgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIMK7DQo+PGxwLXdhbi1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IGEgw6ljcml0IDoNCj4NCj4+DQo+PkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cw0KPj5kaXJlY3Rvcmllcy4NCj4+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgSVB2NiBvdmVyIExvdyBQb3dlciBXaWRlLUFyZWEgTmV0d29ya3MNCj4+b2YgdGhlIElFVEYu DQo+Pg0KPj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IExQV0FOIFN0YXRpYyBDb250ZXh0IEhl YWRlciBDb21wcmVzc2lvbiAoU0NIQykNCj4+YW5kIGZyYWdtZW50YXRpb24gZm9yIElQdjYgYW5k IFVEUA0KPj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IEFuYSBNaW5hYnVybw0KPj4gICAgICAg ICAgICAgICAgICAgICAgICAgIExhdXJlbnQgVG91dGFpbg0KPj4gICAgICAgICAgICAgICAgICAg ICAgICAgIENhcmxlcyBHb21leg0KPj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1scHdh bi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjLTA1LnR4dA0KPj4JUGFnZXMgICAgICAgICAgIDogMzcN Cj4+CURhdGUgICAgICAgICAgICA6IDIwMTctMDctMDENCj4+DQo+PkFic3RyYWN0Og0KPj4gICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGhlYWRlciBjb21wcmVzc2lvbiBzY2hlbWUgYW5kIGZy YWdtZW50YXRpb24NCj4+ICAgZnVuY3Rpb25hbGl0eSBmb3IgdmVyeSBsb3cgYmFuZHdpZHRoIG5l dHdvcmtzLiAgVGhlc2UgdGVjaG5pcXVlcyBhcmUNCj4+ICAgZXNwZWNpYWxseSB0YWlsb3JlZCBm b3IgTFBXQU4gKExvdyBQb3dlciBXaWRlIEFyZWEgTmV0d29yaykgbmV0d29ya3MuDQo+Pg0KPj4g ICBUaGUgU3RhdGljIENvbnRleHQgSGVhZGVyIENvbXByZXNzaW9uIChTQ0hDKSBvZmZlcnMgYSBn cmVhdCBsZXZlbCBvZg0KPj4gICBmbGV4aWJpbGl0eSB3aGVuIHByb2Nlc3NpbmcgdGhlIGhlYWRl ciBmaWVsZHMgYW5kIG11c3QgYmUgdXNlZCBmb3INCj4+ICAgdGhlc2Uga2luZCBvZiBuZXR3b3Jr cy4gIEEgY29tbW9uIGNvbnRleHQgc3RvcmVkIGluIGEgTFBXQU4gZGV2aWNlDQo+PiAgIGFuZCBp biB0aGUgbmV0d29yayBpcyB1c2VkLiAgVGhpcyBjb250ZXh0IGtlZXBzIGluZm9ybWF0aW9uIHRo YXQgd2lsbA0KPj4gICBub3QgYmUgdHJhbnNtaXR0ZWQgaW4gdGhlIGNvbnN0cmFpbmVkIG5ldHdv cmsuICBTdGF0aWMgY29udGV4dCBtZWFucw0KPj4gICB0aGF0IGluZm9ybWF0aW9uIHN0b3JlZCBp biB0aGUgY29udGV4dCB3aGljaCBkZXNjcmliZXMgZmllbGQgdmFsdWVzLA0KPj4gICBkb2VzIG5v dCBjaGFuZ2UgZHVyaW5nIHBhY2tldCB0cmFuc21pc3Npb24sIGF2b2lkaW5nIGNvbXBsZXgNCj4+ ICAgcmVzeW5jaHJvbml6YXRpb24gbWVjaGFuaXNtcywgaW5jb21wYXRpYmxlIHdpdGggTFBXQU4N Cj4+ICAgY2hhcmFjdGVyaXN0aWNzLiAgSW4gbW9zdCBvZiB0aGUgY2FzZXMsIElQdjYvVURQIGhl YWRlcnMgYXJlIHJlZHVjZWQNCj4+ICAgdG8gYSBzbWFsbCBpZGVudGlmaWVyIGNhbGxlZCBSdWxl IElELiAgQnV0IHNvbWV0aW1lcyB0aGUgU0NIQyBoZWFkZXINCj4+ICAgY29tcHJlc3Npb24gbWVj aGFuaXNtcyB3aWxsIG5vdCBiZSBlbm91Z2ggdG8gc2VuZCB0aGUgY29tcHJlc3NlZA0KPj4gICBw YWNrZXQgaW4gb25lIEwyIFBEVSwgc28gdGhlIFNDSEMgRnJhZ21lbnRhdGlvbiBwcm90b2NvbCBt dXN0IGJlIHVzZWQNCj4+ICAgd2hlbiBuZWVkZWQuDQo+Pg0KPj4gICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBTQ0hDIGNvbXByZXNzaW9uL2RlY29tcHJlc3Npb24gbWVjaGFuaXNtDQo+PiAgIGZy YW1ld29yayBhbmQgYXBwbGllcyBpdCB0byBJUHY2L1VEUCBoZWFkZXJzLiAgU2ltaWxhciBzb2x1 dGlvbnMgZm9yDQo+PiAgIG90aGVyIHByb3RvY29scyBzdWNoIGFzIENvQVAgd2lsbCBiZSBkZXNj cmliZWQgaW4gc2VwYXJhdGUgZG9jdW1lbnRzLg0KPj4gICBNb3Jlb3ZlciwgdGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgZnJhZ21lbnRhdGlvbiBhbmQgcmVhc3NlbWJseQ0KPj4gICBtZWNoYW5pbSBm b3IgU0NIQyBjb21wcmVzc2VkIHBhY2tldHMgZXhjZWVkaW5nIHRoZSBMMiBQRFUgc2l6ZSBhbmQN Cj4+ICAgZm9yIHRoZSBjYXNlIHdoZXJlIHRoZSBTQ0hDIGNvbXByZXNzaW9uIGlzIG5vdCBwb3Nz aWJsZSB0aGVuIHRoZQ0KPj4gICBwYWNrZXQgaXMgc2VudCB1c2luZyB0aGUgZnJhZ21lbnRhdGlv biBwcm90b2NvbC4NCj4+DQo+Pg0KPj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjLw0KPj4NCj4+VGhlcmUgYXJlIGFs c28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0YXRpYy1jb250ZXh0LWhjLTA1DQo+Pmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1scHdhbi1pcHY2 LXN0YXRpYy1jb250ZXgNCj4+dA0KPj4taGMtMDUNCj4+DQo+PkEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtbHB3YW4taXB2Ni1zdGF0aWMtY29udGV4dC1oYw0KPj4tDQo+ PjA1DQo+Pg0KPj4NCj4+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+c3VibWlzc2lvbg0KPj51bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4N Cj4+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 Og0KPj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+bHAtd2FuIG1haWxpbmcg bGlzdA0KPj5scC13YW5AaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9scC13YW4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+Q2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+Y29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj5wYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6DQo+cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+ YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzDQo+ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLA0KPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lDQo+b3UgZmFsc2lmaWUuIE1lcmNpLg0KPg0KPlRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkDQo+aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCj50 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4NCj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kDQo+ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLg0KPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0KPmJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLg0KPlRoYW5rIHlvdS4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPmxwLXdhbiBtYWlsaW5nIGxpc3QNCj5scC13YW5AaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xwLXdhbg0KDQoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBk ZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9p dmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2Nl cHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4K ClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBh dXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCgo= From nobody Wed Jul 5 05:42:22 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 1D6D3131CD6 for ; Wed, 5 Jul 2017 05:42:21 -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 vyrvs4ANzjzK for ; Wed, 5 Jul 2017 05:42:19 -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 2E412127077 for ; Wed, 5 Jul 2017 05:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39160; q=dns/txt; s=iport; t=1499258539; x=1500468139; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=500BEyLzN4dV2ua3Ifoq0I6E6jkJFLDdR+7W7Ok8U2E=; b=jgH04GV/1csdig0UzpnSz6gp/OSQSEYNCzRvs6O9rrK2TzSANlupzurr 2ktkgYUsSZ/CaFR/CLvYoOH9XRUzzNQVGVQIqoeoq/cUV/znB1lHjbfSh 1vF0vHlXUObPEHq7V30yaVt/X1As5seydql/RkB4BkcyWnUBAUCI6ha9a 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AAC83VxZ/5pdJa1CFwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCb2pjgRAHjgKRaZYAgSkFYy6ENYE5AhqCeT8YAQIBAQEBAQE?= =?us-ascii?q?Bax0LhRgBAQEBAQIjCjkjAgEIEQQBARUECAEDAwMCAgIwFAcBAQUCAQEBBBMIi?= =?us-ascii?q?UNkEDKtNoImg1OHbQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DJ4NMgWGDJIE8AYF?= =?us-ascii?q?pgTUbCwoVEQeCCBYngkcaBZ8GAodFhwmFLIIVGT2Cb4IFikiKJIsOAR84gQp1F?= =?us-ascii?q?YMVgkccgRdPdgGHW4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,312,1496102400"; d="scan'208,217";a="263950709" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2017 12:42:18 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v65CgIAg001721 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Jul 2017 12:42:18 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; Wed, 5 Jul 2017 07:42: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, 5 Jul 2017 07:42:17 -0500 From: "Pascal Thubert (pthubert)" To: "lp-wan@ietf.org" Thread-Topic: Webex info for the LPWAN Interim, July 5th 2017 Thread-Index: AdLwymjirInR0VClTOGDx5IpklnU3gEwKNhQAAA1mnA= Date: Wed, 5 Jul 2017 12:41:58 +0000 Deferred-Delivery: Wed, 5 Jul 2017 12:41:43 +0000 Message-ID: <6d9b7d6d78a74a3eb3db3355625ba599@XCH-RCD-001.cisco.com> References: <912f39251fd1483e87e09d5de00e69d5@XCH-RCD-001.cisco.com> In-Reply-To: <912f39251fd1483e87e09d5de00e69d5@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.82.220.87] Content-Type: multipart/alternative; boundary="_000_6d9b7d6d78a74a3eb3db3355625ba599XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] FW: 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: Wed, 05 Jul 2017 12:42:21 -0000 --_000_6d9b7d6d78a74a3eb3db3355625ba599XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTFBXQU5lcnMsDQoNCkdlbnRsZSByZW1pbmRlciB0aGF0IHRoZSBpbnRlcmltIGlzIGlu IDkwIG1pbnV0ZXMgYW5kIHRoYXQgdGhlIHdlYmV4IGluZm9ybWF0aW9uIGhhcyBjaGFuZ2VkIGZy b20gdGhlIHByZXZpb3VzIG9jY3VycmVuY2VzLg0KDQpDaGVlcnM7DQoNClRoZSBjaGFpcnMNCg0K RnJvbTogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KU2VudDogamV1ZGkgMjkganVpbiAyMDE3 IDEzOjI1DQpUbzogbHAtd2FuQGlldGYub3JnPG1haWx0bzpscC13YW5AaWV0Zi5vcmc+DQpDYzog J2xwLXdhbi1jaGFpcnNAaWV0Zi5vcmcnIDxscC13YW4tY2hhaXJzQGlldGYub3JnPG1haWx0bzps cC13YW4tY2hhaXJzQGlldGYub3JnPj4NClN1YmplY3Q6IFdlYmV4IGluZm8gZm9yIHRoZSBMUFdB TiBJbnRlcmltLCBKdWx5IDV0aCAyMDE3DQoNCkhlbGxvIExQV0FOZXJzLA0KDQoNCg0KVGhlIGNo YWlycyBpbnZpdGVzIHlvdSB0byBqb2luIG91ciBuZXh0IGludGVyaW0gbWVldGluZw0KDQouDQoN Cg0KDQoNCg0KTFBXQU4gSW50ZXJpbQ0KDQpXZWRuZXNkYXkgNSBKdWx5IDIwMTcNCg0KMTY6MDAg IHwgIEV1cm9wZSBTdW1tZXIgVGltZSAoUGFyaXMsIEdNVCswMjowMCkgIHwgIDEgaHINCg0KDQoN Cg0KDQpKb2luIFdlYkV4IG1lZXRpbmcgPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2Fs ZXMvai5waHA/TVRJRD1tMjAxNGNhMmRkMTgxYjFhNWI2ZTI3Zjk0MTgwYmQwZGU+DQoNCg0KTWVl dGluZyBudW1iZXI6DQoNCjIwNyA1MTQgMjI3DQoNCk1lZXRpbmcgcGFzc3dvcmQ6DQoNClRtQ0VD dFNLICg4NjIzMjg3NSBmcm9tIHBob25lcykNCg0KDQpKb2luIGZyb20gYSB2aWRlbyBjb25mZXJl bmNpbmcgc3lzdGVtIG9yIGFwcGxpY2F0aW9uDQoNCkRpYWwgMjA3NTE0MjI3QGNpc2NvLndlYmV4 LmNvbTwlMjBzaXA6MjA3NTE0MjI3QGNpc2NvLndlYmV4LmNvbT4NCg0KRnJvbSB0aGUgQ2lzY28g aW50ZXJuYWwgbmV0d29yaywgZGlhbCAqMjY3KiBhbmQgdGhlIDktZGlnaXQgbWVldGluZyBudW1i ZXIuIElmIHlvdSBhcmUgdGhlIGhvc3QsIGVudGVyIHlvdXIgUElOIHdoZW4gcHJvbXB0ZWQuDQoN Cg0KDQoNCg0KSm9pbiBieSBwaG9uZQ0KDQorMS04NjYtNDMyLTk5MDMgQ2FsbC1pbiB0b2xsLWZy ZWUgbnVtYmVyIChVUy9DYW5hZGEpDQoNCisxLTQwOC01MjUtNjgwMCBDYWxsLWluIHRvbGwgbnVt YmVyIChVUy9DYW5hZGEpDQoNCkFjY2VzcyBjb2RlOiAyMDcgNTE0IDIyNw0KDQpHbG9iYWwgY2Fs bC1pbiBudW1iZXJzPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvZ2xvYmFsY2Fs bGluLnBocD9zZXJ2aWNlVHlwZT1NQyZFRD0zOTIxNzcyNDcmdG9sbEZyZWU9MT4gIHwgIFRvbGwt ZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczxodHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxm cmVlX3Jlc3RyaWN0aW9ucy5wZGY+DQoNCg0KDQoNCg0KQWRkIHRoaXMgbWVldGluZzxodHRwczov L2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bTYxZjk2MWQ1NmI3ZWQ0NDk4 MjM0MDEwMmZmNDRhZDZlPiB0byB5b3VyIGNhbGVuZGFyLiAoQ2Fubm90IGFkZCBmcm9tIG1vYmls ZSBkZXZpY2VzLikNCg0KDQoNCg0KDQpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1 cHBvcnQuPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvbWM+DQoNCg0KDQoNCg0K SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLg0KDQoNCg0KDQo= --_000_6d9b7d6d78a74a3eb3db3355625ba599XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglm b250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzY2NjY2NjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNl cmlmOw0KCWNvbG9yOiM2NjY2NjY7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiM2NjY2NjYiIHZsaW5rPSIjNjY2NjY2Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGVsbG8gTFBXQU5lcnMsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5HZW50bGUgcmVtaW5kZXIgdGhhdCB0aGUgaW50 ZXJpbSBpcyBpbiA5MCBtaW51dGVzIGFuZCB0aGF0IHRoZSB3ZWJleCBpbmZvcm1hdGlvbiBoYXMg Y2hhbmdlZCBmcm9tIHRoZSBwcmV2aW91cyBvY2N1cnJlbmNlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVyczs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBjaGFpcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCjxicj4NCjxiPlNlbnQ6 PC9iPiBqZXVkaSAyOSBqdWluIDIwMTcgMTM6MjU8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpscC13YW5AaWV0Zi5vcmciPmxwLXdhbkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+ ICdscC13YW4tY2hhaXJzQGlldGYub3JnJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxwLXdhbi1jaGFp cnNAaWV0Zi5vcmciPmxwLXdhbi1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBXZWJleCBpbmZvIGZvciB0aGUgTFBXQU4gSW50ZXJpbSwgSnVseSA1dGggMjAxNzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SGVsbG8gTFBXQU5lcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNSIg Y2VsbHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iNSUiIHN0eWxlPSJ3aWR0aDo1LjEl Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzozLjc1cHQgMGNtIDBjbSAwY20i Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0i NSIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjM5 My43NXB0O21hcmdpbi1sZWZ0OjMuNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0 b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lk dGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxz cGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDozOTMuNzVw dCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGNoYWlycyBpbnZpdGVzIHlvdSB0byBqb2luIG91 ciBuZXh0IGludGVyaW0gbWVldGluZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjcuNXB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+LiA8bzpw Pg0KPC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFj aW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+ DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hv ci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1u O21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90 YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNv LWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIg Y2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRo OjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNv LWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM0RDRENEQiPkxQV0FOIEludGVyaW08L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQiPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEu MHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+V2VkbmVzZGF5IDUg SnVseSAyMDE3DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0 ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2 Ij4xNjowMCZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDtFdXJvcGUgU3VtbWVyIFRpbWUgKFBhcmlz LCBHTVQmIzQzOzAyOjAwKSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsxIGhyDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNSIg Y2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5 Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNt IDBjbSAwY207aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFj aW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6 YXV0byFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDBBRkY5Ij48YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNj b3NhbGVzL2oucGhwP01USUQ9bTIwMTRjYTJkZDE4MWIxYTViNmUyN2Y5NDE4MGJkMGRlIj48Yj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+Sm9pbiBXZWJF eCBtZWV0aW5nPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29y YXRpb246bm9uZSI+DQo8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpu b25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9 IjAiIHN0eWxlPSJ3aWR0aDowY207d2lkdGg6YXV0byFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRy Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAzLjc1cHQgMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1l bGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxl bWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9u dGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM2NjY2NjYiPk1lZXRpbmcgbnVtYmVyOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N Cjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2 NjY2Ij4yMDcgNTE0IDIyNw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDMuNzVwdCAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+TWVldGluZyBwYXNzd29yZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3Rk Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2 NjY2NjYiPlRtQ0VDdFNLICg4NjIzMjg3NSBmcm9tIHBob25lcyk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2 NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNs YXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iNSIgY2VsbHBhZGRp bmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0K PHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLXRvcDoxNS4wcHQ7bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NjY2NjY2Ij5Kb2luIGZyb20gYSB2aWRlbyBjb25mZXJlbmNpbmcgc3lzdGVtIG9yIGFwcGxpY2F0 aW9uPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNjY2NjY2Ij5EaWFsIDxhIGhyZWY9IiUyMHNpcDoyMDc1MTQyMjdAY2lzY28ud2Vi ZXguY29tIj4NCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpu b25lIj4yMDc1MTQyMjdAY2lzY28ud2ViZXguY29tPC9zcGFuPjwvYj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4w cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1l bGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7 bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFj dGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+RnJvbSB0aGUgQ2lzY28gaW50ZXJu YWwgbmV0d29yaywgZGlhbCAqMjY3KiBhbmQgdGhlIDktZGlnaXQgbWVldGluZyBudW1iZXIuIElm IHlvdSBhcmUgdGhlIGhvc3QsIGVudGVyIHlvdXIgUElOIHdoZW4gcHJvbXB0ZWQuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0i NSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRi b2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20g MGNtIDBjbSAwY207aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxz cGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDozOTMuNzVw dCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM2NjY2NjYiPkpvaW4gYnkgcGhvbmU8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiYjNDM7MS04NjYtNDMyLTk5 MDM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7Q2FsbC1pbiB0 b2xsLWZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+JiM0MzsxLTQwOC01MjUtNjgwMDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5h ZGEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+QWNjZXNz IGNvZGU6Jm5ic3A7MjA3IDUxNCAyMjc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNjY2NjY2Ij48YSBocmVmPSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVz L2dsb2JhbGNhbGxpbi5waHA/c2VydmljZVR5cGU9TUMmYW1wO0VEPTM5MjE3NzI0NyZhbXA7dG9s bEZyZWU9MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzAwQUZGOTt0ZXh0 LWRlY29yYXRpb246bm9uZSI+R2xvYmFsIGNhbGwtaW4NCiBudW1iZXJzPC9zcGFuPjwvYT4mbmJz cDsmbmJzcDt8Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90 b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0 cmljdGlvbnM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSI1IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0 eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQi Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5 Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iMCIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0i cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48YSBocmVm PSJodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP01USUQ9bTYxZjk2MWQ1 NmI3ZWQ0NDk4MjM0MDEwMmZmNDRhZDZlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0 LWRlY29yYXRpb246bm9uZSI+QWRkIHRoaXMgbWVldGluZzwvc3Bhbj48L2E+IHRvIHlvdXIgY2Fs ZW5kYXIuDQogKENhbm5vdCBhZGQgZnJvbSBtb2JpbGUgZGV2aWNlcy4pPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVs ZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxw YWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0 ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4w cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBh cmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1y dWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0i NSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToxLjBwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM2NjY2NjYiPkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/DQo8YSBocmVmPSJodHRwczov L2Npc2NvLndlYmV4LmNvbS9jaXNjb3NhbGVzL21jIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZG OTt0ZXh0LWRlY29yYXRpb246bm9uZSI+Q29udGFjdCBzdXBwb3J0Ljwvc3Bhbj48L2E+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2lu Zz0iNSIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0K PHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6Ny41cHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBj bSAwY20gMGNtIDBjbTtoZWlnaHQ6Ny41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1saW5lLWhlaWdodC1hbHQ6Ny41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2 NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjEuMHB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHNwYWNpbmc9IjUiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRo OjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDtt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6MS4wcHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiNBMEEwQTAiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBu b3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3Jt YXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBi ZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcNCiB0aGlzIHNlc3Np b24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3Ug ZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3 aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_6d9b7d6d78a74a3eb3db3355625ba599XCHRCD001ciscocom_-- From nobody Wed Jul 5 09:15: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 C51A1131D6B for ; Wed, 5 Jul 2017 09:15:23 -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 0fgL5L22Cr-o for ; Wed, 5 Jul 2017 09:15:22 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51939131D48 for ; Wed, 5 Jul 2017 09:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3045; q=dns/txt; s=iport; t=1499271322; x=1500480922; h=from:to:subject:date:message-id:mime-version; bh=XCoOVlTV0TyGmiXWDAZcW1p7aeZXtfvBTbUMtqwX0dI=; b=L7k/8iLJRuIWYpr0quz6N5ND2OE0tQD9ZsBU81BwbjuGUlzcg60aEvyV x4GkzlOyzlCYIg/mK3vVuAOgGlZPA/brLLFgkZwBGCy8NuQbNuTHIgNnb xul0LY0I3uuKgxgqSK1MDZUOZmZ7O1/LIQIoExY8AMIQPB4Lmwv3maF5/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAABbEF1Z/5NdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9qY4EXjgKiO4UsghEsiQ4/GAECAQEBAQEBAWsdC4VMXgEMdCYBBBu?= =?us-ascii?q?JQ2QQsAiLQwEBAQEBBQEBAQEBAQEcBYMng0yPYwWXKYddAoFjhWKMNYIVhUqKS?= =?us-ascii?q?JUyAR84gQp1FYdeiGyBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,312,1496102400"; d="scan'208,217";a="449945305" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2017 16:15:21 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v65GFKOn017538 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Jul 2017 16:15:21 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 11:15:20 -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, 5 Jul 2017 11:15:20 -0500 From: "Pascal Thubert (pthubert)" To: "lp-wan@ietf.org" Thread-Topic: Agenda for IETF 99 Thread-Index: AdL1qZs3RWPx96eITieaaVY2hf2Ovg== Date: Wed, 5 Jul 2017 16:15:04 +0000 Deferred-Delivery: Wed, 5 Jul 2017 16:14:18 +0000 Message-ID: <1c4e77f41f5343d8be2e6d9f982d99fd@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.75.233.244] Content-Type: multipart/alternative; boundary="_000_1c4e77f41f5343d8be2e6d9f982d99fdXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Agenda for IETF 99 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, 05 Jul 2017 16:15:24 -0000 --_000_1c4e77f41f5343d8be2e6d9f982d99fdXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear LPWANers, You will find the agenda for our WG meeting @IETF99 in Prague at https://da= tatracker.ietf.org/meeting/99/agenda/lpwan/. If you have any suggestion, please let us know asap; per IETF rules, the ag= enda is to be finalized on July 10th at the latest. The chairs. --_000_1c4e77f41f5343d8be2e6d9f982d99fdXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear LPWANers,=

 

You will find the agenda for our WG meeting @IETF99 = in Prague at https://datatracker.ietf.org/meeting/99/agenda/lpwan/.

 

If you have any suggestion, please let us know asap;= per IETF rules, the agenda is to be finalized on July 10th at t= he latest.

 

The chairs.

--_000_1c4e77f41f5343d8be2e6d9f982d99fdXCHRCD001ciscocom_-- From nobody Mon Jul 10 05:19: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 9422613171B; Mon, 10 Jul 2017 05:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 FXVHyZp2LsXk; Mon, 10 Jul 2017 05:19:31 -0700 (PDT) Received: from smtp2.enst.fr (smtp2.enst.fr [IPv6:2001:660:330f:2::8b]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBD513171A; Mon, 10 Jul 2017 05:19:31 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) by smtp2.enst.fr (Postfix) with ESMTP id A00A4209C2; Mon, 10 Jul 2017 14:19:23 +0200 (CEST) Authentication-Results: smtp2.enst.fr; dkim=pass reason="1024-bit key; unprotected key" header.d=imt-atlantique.fr header.i=@imt-atlantique.fr header.b=P2dKA0S7; dkim-adsp=pass; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 945D8102A27; Mon, 10 Jul 2017 14:19:23 +0200 (CEST) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id d7RHCwMbXPes; Mon, 10 Jul 2017 14:19:23 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 1117B101FDC; Mon, 10 Jul 2017 14:19:23 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy110.enst.fr 1117B101FDC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1499689163; bh=6tTMXkMjvDg5ViKbg3/9MI/L55gPoaKGPCw2/1Pd5ug=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=P2dKA0S79YddMLH8Dl97Lo192tSJl27WJDj9WlJ74KwbtkQez/bwNZKYbP5K0SEf3 MGfTKD0qtHbJjJAfFM8e5a7ilJBINutzkv6lsir5h24NQPi3aEuuDQcYcbWQOI75ga lSS5qSM00AYKnq+Wg8O/HKXRRDsxMAkVgPrySEK8= 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 cjLOFNpiD9ny; Mon, 10 Jul 2017 14:19:22 +0200 (CEST) Received: from mail-ua0-f171.google.com (mail-ua0-f171.google.com [209.85.217.171]) by zproxy110.enst.fr (Postfix) with ESMTPSA id A5641102A21; Mon, 10 Jul 2017 14:19:22 +0200 (CEST) Received: by mail-ua0-f171.google.com with SMTP id j53so52706444uaa.2; Mon, 10 Jul 2017 05:19:22 -0700 (PDT) X-Gm-Message-State: AIVw112OOfgg3NH+9kW9/+gerXA2bINhEuLwyiOXBKc9hy5jT5wyjcFW V7tEXv9LqIVs0zRCp1xfnNYEtmeA1A== X-Received: by 10.176.83.216 with SMTP id l24mr8843042uaa.59.1499689161096; Mon, 10 Jul 2017 05:19:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.61.13 with HTTP; Mon, 10 Jul 2017 05:18:40 -0700 (PDT) From: Laurent Toutain Date: Mon, 10 Jul 2017 14:18:40 +0200 X-Gmail-Original-Message-ID: Message-ID: To: lp-wan , hackathon@ietf.org Content-Type: multipart/alternative; boundary="f403045ddb00b885650553f597db" Archived-At: Subject: [lp-wan] interop on SCHC 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, 10 Jul 2017 12:19:33 -0000 --f403045ddb00b885650553f597db Content-Type: text/plain; charset="UTF-8" Hi, We just release a short note describing the network architecture for LPWAN connectivity during the hackathon. It is available here: https://github.com/ltn22/hackathonSCHC See you in Prague. Laurent --f403045ddb00b885650553f597db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We just release a short no= te describing the network architecture for LPWAN connectivity during the ha= ckathon.

It is available here: https://github.com/ltn22/hackathonSCHC

See you in Prague.

Laurent
--f403045ddb00b885650553f597db-- From nobody Mon Jul 10 06:50: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 D23471270A0 for ; Mon, 10 Jul 2017 06:50:32 -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 w8pxf8E_xG5T for ; Mon, 10 Jul 2017 06:50:30 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 BD22112702E for ; Mon, 10 Jul 2017 06:50:29 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id k67so139321094wrc.2 for ; Mon, 10 Jul 2017 06:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=actility.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5Tn3S5XD7txp9uwiRjkCS9vZ2DaEo67RQylhBC4n7s8=; b=JcTOvpOsJyVRBBigZds0A0nMjwEa7xhHXPNQeeGrHmytPI7bpu8p3+MMng0Azvv/8l Qg9Ig7o4MLoohHwBbbd67VafELBOI7hz2c+giBlpPBkqBDcN0V0ZCkOWDhBxe/eQRD5H VC7DuHlxkNqPG60VVhfnsEFzrsdRpJ8Gvm8eU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5Tn3S5XD7txp9uwiRjkCS9vZ2DaEo67RQylhBC4n7s8=; b=TEOuCxl6mSPVGPe+QavzeNnRgun2aVkksWRMXgUFSBApbimbyJy2i+f+4nB4n/Mi6P CNu8ZP2Bi9gY7N7BYASHIsQ5h5b7qbvnf7NQSVsHLGYYQ79tjhZu81Vb1Evg0wvLIg4W vtT/iALnkYDX/dd/HVARqtX3sPQ0DqDKOTKdwXpPEUGzctQYUQ16r2ZwaA81SPGCk9hF HaRN+k4WnFc9ljVUfJ7zyKzRQncmA4QnJ/NjgcfmMp70cT1+7xiYGwWhbQUb7VjA64IL tvaI4ZpmWMcsHuNR1NUU/4T/k+5ByvW+p1EaJW21nD15zs9eZNrP0QTSqZ03CmqBkkPN RP8w== X-Gm-Message-State: AIVw113rsL0S02IgarLfuK6npdvGZl/FHBliiVI6Y9m+ga/mpwgknMqp acn8MWAyPfzFq1edGO1uXw== X-Received: by 10.28.131.130 with SMTP id f124mr7808928wmd.25.1499694628137; Mon, 10 Jul 2017 06:50:28 -0700 (PDT) Received: from [192.168.2.182] ([88.234.3.191]) by smtp.gmail.com with ESMTPSA id 9sm13099370wml.25.2017.07.10.06.50.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 06:50:27 -0700 (PDT) From: Alper Yegin Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_64203639-6402-4135-B063-A3509886BAA0" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 10 Jul 2017 16:50:25 +0300 In-Reply-To: <88a4a10c-6abf-efeb-0430-da9cbf24b5a9@cs.tcd.ie> Cc: lp-wan@ietf.org To: Stephen Farrell References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie> <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> <88a4a10c-6abf-efeb-0430-da9cbf24b5a9@cs.tcd.ie> 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: Mon, 10 Jul 2017 13:50:33 -0000 --Apple-Mail=_64203639-6402-4135-B063-A3509886BAA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Stephen, > I suspect this is one of those where we'll only understand > one another f2f, but=E2=80=A6 One more try over email. If still not clear, we can chat over the phone. = I won=E2=80=99t be at IETF this time unfortunately. When confronted by a Join-request, the NS needs to figure out how to = authenticate the request. If the NS can recognize the DevEUI, then it=E2=80=99d know how to do the = auth (e.g., by locally, or by forwarding to an external JS for that = given DevEUI entry). If the NS cannot recognize the DevEUI, then it resorts to AppEUI (or = JoinEUI, both are different names for the exact same field in the = Join-Request =E2=80=94 name change happening in revisions). = AppEUI/JoinEUI tells the NS who can authenticate that request (a = local/co-located JS, or an external JS identified by the = AppEUI/JoinEUI). The confusion is arising from the evolving name and semantics of that = field. At any rate, LW1.0.2 says:=20 "The AppEUI is a global application ID in IEEE EUI64 address space that = uniquely identifies the entity able to process the JoinReq frame." In my emails I=E2=80=99ve been highlighting the essential/underlined = role of the AppEUI field.=20 Alper > On Jul 1, 2017, at 10:40 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > I suspect this is one of those where we'll only understand > one another f2f, but... >=20 > On 01/07/17 20:18, Alper Yegin wrote: >> Hi Stephen, >>=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 >>> So I just don't understand how that can be correct, sorry;-) >>>=20 >>> A join-request is processed by a NS (or, in 1.1 a JS). There are = very >>> few of those, maybe 1 per n/w. There are many more device-types, = which >>> do mostly map 1:1 with AppEUIs. And the same device-types can be = found >>> in many networks. >>>=20 >>> So the suggested text just seems incorrect to me. >>>=20 >>> I'd say we're better to just stick with 1.0.2 terms tbh. >>>=20 >>=20 >> If we want to strictly stick with the LW1.0.2 definition, than = it=E2=80=99d be: >>=20 >> AppEUI IEEE EUI64 application id that identifies the entity = processesing Join-request >>=20 >=20 > Just to note: the above doesn't help me. I read it as the same as > your previous suggested text, and hence, for me, it just reads like > a false statement. (I don't mean badly worded, I mean untrue:-) >=20 >> In practice, it identifies the JS. >=20 > Let me try explain why I don't get that. >=20 > Each instance of some class of device will have the same AppEUI, > call that "X." Let's say there are 10^5 instances of devices > like that. >=20 > Let's say there are 2 LoRaWAN networks, each with an NS that has > a co-located NS. With half the "X" type devices in each. >=20 > Both networks (call them N1, N2) have devices of the type that > uses AppEUI X. >=20 > There is a 5000:1 ratio between instances of X and NS's/JS's > in each network. >=20 > X therefore does not identify an NS or JS or anything like that. >=20 > Do you see why I'm confused if you want to say that X identifies > or names the JS? >=20 > Cheers, > S. >=20 >>=20 >> Note that: >> - NS and JS may be co-located or separated. This is true for both = LW1.0.x and LW1.1 specs. >> - The entity that processes the Join-request and generates = Join-accept is the JS. >> - Single NS may be connected to multiple JSs. >> - Spec is based on 1:1 relationship between the end-device and JS. = (Obviously, implementations can extend that). >> - If the NS knows the identify of the JS to process an incoming = Join-request based on the DevEUI, then AppEUI (which is later renamed to = JoinEUI in LW1.1) has no significance. Otherwise, the NS relies on the = AppEUI (JoinEUI) to identify the JS to process the request. >>=20 >> I just elaborated on these details, not to suggest including in the = draft, but to point out that the significance of the AppEUI is to =E2=80=9C= identify(ies) the entity able to process the JoinReq frame.=E2=80=9D as = stated in the LW1.0.2 spec. As long as we capture that, it is OK if the = draft also refers to it as =E2=80=9Capplication id=E2=80=9D. (The reason = name of the Join-request field morphed from AppEUI into JoniEUI in LW1.1 = is basically this.) >>=20 >> Regards, >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> Cheers, >>> S. >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Thanks Stephen. >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> lp-wan mailing list >>>> lp-wan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lp-wan >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan = --Apple-Mail=_64203639-6402-4135-B063-A3509886BAA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Stephen,

I suspect this is one = of those where we'll only understand
one another f2f, = but=E2=80=A6

One = more try over email. If still not clear, we can chat over the phone. I = won=E2=80=99t be at IETF this time unfortunately.

When confronted by a Join-request, the NS needs to figure out = how to authenticate the request.
If the NS can = recognize the DevEUI, then it=E2=80=99d know how to do the auth (e.g., = by locally, or by forwarding to an external JS for that given DevEUI = entry).
If the NS cannot recognize the DevEUI, then = it resorts to AppEUI (or JoinEUI, both are different names for the exact = same field in the Join-Request =E2=80=94 name change happening in = revisions). AppEUI/JoinEUI tells the NS who can authenticate that = request (a local/co-located JS, or an external JS identified by the = AppEUI/JoinEUI).

The confusion is arising from the evolving name and semantics = of that field.

At any rate, LW1.0.2 says: 

"The AppEUI is a global application ID in IEEE = EUI64 address space that uniquely identifies the entity able to process the JoinReq = frame."

In = my emails I=E2=80=99ve been highlighting the essential/underlined role = of the AppEUI field. 




Alper















On Jul 1, 2017, at 10:40 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

I suspect this is one of those where = we'll only understand
one another f2f, but...

On 01/07/17 20:18, Alper Yegin = wrote:
Hi Stephen,



 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.


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

So I just don't understand how = that can be correct, sorry;-)

A = join-request is processed by a NS (or, in 1.1 a JS). There are very
few of those, maybe 1 per n/w. There are many more = device-types, which
do mostly map 1:1 with AppEUIs. And = the same device-types can be found
in many networks.

So the suggested text just seems incorrect to = me.

I'd say we're better to just stick with = 1.0.2 terms tbh.


If we want to strictly  stick with the LW1.0.2 = definition, than it=E2=80=99d be:

AppEUI IEEE = EUI64 application id that identifies the entity processesing = Join-request


Just to note: the = above doesn't help me. I read it as the same as
your previous = suggested text, and hence, for me, it just reads like
a false statement. = (I don't mean badly worded, I mean untrue:-)

In practice, it identifies = the JS.

Let me try explain why I don't get = that.

Each instance of = some class of device will have the same AppEUI,
call that "X." = Let's say there are 10^5 instances of devices
like = that.

Let's say there are = 2 LoRaWAN networks, each with an NS that has
a co-located NS. = With half the "X" type devices in each.

Both networks (call them N1, N2) have devices of = the type that
uses AppEUI X.

There is a 5000:1 ratio between instances of X = and NS's/JS's
in each network.

X therefore does not identify an NS or JS or = anything like that.

Do you see why I'm confused if you want to say = that X identifies
or names the JS?

Cheers,
S.


Note that:
- NS and JS may be co-located or separated. This is true for = both LW1.0.x and LW1.1 specs.
- The entity that processes = the Join-request and generates Join-accept is the JS.
- = Single NS may be connected to multiple JSs.
- Spec is = based on 1:1 relationship between the end-device and JS. (Obviously, = implementations can extend that).
- If the NS knows the = identify of the JS to process an incoming Join-request based on the = DevEUI, then AppEUI (which is later renamed to JoinEUI in LW1.1) has no = significance. Otherwise, the NS relies on the AppEUI (JoinEUI) to = identify the JS to process the request.

I = just elaborated on these details, not to suggest including in the draft, = but to point out that the significance of the AppEUI is to =E2=80=9C = identify(ies) the entity able to process the JoinReq frame.=E2=80=9D as = stated in the LW1.0.2 spec. As long as we capture that, it is OK if the = draft also refers to it as =E2=80=9Capplication id=E2=80=9D. (The reason = name of the Join-request field morphed from AppEUI into JoniEUI in LW1.1 = is basically this.)

Regards,

Alper







Cheers,S.





Thanks Stephen.

Alper



_______________________________________________
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=_64203639-6402-4135-B063-A3509886BAA0-- From nobody Mon Jul 10 07:28: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 61ED813144F for ; Mon, 10 Jul 2017 07:28:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 7u67hA2Aoqi7 for ; Mon, 10 Jul 2017 07:28:01 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 C5E1F127078 for ; Mon, 10 Jul 2017 07:28:00 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id f194so28495942yba.3 for ; Mon, 10 Jul 2017 07:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=wvDytRKRKcajqRyJK/WefuvR0Rk+K0Jkp5kRdzDvwmc=; b=V493gXszXNy6JiVOUTV0y7eAIcB+e+jQE/kL6MSzCp7ZXF8WJWvEtHDOzRAJdYQ4ms HPSgXGmA7Di9MAVlDhnty/JYcKVO8/NfUhwivQXuNDHu/xXc5ckpqQFsaiAXDQqdCpos aMciYzZrjvOl2s6E7GVb8+HTF8w51po7T5NnO+RW13KplPixln//J6NiPEY5agH4wsjf iEzYR+s8cCY3hRIXBxvU41c/KwSkdZG63k0uK31nt0HHrAX1Z6H1swho9WVwzxC+q3p7 ml26DV8gnjcE8w5VM86UC8bzou9AMx+z2qY0gxoY7kvPlTMILlp9r9XgpgU5T5wq5hqb DkrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wvDytRKRKcajqRyJK/WefuvR0Rk+K0Jkp5kRdzDvwmc=; b=ZX+ETFtTArcdIfUx087VeCwBDeASIjwRB09X7N+c0lbOtydoXTwM3jeS6l+S85IIfg 4wR3v4tGT+4sWlWTSjnjM2604zHUJRPhZ3MGCrwKUB3bbHdd1HI38lfg+V9TTmg6cOG2 a8RxvlR7vv2stu9Hfg5zYSneVpc+XAR4nfX5rFtYG+zIn+/mA45/QvT+UQaoXaFKLvIG UnmRke4cDBkJ6qr6c0jjxp6YlNgr8IvIvCsQHiz0vFUtXimWByJEIwCTMA7YgX0TOOqR wd0Y2SAiSjvxc00E1YLmTzt56W1SPils+ErfaE2ODayNpB2gmFmNKWA0mBQIxE8dib5G pG4w== X-Gm-Message-State: AIVw110YxceWGjxzwfid+pLWqfyRHfMF7Elk9QY4DCZLZ+Js/Y6Xv+4d Z3FaGnYYP9M2Eq770nwk4MP8r/EbeExRbQA= X-Received: by 10.37.54.4 with SMTP id d4mr15871557yba.33.1499696878245; Mon, 10 Jul 2017 07:27:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.175.19 with HTTP; Mon, 10 Jul 2017 07:27:37 -0700 (PDT) From: "Prof. Diego Dujovne" Date: Mon, 10 Jul 2017 16:27:37 +0200 Message-ID: To: lp-wan Content-Type: multipart/alternative; boundary="94eb2c1b0edeb30ca70553f76332" Archived-At: Subject: [lp-wan] Comments on draft-ietf-lpwan-ipv6-static-context-hc-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: Mon, 10 Jul 2017 14:28:03 -0000 --94eb2c1b0edeb30ca70553f76332 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I attach below the comments on the SCHC draft until the end of section 8. I will follow up with the rest of the draft later. Regards, Diego Abstract: -"A common context stored in a LPWAN device and in the network is used." Although this is still the Abstract, it is not clear how a common context will be stored in the network. -"In most of the cases, IPv6/UDP headers are reduced to a small identifier called Rule ID. But sometimes the SCHC header compression mechanisms will not be enough to send the compressed packet in one L2 PDU, so the SCHC Fragmentation protocol must be used when needed." There is an intermediate condition where the rest of the headers can be transmitted without changing using fragmentation. -"Moreover, this document specifies fragmentation and reassembly mechanim for SCHC" "A fragmentation and reassembly mechaniSm" - "information with LPWAN" "information with a WAN" - "LPWAN Radio Network (RG)" What is ithe G standing for? - "A Matching Operator (MO) is the operator used to make the comparison between the Field Value" The Field Value is not defined in the terminology section - "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." The direction indicator defines Dw when it signals an Downlink message, and Up when it signals an Uplink message. What would be a compression from an Downlink to an Uplink? - "In the Up situation only the Rule-ID is used." Does this mean that when a node communicates with the Gateway, only the Rule-ID is used given that another form of ID is transmitted on the packet on L2? What if there is no device ID in the L2 layer? - "Next, then the fields" It is either Next or then. - "and the SCHC take next Rule." "takes" - "Otherwise the next rule is tested." "Otherwise, " - "Decompession Actions" Decompression - "layer two" Throughout the document, L2 is mentioned either in words or with the acronym. It should be uniform. - "A matching is obtained" "A match is obtained" - "target value", "TV", "Target Value" One of the options should be chosen, it is not used uniformly on the document. - "compression of headers fields" "compression of header fields" - "TV OR received value" should it be in capitals? - "If the DiffServ field identified by the rest of the rule do not vary" "If the DiffServ field identified by the rest of the rule does not vary" - "CDA must be "not-sent." Missing a " - "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:" "the first one is not to compress the field and send the original value, or the second where the values can be computed by sending only the LSB bits:" - "is not derivated from an" "derived" - "then the TV contains the list of possible IIDs," "then the TV contains the list of all possible IIDs," --=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 --94eb2c1b0edeb30ca70553f76332 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 I attach below the comments on the SCHC draft
until the en= d of section 8. I will follow up with the rest of
the draft later= .
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=A0Diego

Abstract:

-"A common context stored in a LPWAN device and in the network is used."

Although this i= s still the Abstract, it is not clear how a common context will
b= e stored in the network.

-"In most of the cas= es, IPv6/UDP headers are reduced to a small identifier called Rule ID. But sometimes the SCHC header compression mechanisms will not be enough to send the compressed packet in one L2 PDU, so the SCHC Fragmentation protocol must be used when needed."

There is an intermediate condi= tion where the rest of the headers can be transmitted without changing usin= g fragmentation.

-"Moreover, this document sp= ecifies fragmentation and reassembly mechanim for SCHC"

"A fragmentation and reasse= mbly mechaniSm"

- "information with LPWA= N"

"information with =C2=A0a WAN"

- "LPWAN Radio Network (RG)"

What is ithe G standing for?

- "A Matching Operator (MO) is the operator us= ed to make the comparison between the Field Value"=C2=A0

Th= e Field Value is not defined in the terminology section

- "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."=C2=A0

The direction indicator defines Dw when it signals an Dow= nlink message, and Up when it signals an Uplink message. What would be a co= mpression from an Downlink to an Uplink?

- "I= n the Up situation only the Rule-ID is used."=C2=A0

D= oes this mean that when a node communicates with the Gateway, only the Rule= -ID is used given that another form of ID is transmitted on the packet on L= 2?=C2=A0 What if there is no device ID in the L2 layer?

- "Next, then the fields"=C2=A0

It= is either Next or then.

- =C2=A0"and the SCH= C take next Rule."

"takes"

- "Otherwise the next rule is tested."

"Otherwise, "

- =C2=A0&q= uot;Decompession Actions"

Decompression
=

- "layer two"

Throug= hout the document, L2 is mentioned either in words or with the acronym. It = should be uniform.

- "A matching is obtained&= quot;

"A match is obtained"
- "target value", "TV", "Target Value= "

One of the options should be chosen, it is = not used uniformly on the document.

- "compre= ssion of headers fields"

"compression of= header fields"

- "TV OR received value&= quot;

should it be in capitals?
- "If the DiffServ field identified by the rest of the rul= e do not vary"

"If the DiffServ field id= entified by the rest of the rule does not vary"

- "CDA must be "not-sent."

Missi= ng a "

- "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:"
=

"the first one is not to compress the field and se= nd the original value, or the second where the values can be computed by sending only the LSB bits:"
=

- "is not derivated from an"
"derived"

- "then the = TV contains the list of possible IIDs,"

"then the TV contains t= he list of all possible IIDs,"



--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform= =C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Universida= d Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
--94eb2c1b0edeb30ca70553f76332-- From nobody Tue Jul 11 08:36:17 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 5128E12F3D3 for ; Tue, 11 Jul 2017 08:36:16 -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 HGeOQ2B1z4fc for ; Tue, 11 Jul 2017 08:36:13 -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 B381F126C3D for ; Tue, 11 Jul 2017 08:36:12 -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 v6BFaAaQ004042; Tue, 11 Jul 2017 17:36:10 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 2C4C71D53C1; Tue, 11 Jul 2017 17:36:09 +0200 (CEST) Received: from 2.136.180.139 by webmail.entel.upc.edu with HTTP; Tue, 11 Jul 2017 17:36:07 +0200 Message-ID: <081c78ebcec02853bf5c92d5742b4cd1.squirrel@webmail.entel.upc.edu> In-Reply-To: <18126_1499245891_595CAD43_18126_64_1_D58186B6.457FB%dominique.barthel@orange.com> References: <149892867732.532.13514525150008761783@ietfa.amsl.com> <18126_1499245891_595CAD43_18126_64_1_D58186B6.457FB%dominique.barthel@orange.com> Date: Tue, 11 Jul 2017 17:36:07 +0200 From: "Carles Gomez Montenegro" To: dominique.barthel@orange.com 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: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Tue, 11 Jul 2017 17:36:10 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.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: Tue, 11 Jul 2017 15:36:16 -0000 Hello Dominique, First of all, thank you very much for such a thorough, comprehensive, and constructive review! All comments (except two) have led to respective updates in the working version of the document: https://github.com/lp-wan/ip-compression Some of the updates have been included in this email as well. Below, "Agreed" can be understood as "Agreed and update done". Please find inline responses below. > Hello all, > > I have reviewed the "Fragmentation" part (Section 9, Appendices A and B) > of this draft and I have the following comments. > > "highest CFN in the window" > This notion is introduced in 9.5.2, in the subsection that describes the > CFN field. > At this point in the text, it is not clear who picks the value of > "highest CFN in the window", if it is a constant or how it is conveyed to > the receiver if it is variable. > Only when reading section 9.7 does one understand that it is a constant > that is known as part of the context and that multiple values may be > supported by ways of different rule Ids. > However, "highest CFN in the window" is not listed at the bottom of > 9.5.2 along with R, N, T and M that are constants to be defined in other > documents. > I think "highest CFN in the window" deserves a short name and a > notation, and it should be listed along with R, N, T and M at the bottom > of 9.5.2. Agreed. Proposed notation: MAX_WIND_FCN. The setting for MAX_WIND_FCN has been added as well in the examples in Appendix A. > The explanation at the bottom of 9.5.3 as to why one could want a > "highest CFN in the window" value that is not CFN=2^N-2 (56 bits in the > example) is very useful. Thanks. Added a pointer in 9.5.2 so that the explanation in 9.5.3 can be found more easily by a reader. > Furthermore, I think that it would be advantageous that, in the > examples, at least one example use a "highest CFN in the window" value > that is not CFN=2^N-2. Agreed. An example has been added at the end of Appendix A. > Correction : in Section 9.6, replace > OLD TEXT > "Note that, in Window mode, the first fragment of the window is the > one with CFN=2^N-2." > NEW TEXT > "Note that, in Window mode, the first fragment of the window is the one > with "highest CFN in the window"". Agreed, applied this change as: “Note that, in Window mode, the first fragment of the window is the one with FCN set to MAX_WIND_FCN” > Section 9.6, Baseline mechanism, description of reassembly buffer > "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 order to place fragment at the appropriate location in the reassembly > buffer, how does one know the size of preceding fragments that have been > lost? Are fragments supposed to be all of the same size? > Does a specific rule Id mandate a fragment size? Is this behaviour to be > specified in "other documents"? Fragments are not required/supposed to be of the same size. Maybe the following text should suffice? NEW: For example, it may place the data payload of the fragments within a payload datagram reassembly buffer, based on the CFN and order of arrival of the fragments. However, implementers need to be aware that fragments are not supposed to be all of the same size. > "It uses the CFN and the order of arrival of each fragment to determine > the location" > Maybe an explanation of why the CFN *and* the order or arrival? I guess > you are referring to the No ACK mode where CFN is constant but for the > last fragment? > Do we agree that in Window mode, CFN and W unambiguously determine > location in the reassembly buffer? The No ACK mode is indeed one reason for why the FCN *and* the order of arrival are mentioned. I understand you mean that in Window mode, the receiver will suffer no ambiguity to determine the location of a fragment in a reassembly buffer, and I agree. However, strictly speaking, maybe at an abstract level, the FCN and W alone do not unambiguously determine the location of a fragment, since e.g. an IPv6 packet comprising three or more windows may transmit two or more different fragments with the same CFN and W values. > Section 9.6, Baseline mechanism, description of Window mode - ACK on error > "Upon expiration of the "ACK on Error Timer", if the receiver knows that > at least one fragment of the current window has been lost Š² > If the "ACK on Error Timer" expires at the receiver, then it knows that > at least the last fragment is assumed to have been lost, correct? > Therefore, the "if the receiver knows that at least one fragment of the > current window has been lost" clause is irrelevant and can be removed from > the text. Agreed, although an addition is needed to state that: When the last fragment of the IPv6 datagram is received, if all fragments of that last window of the packet have been received, the “ACK on Error Timer” is stopped. > The description of ³Window mode - ACK on error² does not mention > MAX_FRAG_RETRIES. My understanding of ³Window mode - Ack on error² is that > it would benefit from the same MAX_FRAG_RETRIES mechanism. > In ³Window mode - ACK on error², the ACK cannot be used for flow control. > The draft does not provide recommendations on when a sender can forget > about a window that it has sent, and reallocate the window number (1 bit) > to a new window. Nor does it provide recommendation about forgetting about > the last window of an IPv6 packet. See for example Figures 17 and 18 in > Appendix A. I¹m assuming that a sender implementation would want to wait > for a reasonable time before forgetting about a window, just in case an > ACK on error would be received shortly. Should this be described here? Proposed new text follows. NEW: In Window mode – ACK on error, when a fragment sender has transmitted the last fragment of a window, or it has retransmitted the last fragment within the set of lost fragments reported in an ACK, it is assumed that the time the fragment sender will wait to receive an ACK is smaller than the transmission time of MAX_WIND_FCN + 1 fragments (i.e. the time required to transmit a complete window of fragments). This aspect must be carefully considered if Window mode – ACK on error is used, in particular taking into account the latency characteristics of the underlying L2 technology. With regard to MAX_FRAG_RETRIES, please see another response below. > Section 9.6, Baseline mechanism, description of MIC processing at the end > of reassembly > ³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.² > The following sentences state that in either Window mode, the ACK > conveys information about fragments of the last window that have been > correctly received or not received. (Incidentally, these sentences are > redundant with the same text in the third and fifth paragraphs of the same > section 9.6. Do we need both?) Agreed that these are redundant and not needed. > Nothing is said about what to do, in Window mode, when the MIC does not > match. For completeness, I suggest we write that the reassembled IPv6 > datagram MUST be discarded, and simply state that an ACK is sent with the > same behaviour than for any other window. Agreed that we need to refer explicitly to Window mode. A problem is that if at the first MIC check the IPv6 datagram is discarded, then we miss the opportunity to hopefully recover the IPv6 datagram by retransmitting the missing fragment(s) from the last window. Therefore, the following new text is proposed: NEW: In Window mode, a MIC check is also performed by the fragment receiver after reception of a round of retransmitted fragments. If the MIC check still fails after the last round of fragments retransmitted by the fragment sender (which may have been received or not by the fragment receiver), the reassembled IPv6 packet is discarded. Note that the fragment receiver will need to determine when it is safe to assume that no more fragments will be received. Further guidance on this is expected to be provided in future (possibly technology-specific) documents. Note also that, in Window mode, the rules that apply for constructing and transmitting an ACK for the last window are the same rules that apply for any other window. > Appendix B, allocation of Rule IDs for fragmentation > I suggest to modify the section title to ³Allocation of Rule IDs for > fragmentation². Agreed. > This section should be rewritten. I suggest: > ³A set of Rule IDs are allocated to support different aspects of > fragmentation > functionality as per this document. The allocation of IDs is to be > defined in other documents. The set MAY include: > > o one ID or a subset of IDs to identify a fragment as well as its > reliability option and its window size, if multiple of these are supported > > o one ID to identify the ACK message. > > o one ID to identify the Abort message as per Section 9.8.² Agreed. > Do we agree with the ³one ID² in the last two items, or are there use > cases that I don¹t see that would justify for multiple IDs ? For ACKs, my understanding is that one ID is sufficient. For Abort, we discussed in one of the past interims that there might be reasons to support different options (e.g. abort all on-going, possibly interleaved, transmissions vs some more fine-grained behavior). We decided at the time that we would go for the most simple approach to just use one ID to abort all on-going transmissions. > Various nits > * Section 3, Terminology. CFN is not listed. Also add the other acronyms > (DTag, MIC, etc.) used in the fragmentation section. Agreed. > * Section 9.2: MAX_FRAG_RETRIES is described for the Window mode - ACK > ³always². For completeness, the same text should be repeated for the > Window mode - ACK on error. I think your proposal is one possible approach. Another approach, which is the current one in the draft (and may need to be discussed) is that in “ACK on error”, the maximum number of retransmission rounds will be controlled by the receiver by means of MAX_ACKS_PER_WINDOW, while the sender will retransmit any fragments reported to be lost in an ACK. Otherwise, in some situations, the receiver may unnecessarily send ACKs while the sender will not reply (with fragment retries) to those if it has reached its maximum number of retries. The receiver does not necessarily know the MAX_FRAG_RETRIES value of the sender. Thoughts? > * Section 9.4: Rule ID description. Add the use of Rule ID for conveying > the window size if multiple sizes are supported. > OLD TEXT > ³Rule ID may also be used to signal which reliability option is in use > for the IPv6 packet being carried.² > NEW TEXT > ³Rule ID may also be used to signal which reliability option is in use > for the IPv6 packet being carried. Rule ID may also be used to signal the > window size if multiple sizes are supported (see 9.7).² Agreed. > * Section 9.4: ³Compressed Fragment Number². ³Compressed² refers to the > number, not to the fragment, since uncompressed packet can also be > fragmented with this mechanism. > To remove this ambiguity, rename CFN to Fragment Compressed Number > (FCN)? > CFN/FCN should be listed in the Terminology section. Agreed. > The part of the sentence ³, and does not necessarily carry an absolute > fragment number.² should be rewritten as ³, and does not carry an absolute > fragment number.². Indeed, CFN counts down from "highest CFN in the > window" anyway, so the chances that it corresponds to an absolute fragment > number are null. Agreed. > See as well my comment on text regarding CFN in 9.5.2 > * Section 9.5.2: Remove ³, and thus the CFN does not strictly correspond > to the N least significant bits of the actual absolute fragment number.². > It does not strictly correspond, nor loosely. Agreed. > * Section 9.5.3: ²Absence of the bitmap in an ACK confirms correct > reception of all fragments to be acknowledged by means of the ACK." > For the wondering soul, maybe explain that the absence is noticed by > looking at the L2 size, since it doesn't immediately show from Figure 13. Agreed. > * Section 9.6: "if no ACK has been received since the timer start, the > sender retransmits the last fragment sent Š". Could refer to the last in > time or the last in order. > I guess the correct answer is the latter, i.e. the last fragment of the > IPv6 packet. The sentence refers to the last fragment that has been sent at the moment of timer expiration, which could be: i) the last fragment of a window (i.e. FCN=0 or FCN=2^N-1), e.g. in the first round of fragment transmission attempts; or ii) the last fragment sent within a a round of retransmissions (which can be a fragment with any valid FCN for the current window). Proposed new text follows. NEW Upon expiration of the timer, if no ACK has been received since the timer start, the sender retransmits the last fragment sent at the moment of timer expiration, and it reinitializes and restarts the timer. Note that the last fragment sent at the moment of timer expiration may be the last fragment of a window (i.e. FCN=0 or FCN=2^N-1) or the last fragment sent within a round of fragment retransmissions. > * Section 9.6: ³Similarly, when a node first receives Š ³. ³node² is not > part of the terminology. Do you mean a Device, or either end of the LPWAN > link ? Either end of the LPWAN link. > * Section 9.8, fragm/reassbly abortion > OLD TEXT > ³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.² > NEW TEXT > ³The entity (either the fragment sender or the fragment receiver) that > triggers abortion transmits to the other endpoint a packet that only > comprises a unique Rule ID (of size R bits), which signals abortion of all > on-going fragmented IPv6 packet transmissions.² Yes, “format” is not so suitable here... What about “data unit with an L2 payload” instead of “packet”? I’d like to avoid terminology confusion with an IPv6 packet... > * Section 10.2, security considerations for fragmentation > ³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.² > This is true of all LPWAN technologies. For example, LoRaWAN has source > authentication that allows a receiver distinguishing a random-payload > spoofed fragment from a legitimate one. Il also has a frame counter > mechanism that allows a receiver to discard later replay by an attacker of > a strictly identical message as send earlier by a legitimate node. > Therefore, the attack described here and its mitigation only applies to > certain LPWAN technologies. Agreed. OLD: A receiver cannot distinguish legitimate from spoofed fragments NEW: If the LPWAN technology does not support suitable protection (e.g. source authentication and frame counters to prevent replay attacks), a receiver cannot distinguish legitimate from spoofed fragments. > * Appendix A: ³Note: in Window mode, an additional bit will be needed to > number windows.². This comment is correct, but it is oddly placed in the > middle of the description of Figure 19 as if it didn¹t apply to the ³ACK > on error² mode as well. I think it is better to just remove the sentence. The “W” bit is now clearly defined in the document (the sentence pointed out made sense in an older version of the document, before the “W” bit was defined). Cheers, Carles > Best regards, > > Dominique From nobody Tue Jul 11 09:45: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 F3B85129AD7 for ; Tue, 11 Jul 2017 09:45:09 -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, FREEMAIL_FROM=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_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 aPqTvvXDj_UX for ; Tue, 11 Jul 2017 09:45:03 -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 676B9129B62 for ; Tue, 11 Jul 2017 09:45:03 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 1AA7B1805EC; Tue, 11 Jul 2017 18:45:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id E1C731C00C9; Tue, 11 Jul 2017 18:45:01 +0200 (CEST) Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0352.000; Tue, 11 Jul 2017 18:45:01 +0200 From: To: Carles Gomez Montenegro CC: "lp-wan@ietf.org" Thread-Topic: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.txt Thread-Index: AQHS+ltu0uh2O9pN+EqbHRlZJvn8FKJO1VsA Date: Tue, 11 Jul 2017 16:45:00 +0000 Message-ID: <21934_1499791502_5965008D_21934_319_2_D58AC998.46382%dominique.barthel@orange.com> References: <149892867732.532.13514525150008761783@ietfa.amsl.com> <18126_1499245891_595CAD43_18126_64_1_D58186B6.457FB%dominique.barthel@orange.com> <081c78ebcec02853bf5c92d5742b4cd1.squirrel@webmail.entel.upc.edu> In-Reply-To: <081c78ebcec02853bf5c92d5742b4cd1.squirrel@webmail.entel.upc.edu> 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.3] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-ipv6-static-context-hc-05.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: Tue, 11 Jul 2017 16:45:10 -0000 SGVsbG8gQ2FybGVzLA0KDQpUaGFua3MgdG8geW91IGZvciBhbGwgeW91ciBkZXRhaWxlZCBhbnN3 ZXJzLg0KQSBmZXcgcmVhY3Rpb25zIGlubGluZS4gVGhleSBhcmUgYWxsIHllcydlcywgYnV0IG9u ZSB0aGF0IEkgdGhpbmsgd2FycmFudHMNCmZ1cnRoZXIgZGlzY3Vzc2lvbi4NCkNoZWVycywNCg0K RG9taW5pcXVlDQoNCg0KTGUgMTEvMDcvMTcgMTc6MzYsIMKrIENhcmxlcyBHb21leiBNb250ZW5l Z3JvIMK7IDxjYXJsZXNnb0BlbnRlbC51cGMuZWR1PiBhDQrDqWNyaXQgOg0KDQo+SGVsbG8gRG9t aW5pcXVlLA0KPg0KPkZpcnN0IG9mIGFsbCwgdGhhbmsgeW91IHZlcnkgbXVjaCBmb3Igc3VjaCBh IHRob3JvdWdoLCBjb21wcmVoZW5zaXZlLCBhbmQNCj5jb25zdHJ1Y3RpdmUgcmV2aWV3IQ0KPg0K PkFsbCBjb21tZW50cyAoZXhjZXB0IHR3bykgaGF2ZSBsZWQgdG8gcmVzcGVjdGl2ZSB1cGRhdGVz IGluIHRoZSB3b3JraW5nDQo+dmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQ6DQo+aHR0cHM6Ly9naXRo dWIuY29tL2xwLXdhbi9pcC1jb21wcmVzc2lvbg0KPg0KPlNvbWUgb2YgdGhlIHVwZGF0ZXMgaGF2 ZSBiZWVuIGluY2x1ZGVkIGluIHRoaXMgZW1haWwgYXMgd2VsbC4gQmVsb3csDQo+IkFncmVlZCIg Y2FuIGJlIHVuZGVyc3Rvb2QgYXMgIkFncmVlZCBhbmQgdXBkYXRlIGRvbmUiLg0KPg0KPlBsZWFz ZSBmaW5kIGlubGluZSByZXNwb25zZXMgYmVsb3cuDQo+DQo+PiBIZWxsbyBhbGwsDQo+Pg0KPj4g SSBoYXZlIHJldmlld2VkIHRoZSAiRnJhZ21lbnRhdGlvbiIgcGFydCAoU2VjdGlvbiA5LCBBcHBl bmRpY2VzIEEgYW5kIEIpDQo+PiBvZiB0aGlzIGRyYWZ0IGFuZCBJIGhhdmUgdGhlIGZvbGxvd2lu ZyBjb21tZW50cy4NCj4+DQo+PiAiaGlnaGVzdCBDRk4gaW4gdGhlIHdpbmRvdyINCj4+ICAgVGhp cyBub3Rpb24gaXMgaW50cm9kdWNlZCBpbiA5LjUuMiwgaW4gdGhlIHN1YnNlY3Rpb24gdGhhdCBk ZXNjcmliZXMNCj4+dGhlDQo+PiBDRk4gZmllbGQuDQo+PiAgIEF0IHRoaXMgcG9pbnQgaW4gdGhl IHRleHQsIGl0IGlzIG5vdCBjbGVhciB3aG8gcGlja3MgdGhlIHZhbHVlIG9mDQo+PiAiaGlnaGVz dCBDRk4gaW4gdGhlIHdpbmRvdyIsIGlmIGl0IGlzIGEgY29uc3RhbnQgb3IgaG93IGl0IGlzIGNv bnZleWVkDQo+PnRvDQo+PiB0aGUgcmVjZWl2ZXIgaWYgaXQgaXMgdmFyaWFibGUuDQo+PiAgIE9u bHkgd2hlbiByZWFkaW5nIHNlY3Rpb24gOS43IGRvZXMgb25lIHVuZGVyc3RhbmQgdGhhdCBpdCBp cyBhDQo+PmNvbnN0YW50DQo+PiB0aGF0IGlzIGtub3duIGFzIHBhcnQgb2YgdGhlIGNvbnRleHQg YW5kIHRoYXQgbXVsdGlwbGUgdmFsdWVzIG1heSBiZQ0KPj4gc3VwcG9ydGVkIGJ5IHdheXMgb2Yg ZGlmZmVyZW50IHJ1bGUgSWRzLg0KPj4gICBIb3dldmVyLCAiaGlnaGVzdCBDRk4gaW4gdGhlIHdp bmRvdyIgaXMgbm90IGxpc3RlZCBhdCB0aGUgYm90dG9tIG9mDQo+PiA5LjUuMiBhbG9uZyB3aXRo IFIsIE4sIFQgYW5kIE0gdGhhdCBhcmUgY29uc3RhbnRzIHRvIGJlIGRlZmluZWQgaW4gb3RoZXIN Cj4+IGRvY3VtZW50cy4NCj4+ICAgSSB0aGluayAiaGlnaGVzdCBDRk4gaW4gdGhlIHdpbmRvdyIg ZGVzZXJ2ZXMgYSBzaG9ydCBuYW1lIGFuZCBhDQo+PiBub3RhdGlvbiwgYW5kIGl0IHNob3VsZCBi ZSBsaXN0ZWQgYWxvbmcgd2l0aCBSLCBOLCBUIGFuZCBNIGF0IHRoZSBib3R0b20NCj4+IG9mIDku NS4yLg0KPg0KPkFncmVlZC4gUHJvcG9zZWQgbm90YXRpb246IE1BWF9XSU5EX0ZDTi4gVGhlIHNl dHRpbmcgZm9yIE1BWF9XSU5EX0ZDTiBoYXMNCj5iZWVuIGFkZGVkIGFzIHdlbGwgaW4gdGhlIGV4 YW1wbGVzIGluIEFwcGVuZGl4IEEuDQo+DQo+PiAgIFRoZSBleHBsYW5hdGlvbiBhdCB0aGUgYm90 dG9tIG9mIDkuNS4zIGFzIHRvIHdoeSBvbmUgY291bGQgd2FudCBhDQo+PiAiaGlnaGVzdCBDRk4g aW4gdGhlIHdpbmRvdyIgdmFsdWUgdGhhdCBpcyBub3QgQ0ZOPTJeTi0yICg1NiBiaXRzIGluIHRo ZQ0KPj4gZXhhbXBsZSkgaXMgdmVyeSB1c2VmdWwuDQo+DQo+VGhhbmtzLiAgQWRkZWQgYSBwb2lu dGVyIGluIDkuNS4yIHNvIHRoYXQgdGhlIGV4cGxhbmF0aW9uIGluIDkuNS4zIGNhbiBiZQ0KPmZv dW5kIG1vcmUgZWFzaWx5IGJ5IGEgcmVhZGVyLg0KPg0KPj4gICBGdXJ0aGVybW9yZSwgSSB0aGlu ayB0aGF0IGl0IHdvdWxkIGJlIGFkdmFudGFnZW91cyB0aGF0LCBpbiB0aGUNCj4+IGV4YW1wbGVz LCBhdCBsZWFzdCBvbmUgZXhhbXBsZSB1c2UgYSAiaGlnaGVzdCBDRk4gaW4gdGhlIHdpbmRvdyIg dmFsdWUNCj4+IHRoYXQgaXMgbm90IENGTj0yXk4tMi4NCj4NCj5BZ3JlZWQuIEFuIGV4YW1wbGUg aGFzIGJlZW4gYWRkZWQgYXQgdGhlIGVuZCBvZiBBcHBlbmRpeCBBLg0KPg0KPj4gICBDb3JyZWN0 aW9uIDogaW4gU2VjdGlvbiA5LjYsIHJlcGxhY2UNCj4+ICAgT0xEIFRFWFQNCj4+ICAgICAiTm90 ZSB0aGF0LCBpbiBXaW5kb3cgbW9kZSwgdGhlIGZpcnN0IGZyYWdtZW50IG9mIHRoZSB3aW5kb3cg aXMgdGhlDQo+PiBvbmUgd2l0aCBDRk49Ml5OLTIuIg0KPj4gICBORVcgVEVYVA0KPj4gICAgIk5v dGUgdGhhdCwgaW4gV2luZG93IG1vZGUsIHRoZSBmaXJzdCBmcmFnbWVudCBvZiB0aGUgd2luZG93 IGlzIHRoZQ0KPj5vbmUNCj4+IHdpdGggImhpZ2hlc3QgQ0ZOIGluIHRoZSB3aW5kb3ciIi4NCj4N Cj5BZ3JlZWQsIGFwcGxpZWQgdGhpcyBjaGFuZ2UgYXM6DQo+DQo+4oCcTm90ZSB0aGF0LCBpbiBX aW5kb3cgbW9kZSwgdGhlIGZpcnN0IGZyYWdtZW50IG9mIHRoZSB3aW5kb3cgaXMgdGhlDQo+ICAg b25lIHdpdGggRkNOIHNldCB0byBNQVhfV0lORF9GQ07igJ0NCj4NCj4+IFNlY3Rpb24gOS42LCBC YXNlbGluZSBtZWNoYW5pc20sIGRlc2NyaXB0aW9uIG9mIHJlYXNzZW1ibHkgYnVmZmVyDQo+PiAi Rm9yIGV4YW1wbGUsIGl0IG1heSBwbGFjZSB0aGUgZGF0YSBwYXlsb2FkIG9mIHRoZSBmcmFnbWVu dHMgd2l0aGluIGENCj4+IHBheWxvYWQgZGF0YWdyYW0gcmVhc3NlbWJseSBidWZmZXIgYXQgdGhl IGxvY2F0aW9uIGRldGVybWluZWQgZnJvbSB0aGUNCj4+Q0ZODQo+PiBhbmQgb3JkZXIgb2YgYXJy aXZhbCBvZiB0aGUgZnJhZ21lbnRzLCBhbmQgdGhlIGZyYWdtZW50IHBheWxvYWQgc2l6ZXMuIg0K Pj4gICBJbiBvcmRlciB0byBwbGFjZSBmcmFnbWVudCBhdCB0aGUgYXBwcm9wcmlhdGUgbG9jYXRp b24gaW4gdGhlDQo+PnJlYXNzZW1ibHkNCj4+IGJ1ZmZlciwgaG93IGRvZXMgb25lIGtub3cgdGhl IHNpemUgb2YgcHJlY2VkaW5nIGZyYWdtZW50cyB0aGF0IGhhdmUgYmVlbg0KPj4gbG9zdD8gQXJl IGZyYWdtZW50cyBzdXBwb3NlZCB0byBiZSBhbGwgb2YgdGhlIHNhbWUgc2l6ZT8NCj4+ICAgRG9l cyBhIHNwZWNpZmljIHJ1bGUgSWQgbWFuZGF0ZSBhIGZyYWdtZW50IHNpemU/IElzIHRoaXMgYmVo YXZpb3VyIHRvDQo+PmJlDQo+PiBzcGVjaWZpZWQgaW4gIm90aGVyIGRvY3VtZW50cyI/DQo+DQo+ RnJhZ21lbnRzIGFyZSBub3QgcmVxdWlyZWQvc3VwcG9zZWQgdG8gYmUgb2YgdGhlIHNhbWUgc2l6 ZS4gTWF5YmUgdGhlDQo+Zm9sbG93aW5nIHRleHQgc2hvdWxkIHN1ZmZpY2U/DQo+DQo+TkVXOg0K PiAgRm9yIGV4YW1wbGUsIGl0IG1heSBwbGFjZSB0aGUgZGF0YSBwYXlsb2FkIG9mIHRoZSBmcmFn bWVudHMgd2l0aGluIGENCj4gIHBheWxvYWQgZGF0YWdyYW0gcmVhc3NlbWJseSBidWZmZXIsIGJh c2VkIG9uIHRoZSBDRk4gYW5kIG9yZGVyIG9mDQo+YXJyaXZhbA0KPiAgb2YgdGhlIGZyYWdtZW50 cy4gSG93ZXZlciwgaW1wbGVtZW50ZXJzIG5lZWQgdG8gYmUgYXdhcmUgdGhhdCBmcmFnbWVudHMN Cj4gIGFyZSBub3Qgc3VwcG9zZWQgdG8gYmUgYWxsIG9mIHRoZSBzYW1lIHNpemUuDQpZZXMsIHRo aXMgc291bmRzIGdvb2QuDQoNCj4NCj4+ICJJdCB1c2VzIHRoZSBDRk4gYW5kIHRoZSBvcmRlciBv ZiBhcnJpdmFsIG9mIGVhY2ggZnJhZ21lbnQgdG8gZGV0ZXJtaW5lDQo+PiB0aGUgbG9jYXRpb24i DQo+PiAgIE1heWJlIGFuIGV4cGxhbmF0aW9uIG9mIHdoeSB0aGUgQ0ZOICphbmQqIHRoZSBvcmRl ciBvciBhcnJpdmFsPyBJDQo+Pmd1ZXNzDQo+PiB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUgTm8g QUNLIG1vZGUgd2hlcmUgQ0ZOIGlzIGNvbnN0YW50IGJ1dCBmb3IgdGhlDQo+PiBsYXN0IGZyYWdt ZW50Pw0KPj4gICBEbyB3ZSBhZ3JlZSB0aGF0IGluIFdpbmRvdyBtb2RlLCBDRk4gYW5kIFcgdW5h bWJpZ3VvdXNseSBkZXRlcm1pbmUNCj4+IGxvY2F0aW9uIGluIHRoZSByZWFzc2VtYmx5IGJ1ZmZl cj8NCj4NCj5UaGUgTm8gQUNLIG1vZGUgaXMgaW5kZWVkIG9uZSByZWFzb24gZm9yIHdoeSB0aGUg RkNOICphbmQqIHRoZSBvcmRlciBvZg0KPmFycml2YWwgYXJlIG1lbnRpb25lZC4gSSB1bmRlcnN0 YW5kIHlvdSBtZWFuIHRoYXQgaW4gV2luZG93IG1vZGUsIHRoZQ0KPnJlY2VpdmVyIHdpbGwgc3Vm ZmVyIG5vIGFtYmlndWl0eSB0byBkZXRlcm1pbmUgdGhlIGxvY2F0aW9uIG9mIGEgZnJhZ21lbnQN Cj5pbiBhIHJlYXNzZW1ibHkgYnVmZmVyLCBhbmQgSSBhZ3JlZS4gSG93ZXZlciwgc3RyaWN0bHkg c3BlYWtpbmcsIG1heWJlIGF0DQo+YW4gYWJzdHJhY3QgbGV2ZWwsIHRoZSBGQ04gYW5kIFcgYWxv bmUgZG8gbm90IHVuYW1iaWd1b3VzbHkgZGV0ZXJtaW5lIHRoZQ0KPmxvY2F0aW9uIG9mIGEgZnJh Z21lbnQsIHNpbmNlIGUuZy4gYW4gSVB2NiBwYWNrZXQgY29tcHJpc2luZyB0aHJlZSBvciBtb3Jl DQo+d2luZG93cyBtYXkgdHJhbnNtaXQgdHdvIG9yIG1vcmUgZGlmZmVyZW50IGZyYWdtZW50cyB3 aXRoIHRoZSBzYW1lIENGTiBhbmQNCj5XIHZhbHVlcy4NCj4NCj4+IFNlY3Rpb24gOS42LCBCYXNl bGluZSBtZWNoYW5pc20sIGRlc2NyaXB0aW9uIG9mIFdpbmRvdyBtb2RlIC0gQUNLIG9uDQo+PmVy cm9yDQo+PiAiVXBvbiBleHBpcmF0aW9uIG9mIHRoZSAiQUNLIG9uIEVycm9yIFRpbWVyIiwgaWYg dGhlIHJlY2VpdmVyIGtub3dzIHRoYXQNCj4+IGF0IGxlYXN0IG9uZSBmcmFnbWVudCBvZiB0aGUg Y3VycmVudCB3aW5kb3cgaGFzIGJlZW4gbG9zdCDFoMKyDQo+PiAgIElmIHRoZSAiQUNLIG9uIEVy cm9yIFRpbWVyIiBleHBpcmVzIGF0IHRoZSByZWNlaXZlciwgdGhlbiBpdCBrbm93cw0KPj50aGF0 DQo+PiBhdCBsZWFzdCB0aGUgbGFzdCBmcmFnbWVudCBpcyBhc3N1bWVkIHRvIGhhdmUgYmVlbiBs b3N0LCBjb3JyZWN0Pw0KPj4gVGhlcmVmb3JlLCB0aGUgImlmIHRoZSByZWNlaXZlciBrbm93cyB0 aGF0IGF0IGxlYXN0IG9uZSBmcmFnbWVudCBvZiB0aGUNCj4+IGN1cnJlbnQgd2luZG93IGhhcyBi ZWVuIGxvc3QiIGNsYXVzZSBpcyBpcnJlbGV2YW50IGFuZCBjYW4gYmUgcmVtb3ZlZA0KPj5mcm9t DQo+PiB0aGUgdGV4dC4NCj4NCj5BZ3JlZWQsIGFsdGhvdWdoIGFuIGFkZGl0aW9uIGlzIG5lZWRl ZCB0byBzdGF0ZSB0aGF0Og0KPg0KPiAgIFdoZW4gdGhlIGxhc3QgZnJhZ21lbnQgb2YgdGhlIElQ djYgZGF0YWdyYW0gaXMgcmVjZWl2ZWQsIGlmIGFsbA0KPmZyYWdtZW50cw0KPiAgIG9mIHRoYXQg bGFzdCB3aW5kb3cgb2YgdGhlIHBhY2tldCBoYXZlIGJlZW4gcmVjZWl2ZWQsIHRoZSDigJxBQ0sg b24gRXJyb3INCj4gICBUaW1lcuKAnSBpcyBzdG9wcGVkLg0KDQpBZ3JlZWQNCg0KPj4gVGhlIGRl c2NyaXB0aW9uIG9mIMKzV2luZG93IG1vZGUgLSBBQ0sgb24gZXJyb3LCsiBkb2VzIG5vdCBtZW50 aW9uDQo+PiBNQVhfRlJBR19SRVRSSUVTLiBNeSB1bmRlcnN0YW5kaW5nIG9mIMKzV2luZG93IG1v ZGUgLSBBY2sgb24gZXJyb3LCsiBpcw0KPj50aGF0DQo+PiBpdCB3b3VsZCBiZW5lZml0IGZyb20g dGhlIHNhbWUgTUFYX0ZSQUdfUkVUUklFUyBtZWNoYW5pc20uDQo+PiBJbiDCs1dpbmRvdyBtb2Rl IC0gQUNLIG9uIGVycm9ywrIsIHRoZSBBQ0sgY2Fubm90IGJlIHVzZWQgZm9yIGZsb3cNCj4+Y29u dHJvbC4NCj4+IFRoZSBkcmFmdCBkb2VzIG5vdCBwcm92aWRlIHJlY29tbWVuZGF0aW9ucyBvbiB3 aGVuIGEgc2VuZGVyIGNhbiBmb3JnZXQNCj4+IGFib3V0IGEgd2luZG93IHRoYXQgaXQgaGFzIHNl bnQsIGFuZCByZWFsbG9jYXRlIHRoZSB3aW5kb3cgbnVtYmVyICgxDQo+PmJpdCkNCj4+IHRvIGEg bmV3IHdpbmRvdy4gTm9yIGRvZXMgaXQgcHJvdmlkZSByZWNvbW1lbmRhdGlvbiBhYm91dCBmb3Jn ZXR0aW5nDQo+PmFib3V0DQo+PiB0aGUgbGFzdCB3aW5kb3cgb2YgYW4gSVB2NiBwYWNrZXQuIFNl ZSBmb3IgZXhhbXBsZSBGaWd1cmVzIDE3IGFuZCAxOCBpbg0KPj4gQXBwZW5kaXggQS4gScK5bSBh c3N1bWluZyB0aGF0IGEgc2VuZGVyIGltcGxlbWVudGF0aW9uIHdvdWxkIHdhbnQgdG8gd2FpdA0K Pj4gZm9yIGEgcmVhc29uYWJsZSB0aW1lIGJlZm9yZSBmb3JnZXR0aW5nIGFib3V0IGEgd2luZG93 LCBqdXN0IGluIGNhc2UgYW4NCj4+IEFDSyBvbiBlcnJvciB3b3VsZCBiZSByZWNlaXZlZCBzaG9y dGx5LiBTaG91bGQgdGhpcyBiZSBkZXNjcmliZWQgaGVyZT8NCj4NCj5Qcm9wb3NlZCBuZXcgdGV4 dCBmb2xsb3dzLg0KPg0KPk5FVzoNCj4gICBJbiBXaW5kb3cgbW9kZSDigJMgQUNLIG9uIGVycm9y LCB3aGVuIGEgZnJhZ21lbnQgc2VuZGVyIGhhcyB0cmFuc21pdHRlZA0KPiAgIHRoZSBsYXN0IGZy YWdtZW50IG9mIGEgd2luZG93LCBvciBpdCBoYXMgcmV0cmFuc21pdHRlZCB0aGUgbGFzdA0KPmZy YWdtZW50DQo+ICAgd2l0aGluIHRoZSBzZXQgb2YgbG9zdCBmcmFnbWVudHMgcmVwb3J0ZWQgaW4g YW4gQUNLLCBpdCBpcyBhc3N1bWVkIHRoYXQNCj4gICB0aGUgdGltZSB0aGUgZnJhZ21lbnQgc2Vu ZGVyIHdpbGwgd2FpdCB0byByZWNlaXZlIGFuIEFDSyBpcyBzbWFsbGVyDQo+dGhhbg0KPiAgIHRo ZSB0cmFuc21pc3Npb24gdGltZSBvZiBNQVhfV0lORF9GQ04gKyAxIGZyYWdtZW50cyAoaS5lLiB0 aGUgdGltZQ0KPiAgIHJlcXVpcmVkIHRvIHRyYW5zbWl0IGEgY29tcGxldGUgd2luZG93IG9mIGZy YWdtZW50cykuIFRoaXMgYXNwZWN0IG11c3QNCj5iZQ0KPiAgIGNhcmVmdWxseSBjb25zaWRlcmVk IGlmIFdpbmRvdyBtb2RlIOKAkyBBQ0sgb24gZXJyb3IgaXMgdXNlZCwgaW4NCj5wYXJ0aWN1bGFy DQo+ICAgdGFraW5nIGludG8gYWNjb3VudCB0aGUgbGF0ZW5jeSBjaGFyYWN0ZXJpc3RpY3Mgb2Yg dGhlIHVuZGVybHlpbmcgTDINCj4gICB0ZWNobm9sb2d5Lg0KPg0KPldpdGggcmVnYXJkIHRvIE1B WF9GUkFHX1JFVFJJRVMsIHBsZWFzZSBzZWUgYW5vdGhlciByZXNwb25zZSBiZWxvdy4NCj4NCj4+ IFNlY3Rpb24gOS42LCBCYXNlbGluZSBtZWNoYW5pc20sIGRlc2NyaXB0aW9uIG9mIE1JQyBwcm9j ZXNzaW5nIGF0IHRoZQ0KPj5lbmQNCj4+IG9mIHJlYXNzZW1ibHkNCj4+ICAgwrNJbiBObyBBQ0sg bW9kZSwgaWYgdGhlIGludGVncml0eSBjaGVjayBpbmRpY2F0ZXMgdGhhdCB0aGUgcmVhc3NlbWJs ZWQNCj4+IElQdjYgZGF0YWdyYW0gZG9lcyBub3QgbWF0Y2ggdGhlIG9yaWdpbmFsIElQdjYgZGF0 YWdyYW0gKHByaW9yIHRvDQo+PiBmcmFnbWVudGF0aW9uKSwgdGhlIHJlYXNzZW1ibGVkIElQdjYg ZGF0YWdyYW0gTVVTVCBiZSBkaXNjYXJkZWQuwrINCj4+ICAgVGhlIGZvbGxvd2luZyBzZW50ZW5j ZXMgc3RhdGUgdGhhdCBpbiBlaXRoZXIgV2luZG93IG1vZGUsIHRoZSBBQ0sNCj4+IGNvbnZleXMg aW5mb3JtYXRpb24gYWJvdXQgZnJhZ21lbnRzIG9mIHRoZSBsYXN0IHdpbmRvdyB0aGF0IGhhdmUg YmVlbg0KPj4gY29ycmVjdGx5IHJlY2VpdmVkIG9yIG5vdCByZWNlaXZlZC4gKEluY2lkZW50YWxs eSwgdGhlc2Ugc2VudGVuY2VzIGFyZQ0KPj4gcmVkdW5kYW50IHdpdGggdGhlIHNhbWUgdGV4dCBp biB0aGUgdGhpcmQgYW5kIGZpZnRoIHBhcmFncmFwaHMgb2YgdGhlDQo+PnNhbWUNCj4+IHNlY3Rp b24gOS42LiBEbyB3ZSBuZWVkIGJvdGg/KQ0KPg0KPkFncmVlZCB0aGF0IHRoZXNlIGFyZSByZWR1 bmRhbnQgYW5kIG5vdCBuZWVkZWQuDQo+DQo+PiAgIE5vdGhpbmcgaXMgc2FpZCBhYm91dCB3aGF0 IHRvIGRvLCBpbiBXaW5kb3cgbW9kZSwgd2hlbiB0aGUgTUlDIGRvZXMNCj4+bm90DQo+PiBtYXRj aC4gRm9yIGNvbXBsZXRlbmVzcywgSSBzdWdnZXN0IHdlIHdyaXRlIHRoYXQgdGhlIHJlYXNzZW1i bGVkIElQdjYNCj4+IGRhdGFncmFtIE1VU1QgYmUgZGlzY2FyZGVkLCBhbmQgc2ltcGx5IHN0YXRl IHRoYXQgYW4gQUNLIGlzIHNlbnQgd2l0aA0KPj50aGUNCj4+IHNhbWUgYmVoYXZpb3VyIHRoYW4g Zm9yIGFueSBvdGhlciB3aW5kb3cuDQo+DQo+QWdyZWVkIHRoYXQgd2UgbmVlZCB0byByZWZlciBl eHBsaWNpdGx5IHRvIFdpbmRvdyBtb2RlLg0KPg0KPkEgcHJvYmxlbSBpcyB0aGF0IGlmIGF0IHRo ZSBmaXJzdCBNSUMgY2hlY2sgdGhlIElQdjYgZGF0YWdyYW0gaXMNCj5kaXNjYXJkZWQsIHRoZW4g d2UgbWlzcyB0aGUgb3Bwb3J0dW5pdHkgdG8gaG9wZWZ1bGx5IHJlY292ZXIgdGhlIElQdjYNCj5k YXRhZ3JhbSBieSByZXRyYW5zbWl0dGluZyB0aGUgbWlzc2luZyBmcmFnbWVudChzKSBmcm9tIHRo ZSBsYXN0IHdpbmRvdy4NCj5UaGVyZWZvcmUsIHRoZSBmb2xsb3dpbmcgbmV3IHRleHQgaXMgcHJv cG9zZWQ6DQo+DQo+TkVXOg0KPiAgIEluIFdpbmRvdyBtb2RlLCBhIE1JQyBjaGVjayBpcyBhbHNv IHBlcmZvcm1lZCBieSB0aGUgZnJhZ21lbnQgcmVjZWl2ZXINCj4gICBhZnRlciByZWNlcHRpb24g b2YgYSByb3VuZCBvZiByZXRyYW5zbWl0dGVkIGZyYWdtZW50cy4gSWYgdGhlIE1JQyBjaGVjaw0K PiAgIHN0aWxsIGZhaWxzIGFmdGVyIHRoZSBsYXN0IHJvdW5kIG9mIGZyYWdtZW50cyByZXRyYW5z bWl0dGVkIGJ5IHRoZQ0KPiAgIGZyYWdtZW50IHNlbmRlciAod2hpY2ggbWF5IGhhdmUgYmVlbiBy ZWNlaXZlZCBvciBub3QgYnkgdGhlIGZyYWdtZW50DQo+ICAgcmVjZWl2ZXIpLCB0aGUgcmVhc3Nl bWJsZWQgSVB2NiBwYWNrZXQgaXMgZGlzY2FyZGVkLiBOb3RlIHRoYXQgdGhlDQo+ICAgZnJhZ21l bnQgcmVjZWl2ZXIgd2lsbCBuZWVkIHRvIGRldGVybWluZSB3aGVuIGl0IGlzIHNhZmUgdG8gYXNz dW1lIHRoYXQNCj4gICBubyBtb3JlIGZyYWdtZW50cyB3aWxsIGJlIHJlY2VpdmVkLiBGdXJ0aGVy IGd1aWRhbmNlIG9uIHRoaXMgaXMNCj5leHBlY3RlZA0KPiAgIHRvIGJlIHByb3ZpZGVkIGluIGZ1 dHVyZSAocG9zc2libHkgdGVjaG5vbG9neS1zcGVjaWZpYykgZG9jdW1lbnRzLiBOb3RlDQo+ICAg YWxzbyB0aGF0LCBpbiBXaW5kb3cgbW9kZSwgdGhlIHJ1bGVzIHRoYXQgYXBwbHkgZm9yIGNvbnN0 cnVjdGluZyBhbmQNCj4gICB0cmFuc21pdHRpbmcgYW4gQUNLIGZvciB0aGUgbGFzdCB3aW5kb3cg YXJlIHRoZSBzYW1lIHJ1bGVzIHRoYXQgYXBwbHkNCj5mb3INCj4gICBhbnkgb3RoZXIgd2luZG93 Lg0KPg0KPg0KPj4gQXBwZW5kaXggQiwgYWxsb2NhdGlvbiBvZiBSdWxlIElEcyBmb3IgZnJhZ21l bnRhdGlvbg0KPj4gICBJIHN1Z2dlc3QgdG8gbW9kaWZ5IHRoZSBzZWN0aW9uIHRpdGxlIHRvIMKz QWxsb2NhdGlvbiBvZiBSdWxlIElEcyBmb3INCj4+IGZyYWdtZW50YXRpb27Csi4NCj4NCj5BZ3Jl ZWQuDQo+DQo+PiAgIFRoaXMgc2VjdGlvbiBzaG91bGQgYmUgcmV3cml0dGVuLiBJIHN1Z2dlc3Q6 DQo+PiAgIMKzQSBzZXQgb2YgUnVsZSBJRHMgYXJlIGFsbG9jYXRlZCB0byBzdXBwb3J0IGRpZmZl cmVudCBhc3BlY3RzIG9mDQo+PiBmcmFnbWVudGF0aW9uDQo+PiAgICBmdW5jdGlvbmFsaXR5IGFz IHBlciB0aGlzIGRvY3VtZW50LiBUaGUgYWxsb2NhdGlvbiBvZiBJRHMgaXMgdG8gYmUNCj4+IGRl ZmluZWQgaW4gb3RoZXIgZG9jdW1lbnRzLiBUaGUgc2V0IE1BWSBpbmNsdWRlOg0KPj4NCj4+ICAg IG8gIG9uZSBJRCBvciBhIHN1YnNldCBvZiBJRHMgdG8gaWRlbnRpZnkgYSBmcmFnbWVudCBhcyB3 ZWxsIGFzIGl0cw0KPj4gcmVsaWFiaWxpdHkgb3B0aW9uIGFuZCBpdHMgd2luZG93IHNpemUsIGlm IG11bHRpcGxlIG9mIHRoZXNlIGFyZQ0KPj5zdXBwb3J0ZWQNCj4+DQo+PiAgICBvICBvbmUgSUQg dG8gaWRlbnRpZnkgdGhlIEFDSyBtZXNzYWdlLg0KPj4NCj4+ICAgIG8gIG9uZSBJRCB0byBpZGVu dGlmeSB0aGUgQWJvcnQgbWVzc2FnZSBhcyBwZXIgU2VjdGlvbiA5LjguwrINCj4NCj5BZ3JlZWQu DQo+DQo+PiAgIERvIHdlIGFncmVlIHdpdGggdGhlIMKzb25lIElEwrIgaW4gdGhlIGxhc3QgdHdv IGl0ZW1zLCBvciBhcmUgdGhlcmUgdXNlDQo+PiBjYXNlcyB0aGF0IEkgZG9uwrl0IHNlZSB0aGF0 IHdvdWxkIGp1c3RpZnkgZm9yIG11bHRpcGxlIElEcyA/DQo+DQo+Rm9yIEFDS3MsIG15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCBvbmUgSUQgaXMgc3VmZmljaWVudC4NCj4NCj5Gb3IgQWJvcnQsIHdl IGRpc2N1c3NlZCBpbiBvbmUgb2YgdGhlIHBhc3QgaW50ZXJpbXMgdGhhdCB0aGVyZSBtaWdodCBi ZQ0KPnJlYXNvbnMgdG8gc3VwcG9ydCBkaWZmZXJlbnQgb3B0aW9ucyAoZS5nLiBhYm9ydCBhbGwg b24tZ29pbmcsIHBvc3NpYmx5DQo+aW50ZXJsZWF2ZWQsIHRyYW5zbWlzc2lvbnMgdnMgc29tZSBt b3JlIGZpbmUtZ3JhaW5lZCBiZWhhdmlvcikuIFdlIGRlY2lkZWQNCj5hdCB0aGUgdGltZSB0aGF0 IHdlIHdvdWxkIGdvIGZvciB0aGUgbW9zdCBzaW1wbGUgYXBwcm9hY2ggdG8ganVzdCB1c2Ugb25l DQo+SUQgdG8gYWJvcnQgYWxsIG9uLWdvaW5nIHRyYW5zbWlzc2lvbnMuDQo+DQo+PiBWYXJpb3Vz IG5pdHMNCj4+ICogU2VjdGlvbiAzLCBUZXJtaW5vbG9neS4gQ0ZOIGlzIG5vdCBsaXN0ZWQuIEFs c28gYWRkIHRoZSBvdGhlciBhY3Jvbnltcw0KPj4gKERUYWcsIE1JQywgZXRjLikgdXNlZCBpbiB0 aGUgZnJhZ21lbnRhdGlvbiBzZWN0aW9uLg0KPg0KPkFncmVlZC4NCj4NCj4+ICogU2VjdGlvbiA5 LjI6IE1BWF9GUkFHX1JFVFJJRVMgaXMgZGVzY3JpYmVkIGZvciB0aGUgV2luZG93IG1vZGUgLSBB Q0sNCj4+IMKzYWx3YXlzwrIuIEZvciBjb21wbGV0ZW5lc3MsIHRoZSBzYW1lIHRleHQgc2hvdWxk IGJlIHJlcGVhdGVkIGZvciB0aGUNCj4+IFdpbmRvdyBtb2RlIC0gQUNLIG9uIGVycm9yLg0KPg0K PkkgdGhpbmsgeW91ciBwcm9wb3NhbCBpcyBvbmUgcG9zc2libGUgYXBwcm9hY2guDQo+DQo+QW5v dGhlciBhcHByb2FjaCwgd2hpY2ggaXMgdGhlIGN1cnJlbnQgb25lIGluIHRoZSBkcmFmdCAoYW5k IG1heSBuZWVkIHRvDQo+YmUgZGlzY3Vzc2VkKSBpcyB0aGF0IGluIOKAnEFDSyBvbiBlcnJvcuKA nSwgdGhlIG1heGltdW0gbnVtYmVyIG9mDQo+cmV0cmFuc21pc3Npb24gcm91bmRzIHdpbGwgYmUg Y29udHJvbGxlZCBieSB0aGUgcmVjZWl2ZXIgYnkgbWVhbnMgb2YNCj5NQVhfQUNLU19QRVJfV0lO RE9XLCB3aGlsZSB0aGUgc2VuZGVyIHdpbGwgcmV0cmFuc21pdCBhbnkgZnJhZ21lbnRzDQo+cmVw b3J0ZWQgdG8gYmUgbG9zdCBpbiBhbiBBQ0suIE90aGVyd2lzZSwgaW4gc29tZSBzaXR1YXRpb25z LCB0aGUgcmVjZWl2ZXINCj5tYXkgdW5uZWNlc3NhcmlseSBzZW5kIEFDS3Mgd2hpbGUgdGhlIHNl bmRlciB3aWxsIG5vdCByZXBseSAod2l0aCBmcmFnbWVudA0KPnJldHJpZXMpIHRvIHRob3NlIGlm IGl0IGhhcyByZWFjaGVkIGl0cyBtYXhpbXVtIG51bWJlciBvZiByZXRyaWVzLiBUaGUNCj5yZWNl aXZlciBkb2VzIG5vdCBuZWNlc3NhcmlseSBrbm93IHRoZSBNQVhfRlJBR19SRVRSSUVTIHZhbHVl IG9mIHRoZQ0KPnNlbmRlci4NCj4NCj5UaG91Z2h0cz8NCg0KSSB1bmRlcnN0YW5kIGhvdyBpdCB3 b3JrcyBpZiBldmVyeSBub2RlIGlzIG5pY2UgYW5kIHBsYXlzIGJ5IHRoZSBydWxlLg0KQnV0IEkg cGljdHVyZSBteXNlbGYgaW1wbGVtZW50aW5nIHRoZSBzZW5kZXIgY29kZSBhbmQgd3JpdGluZyB0 aGUgInJlcGVhdA0K4oCmIHVudGlsIiBsb29wIHdoZXJlIHRoZSBleGl0IGNvbmRpdGlvbiBpcyB0 b3RhbGx5IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZQ0Kb3RoZXIgbm9kZS4NClRoYXQgbWFrZXMg bWUgc2hpdmVyLg0KSXNuJ3QgdGhpcyBhbiBhdmVudWUgZm9yIGEgRE9TIGF0dGFjaywgd2l0aCBh IG5vZGUgaGFuZGluZyBpdHMgZW5lcmd5IGFuZA0KcmFkaW8gYmFuZHdpZHRoIG92ZXIgdG8gYW5v dGhlciBub2RlPw0KSSdtIHN1cmUgaW1wbGVtZW50ZXJzIHdpbGwgd2FudCB0byBhZGQgYSBsb2Nh bCBzdG9wIGNvbmRpdGlvbiB0byB0aGlzIGxvb3ANCmFueXdheS4NCkJ1dCBtYXliZSBpdCBkb2Vz IG5vdCBiZWxvbmcgdG8gdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24uDQpXaGF0IGRvIG90aGVy cyB0aGluaz8NCg0KDQo+DQo+PiAqIFNlY3Rpb24gOS40OiBSdWxlIElEIGRlc2NyaXB0aW9uLiBB ZGQgdGhlIHVzZSBvZiBSdWxlIElEIGZvciBjb252ZXlpbmcNCj4+IHRoZSB3aW5kb3cgc2l6ZSBp ZiBtdWx0aXBsZSBzaXplcyBhcmUgc3VwcG9ydGVkLg0KPj4gICBPTEQgVEVYVA0KPj4gICDCs1J1 bGUgSUQgbWF5IGFsc28gYmUgdXNlZCB0byBzaWduYWwgd2hpY2ggcmVsaWFiaWxpdHkgb3B0aW9u IGlzIGluIHVzZQ0KPj4gZm9yIHRoZSBJUHY2IHBhY2tldCBiZWluZyBjYXJyaWVkLsKyDQo+PiAg IE5FVyBURVhUDQo+PiAgIMKzUnVsZSBJRCBtYXkgYWxzbyBiZSB1c2VkIHRvIHNpZ25hbCB3aGlj aCByZWxpYWJpbGl0eSBvcHRpb24gaXMgaW4gdXNlDQo+PiBmb3IgdGhlIElQdjYgcGFja2V0IGJl aW5nIGNhcnJpZWQuIFJ1bGUgSUQgbWF5IGFsc28gYmUgdXNlZCB0byBzaWduYWwNCj4+dGhlDQo+ PiB3aW5kb3cgc2l6ZSBpZiBtdWx0aXBsZSBzaXplcyBhcmUgc3VwcG9ydGVkIChzZWUgOS43KS7C sg0KPg0KPkFncmVlZC4NCj4NCj4+ICogU2VjdGlvbiA5LjQ6IMKzQ29tcHJlc3NlZCBGcmFnbWVu dCBOdW1iZXLCsi4gwrNDb21wcmVzc2VkwrIgcmVmZXJzIHRvIHRoZQ0KPj4gbnVtYmVyLCBub3Qg dG8gdGhlIGZyYWdtZW50LCBzaW5jZSB1bmNvbXByZXNzZWQgcGFja2V0IGNhbiBhbHNvIGJlDQo+ PiBmcmFnbWVudGVkIHdpdGggdGhpcyBtZWNoYW5pc20uDQo+PiAgIFRvIHJlbW92ZSB0aGlzIGFt YmlndWl0eSwgcmVuYW1lIENGTiB0byBGcmFnbWVudCBDb21wcmVzc2VkIE51bWJlcg0KPj4gKEZD Tik/DQo+PiAgIENGTi9GQ04gc2hvdWxkIGJlIGxpc3RlZCBpbiB0aGUgVGVybWlub2xvZ3kgc2Vj dGlvbi4NCj4NCj5BZ3JlZWQuDQo+DQo+PiAgIFRoZSBwYXJ0IG9mIHRoZSBzZW50ZW5jZSDCsywg YW5kIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGNhcnJ5IGFuIGFic29sdXRlDQo+PiBmcmFnbWVudCBu dW1iZXIuwrIgc2hvdWxkIGJlIHJld3JpdHRlbiBhcyDCsywgYW5kIGRvZXMgbm90IGNhcnJ5IGFu DQo+PmFic29sdXRlDQo+PiBmcmFnbWVudCBudW1iZXIuwrIuIEluZGVlZCwgQ0ZOIGNvdW50cyBk b3duIGZyb20gImhpZ2hlc3QgQ0ZOIGluIHRoZQ0KPj4gd2luZG93IiBhbnl3YXksIHNvIHRoZSBj aGFuY2VzIHRoYXQgaXQgY29ycmVzcG9uZHMgdG8gYW4gYWJzb2x1dGUNCj4+ZnJhZ21lbnQNCj4+ IG51bWJlciBhcmUgbnVsbC4NCj4NCj5BZ3JlZWQuDQo+DQo+PiAgIFNlZSBhcyB3ZWxsIG15IGNv bW1lbnQgb24gdGV4dCByZWdhcmRpbmcgQ0ZOIGluIDkuNS4yDQo+PiAqIFNlY3Rpb24gOS41LjI6 IFJlbW92ZSDCsywgYW5kIHRodXMgdGhlIENGTiBkb2VzIG5vdCBzdHJpY3RseSBjb3JyZXNwb25k DQo+PiB0byB0aGUgTiBsZWFzdCBzaWduaWZpY2FudCBiaXRzIG9mIHRoZSBhY3R1YWwgYWJzb2x1 dGUgZnJhZ21lbnQNCj4+bnVtYmVyLsKyLg0KPj4gSXQgZG9lcyBub3Qgc3RyaWN0bHkgY29ycmVz cG9uZCwgbm9yIGxvb3NlbHkuDQo+DQo+QWdyZWVkLg0KPg0KPj4gKiBTZWN0aW9uIDkuNS4zOiDC skFic2VuY2Ugb2YgdGhlIGJpdG1hcCBpbiBhbiBBQ0sgY29uZmlybXMgY29ycmVjdA0KPj4gcmVj ZXB0aW9uIG9mIGFsbCBmcmFnbWVudHMgdG8gYmUgYWNrbm93bGVkZ2VkIGJ5IG1lYW5zIG9mIHRo ZSBBQ0suIg0KPj4gICBGb3IgdGhlIHdvbmRlcmluZyBzb3VsLCBtYXliZSBleHBsYWluIHRoYXQg dGhlIGFic2VuY2UgaXMgbm90aWNlZCBieQ0KPj4gbG9va2luZyBhdCB0aGUgTDIgc2l6ZSwgc2lu Y2UgaXQgZG9lc24ndCBpbW1lZGlhdGVseSBzaG93IGZyb20gRmlndXJlDQo+PjEzLg0KPg0KPkFn cmVlZC4NCj4NCj4+ICogU2VjdGlvbiA5LjY6ICJpZiBubyBBQ0sgaGFzIGJlZW4gcmVjZWl2ZWQg c2luY2UgdGhlIHRpbWVyIHN0YXJ0LCB0aGUNCj4+IHNlbmRlciByZXRyYW5zbWl0cyB0aGUgbGFz dCBmcmFnbWVudCBzZW50IMWgIi4gQ291bGQgcmVmZXIgdG8gdGhlIGxhc3QgaW4NCj4+IHRpbWUg b3IgdGhlIGxhc3QgaW4gb3JkZXIuDQo+PiAgIEkgZ3Vlc3MgdGhlIGNvcnJlY3QgYW5zd2VyIGlz IHRoZSBsYXR0ZXIsIGkuZS4gdGhlIGxhc3QgZnJhZ21lbnQgb2YNCj4+dGhlDQo+PiBJUHY2IHBh Y2tldC4NCj4NCj5UaGUgc2VudGVuY2UgcmVmZXJzIHRvIHRoZSBsYXN0IGZyYWdtZW50IHRoYXQg aGFzIGJlZW4gc2VudCBhdCB0aGUgbW9tZW50DQo+b2YgdGltZXIgZXhwaXJhdGlvbiwgd2hpY2gg Y291bGQgYmU6IGkpIHRoZSBsYXN0IGZyYWdtZW50IG9mIGEgd2luZG93DQo+KGkuZS4gRkNOPTAg b3IgRkNOPTJeTi0xKSwgZS5nLiBpbiB0aGUgZmlyc3Qgcm91bmQgb2YgZnJhZ21lbnQNCj50cmFu c21pc3Npb24gYXR0ZW1wdHM7IG9yIGlpKSB0aGUgbGFzdCBmcmFnbWVudCBzZW50IHdpdGhpbiBh IGEgcm91bmQgb2YNCj5yZXRyYW5zbWlzc2lvbnMgKHdoaWNoIGNhbiBiZSBhIGZyYWdtZW50IHdp dGggYW55IHZhbGlkIEZDTiBmb3IgdGhlDQo+Y3VycmVudCB3aW5kb3cpLg0KPg0KPlByb3Bvc2Vk IG5ldyB0ZXh0IGZvbGxvd3MuDQo+DQo+TkVXDQo+ICAgVXBvbiBleHBpcmF0aW9uIG9mIHRoZSB0 aW1lciwgaWYgbm8gQUNLIGhhcyBiZWVuIHJlY2VpdmVkIHNpbmNlIHRoZQ0KPnRpbWVyDQo+ICAg c3RhcnQsIHRoZSBzZW5kZXIgcmV0cmFuc21pdHMgdGhlIGxhc3QgZnJhZ21lbnQgc2VudCBhdCB0 aGUgbW9tZW50IG9mDQo+ICAgdGltZXIgZXhwaXJhdGlvbiwgYW5kIGl0IHJlaW5pdGlhbGl6ZXMg YW5kIHJlc3RhcnRzIHRoZSB0aW1lci4gTm90ZQ0KPnRoYXQNCj4gICB0aGUgbGFzdCBmcmFnbWVu dCBzZW50IGF0IHRoZSBtb21lbnQgb2YgdGltZXIgZXhwaXJhdGlvbiBtYXkgYmUgdGhlDQo+bGFz dA0KPiAgIGZyYWdtZW50IG9mIGEgd2luZG93IChpLmUuIEZDTj0wIG9yIEZDTj0yXk4tMSkgb3Ig dGhlIGxhc3QgZnJhZ21lbnQNCj5zZW50DQo+ICAgd2l0aGluIGEgcm91bmQgb2YgZnJhZ21lbnQg cmV0cmFuc21pc3Npb25zLg0KPg0KPj4gKiBTZWN0aW9uIDkuNjogwrNTaW1pbGFybHksIHdoZW4g YSBub2RlIGZpcnN0IHJlY2VpdmVzIMWgIMKzLiDCs25vZGXCsiBpcyBub3QNCj4+IHBhcnQgb2Yg dGhlIHRlcm1pbm9sb2d5LiBEbyB5b3UgbWVhbiBhIERldmljZSwgb3IgZWl0aGVyIGVuZCBvZiB0 aGUNCj4+TFBXQU4NCj4+IGxpbmsgPw0KPg0KPkVpdGhlciBlbmQgb2YgdGhlIExQV0FOIGxpbmsu DQo+DQo+PiAqIFNlY3Rpb24gOS44LCBmcmFnbS9yZWFzc2JseSBhYm9ydGlvbg0KPj4gICBPTEQg VEVYVA0KPj4gICDCs1RoZSBlbnRpdHkgKGVpdGhlciB0aGUgZnJhZ21lbnQgc2VuZGVyIG9yIHRo ZSBmcmFnbWVudCByZWNlaXZlcikgdGhhdA0KPj4gdHJpZ2dlcnMgYWJvcnRpb24gdHJhbnNtaXRz IHRvIHRoZSBvdGhlciBlbmRwb2ludCBhIGZvcm1hdCB0aGF0IG9ubHkNCj4+IGNvbXByaXNlcyBh IFJ1bGUgSUQgKG9mIHNpemUgUiBiaXRzKSwgd2hpY2ggc2lnbmFscyBhYm9ydGlvbiBvZiBhbGwN Cj4+IG9uLWdvaW5nIGZyYWdtZW50ZWQgSVB2NiBwYWNrZXQgdHJhbnNtaXNzaW9ucy7Csg0KPj4g ICBORVcgVEVYVA0KPj4gICDCs1RoZSBlbnRpdHkgKGVpdGhlciB0aGUgZnJhZ21lbnQgc2VuZGVy IG9yIHRoZSBmcmFnbWVudCByZWNlaXZlcikgdGhhdA0KPj4gdHJpZ2dlcnMgYWJvcnRpb24gdHJh bnNtaXRzIHRvIHRoZSBvdGhlciBlbmRwb2ludCBhIHBhY2tldCB0aGF0IG9ubHkNCj4+IGNvbXBy aXNlcyBhIHVuaXF1ZSBSdWxlIElEIChvZiBzaXplIFIgYml0cyksIHdoaWNoIHNpZ25hbHMgYWJv cnRpb24gb2YNCj4+YWxsDQo+PiBvbi1nb2luZyBmcmFnbWVudGVkIElQdjYgcGFja2V0IHRyYW5z bWlzc2lvbnMuwrINCj4NCj5ZZXMsIOKAnGZvcm1hdOKAnSBpcyBub3Qgc28gc3VpdGFibGUgaGVy ZS4uLiBXaGF0IGFib3V0IOKAnGRhdGEgdW5pdCB3aXRoIGFuIEwyDQo+cGF5bG9hZOKAnSBpbnN0 ZWFkIG9mIOKAnHBhY2tldOKAnT8NCg0KWWVzLCBzb3VuZHMgZ29vZC4NCg0KPg0KPknigJlkIGxp a2UgdG8gYXZvaWQgdGVybWlub2xvZ3kgY29uZnVzaW9uIHdpdGggYW4gSVB2NiBwYWNrZXQuLi4N Cj4NCj4+ICogU2VjdGlvbiAxMC4yLCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgZnJhZ21l bnRhdGlvbg0KPj4gICDCs0lmIGFuIGF0dGFja2VyIGNhbiBvdmVyaGVhciBhIGZyYWdtZW50LCBp dCBjYW4gc2VuZCBhIHNwb29mZWQNCj4+ZHVwbGljYXRlDQo+PiAoZS5nLiB3aXRoIHJhbmRvbSBw YXlsb2FkKSB0byB0aGUgZGVzdGluYXRpb24uIEEgcmVjZWl2ZXIgY2Fubm90DQo+PiBkaXN0aW5n dWlzaCBsZWdpdGltYXRlIGZyb20gc3Bvb2ZlZCBmcmFnbWVudHMuwrINCj4+ICAgVGhpcyBpcyB0 cnVlIG9mIGFsbCBMUFdBTiB0ZWNobm9sb2dpZXMuIEZvciBleGFtcGxlLCBMb1JhV0FOIGhhcw0K Pj5zb3VyY2UNCj4+IGF1dGhlbnRpY2F0aW9uIHRoYXQgYWxsb3dzIGEgcmVjZWl2ZXIgZGlzdGlu Z3Vpc2hpbmcgYSByYW5kb20tcGF5bG9hZA0KPj4gc3Bvb2ZlZCBmcmFnbWVudCBmcm9tIGEgbGVn aXRpbWF0ZSBvbmUuIElsIGFsc28gaGFzIGEgZnJhbWUgY291bnRlcg0KPj4gbWVjaGFuaXNtIHRo YXQgYWxsb3dzIGEgcmVjZWl2ZXIgdG8gZGlzY2FyZCBsYXRlciByZXBsYXkgYnkgYW4gYXR0YWNr ZXINCj4+b2YNCj4+IGEgc3RyaWN0bHkgaWRlbnRpY2FsIG1lc3NhZ2UgYXMgc2VuZCBlYXJsaWVy IGJ5IGEgbGVnaXRpbWF0ZSBub2RlLg0KPj4gICBUaGVyZWZvcmUsIHRoZSBhdHRhY2sgZGVzY3Jp YmVkIGhlcmUgYW5kIGl0cyBtaXRpZ2F0aW9uIG9ubHkgYXBwbGllcw0KPj50bw0KPj4gY2VydGFp biBMUFdBTiB0ZWNobm9sb2dpZXMuDQo+DQo+QWdyZWVkLg0KPg0KPk9MRDoNCj4gICBBIHJlY2Vp dmVyIGNhbm5vdCBkaXN0aW5ndWlzaCBsZWdpdGltYXRlIGZyb20gc3Bvb2ZlZCBmcmFnbWVudHMN Cj4NCj5ORVc6DQo+ICAgSWYgdGhlIExQV0FOIHRlY2hub2xvZ3kgZG9lcyBub3Qgc3VwcG9ydCBz dWl0YWJsZSBwcm90ZWN0aW9uIChlLmcuDQo+c291cmNlDQo+ICAgYXV0aGVudGljYXRpb24gYW5k IGZyYW1lIGNvdW50ZXJzIHRvIHByZXZlbnQgcmVwbGF5IGF0dGFja3MpLCBhDQo+cmVjZWl2ZXIN Cj4gICBjYW5ub3QgZGlzdGluZ3Vpc2ggbGVnaXRpbWF0ZSBmcm9tIHNwb29mZWQgZnJhZ21lbnRz Lg0KPg0KPj4gKiBBcHBlbmRpeCBBOiDCs05vdGU6IGluIFdpbmRvdyBtb2RlLCBhbiBhZGRpdGlv bmFsIGJpdCB3aWxsIGJlIG5lZWRlZCB0bw0KPj4gbnVtYmVyIHdpbmRvd3MuwrIuIFRoaXMgY29t bWVudCBpcyBjb3JyZWN0LCBidXQgaXQgaXMgb2RkbHkgcGxhY2VkIGluIHRoZQ0KPj4gbWlkZGxl IG9mIHRoZSBkZXNjcmlwdGlvbiBvZiBGaWd1cmUgMTkgYXMgaWYgaXQgZGlkbsK5dCBhcHBseSB0 byB0aGUgwrNBQ0sNCj4+IG9uIGVycm9ywrIgbW9kZSBhcyB3ZWxsLg0KPg0KPkkgdGhpbmsgaXQg aXMgYmV0dGVyIHRvIGp1c3QgcmVtb3ZlIHRoZSBzZW50ZW5jZS4gVGhlIOKAnFfigJ0gYml0IGlz IG5vdw0KPmNsZWFybHkgZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnQgKHRoZSBzZW50ZW5jZSBwb2lu dGVkIG91dCBtYWRlIHNlbnNlIGluIGFuDQo+b2xkZXIgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQs IGJlZm9yZSB0aGUg4oCcV+KAnSBiaXQgd2FzIGRlZmluZWQpLg0KDQpHb29kDQoNCj4NCj5DaGVl cnMsDQo+DQo+Q2FybGVzDQo+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4gRG9taW5pcXVlDQo+ DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Mon Jul 17 00:36: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 0D570131A69 for ; Mon, 17 Jul 2017 00:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HohmRQJYfCOm for ; Mon, 17 Jul 2017 00:36:24 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446F4131945 for ; Mon, 17 Jul 2017 00:36:24 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:20c6:9376:198e:f52] (unknown [IPv6:2001:67c:370:128:20c6:9376:198e:f52]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 95CE11720E0 for ; Mon, 17 Jul 2017 09:36:22 +0200 (CEST) From: Alexander Pelov Content-Type: multipart/alternative; boundary="Apple-Mail=_FC16D030-7805-44A1-B616-7AB2DE917AEB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: References: To: lp-wan Date: Mon, 17 Jul 2017 09:36:31 +0200 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Fwd: [core] Info session on M2MSAT at IETF99 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: Mon, 17 Jul 2017 07:36:27 -0000 --Apple-Mail=_FC16D030-7805-44A1-B616-7AB2DE917AEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, This one seems to be quite in the scope of the LPWAN work. It=E2=80=99s today, 6 pm. Alexander > D=C3=A9but du message r=C3=A9exp=C3=A9di=C3=A9 : >=20 > De: Ines Robles > Objet: [core] Info session on M2MSAT at IETF99 Prague > Date: 17 juillet 2017 =C3=A0 09:33:50 UTC+2 > =C3=80: core@ietf.org, t2trg@irtf.org > Cc: mariarita.palattella@list.lu >=20 >=20 > FYI >=20 > ---------- Message transf=C3=A9r=C3=A9 ---------- > De : Maria Rita Palattella > > Date : samedi 15 juillet 2017 > Objet : Fw: Info session on M2MSAT at IETF99 Prague >=20 >=20 >=20 > I am writing to you because I am organising at IETF99 in Prague a Info = session about an ongoing project I am leading: M2MSAT = (https://artes.esa.int/projects/m2msat = ) > The project, funded by ESA, aims to analyse (both via simulations and = in a real test bed), the performance of IoT application protocols (CoAP = and MQTT) when communicating over a satellite link. IoT networks will be = soon integrated with terrestrial networks in the 5G scenarios, and it is = fundamental to design adaptation/improvement of IoT protocols not = originally designed with the satellite network constrains in mind (link = disruption, high packet loss, etc). We are currently running performance = evaluation using simulators (OpenSAND, Californium CoAP, MQTT Mosquito). = And also setting up a testbed, where we we may collect IoT data from = OpenMote nodes, running 6TiSCH. >=20 > I believe the project may be of interest for different IETF folk, such = those working on CoAP, IoT, 6TiSCH, LPWAN, 6lo, etc. >=20 > It will be great if you can join the meeting, planned for Monday July, = 17th at 6pm, in Paris Room (Lobby level, L) in Hilton Hotel in Prague. > I will appreciate also if you can spread the info among folks that = could find the project of interest, and could provide us some fruitful = feedback. > We will also announce the Info session during the 6TiSCH WG meeting = planned for Monday 17/7/2017, in the first afternoon session. >=20 > Thank you. > Looking forward to hearing from you. > See you in Prague >=20 > Best Regards, > Maria Rita Palattella >=20 > = --------------------------------------------------------------------------= --- > Senior R&T Associate > Department 'Environmental Research and Innovation' (ERIN) > Luxembourg Institute of Science and Technology (LIST) > 41, rue du Brill > L-4422 Belvaux, Grand-duchy of Luxembourg > email: mariarita.palattella@list.lu <>, tel: +352 275 888-5055 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail=_FC16D030-7805-44A1-B616-7AB2DE917AEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

This one seems to be quite in the scope of the LPWAN = work.

It=E2=80=99= s today, 6 pm.

Alexander

D=C3=A9but du message = r=C3=A9exp=C3=A9di=C3=A9 :

De: = Ines Robles <mariainesrobles@googlemail.com>
Objet: = [core] Info = session on M2MSAT at IETF99 Prague
Date: = 17 juillet 2017 =C3=A0 09:33:50 = UTC+2
=C3=80: = core@ietf.org, t2trg@irtf.org
Cc: mariarita.palattella@list.lu

FYI

---------- Message transf=C3=A9r=C3=A9 ----------
De : Maria Rita Palattella <mariarita.palattella@list.lu>
Date : = samedi 15 juillet 2017
Objet : Fw: Info session on = M2MSAT at IETF99 Prague



I am writing to = you because I am organising at IETF99 in Prague a Info session about an ongoing = project I am leading: M2MSAT (https://artes.esa.int/projects/m2msat)
The = project, funded by ESA, aims to analyse (both via simulations and in a = real test bed), the = performance of IoT application protocols (CoAP and MQTT) = when communicating over = a satellite link. IoT networks = will be soon integrated with terrestrial networks in the 5G scenarios, = and it is fundamental to design adaptation/improvement of IoT protocols = not originally designed with the satellite network constrains in mind = (link disruption, high packet loss, etc). We are currently running = performance evaluation using simulators (OpenSAND, Californium CoAP, = MQTT Mosquito). And also setting up a testbed, where we we may collect = IoT data from OpenMote nodes, running 6TiSCH.

I believe the project may be of = interest for different IETF folk, such those working on CoAP, IoT, = 6TiSCH, LPWAN, 6lo, etc.

It will be great if you can join the meeting, = planned for Monday = July, 17th at 6pm, in Paris Room (Lobby level, = L) in Hilton Hotel in = Prague.
I will = appreciate also if you can spread the info  among folks that could = find the project of interest, and could provide us some fruitful = feedback.
We will also = announce the Info session during the 6TiSCH WG meeting planned for = Monday 17/7/2017, in the first afternoon session.
Thank you.
Looking forward to hearing from = you.
See you in = Prague

Best Regards,
Maria Rita Palattella

-----------------------------------------------------------------------------
Senior R&T Associate
Department = 'Environmental Research and Innovation' (ERIN)
Luxembourg = Institute of Science and Technology (LIST)
41, rue du = Brill
L-4422 Belvaux, Grand-duchy of Luxembourg
email: mariarita.palattella@list.lu, = tel: +352 275 888-5055


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

= --Apple-Mail=_FC16D030-7805-44A1-B616-7AB2DE917AEB-- From nobody Mon Jul 17 00:45:33 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 2BDE6131A54 for ; Mon, 17 Jul 2017 00:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni-ywYRWIGvH for ; Mon, 17 Jul 2017 00:45:29 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 CB5BA131945 for ; Mon, 17 Jul 2017 00:45:29 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id v202so45728365itb.0 for ; Mon, 17 Jul 2017 00:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xiW9Dv5cHCBjOApbwmC5yH8O2rG9GHHi4Lfgnrz96/8=; b=Le1omlh4CppBdt3tApilAs4TH2r45pBoGdbolb/wwu6UOVj6XX6IYEhdtbpzoyH05O jOQAgldOA6PNBgQlAyVH3kDms/pr/kiREm0rJhDDs5MVvE53Er02ddxKUkojcjcAT6ZU XUqB1PXMV0P6z7zjRmchSc2Sha5B+r5gUio0Oh3U/I9cQ+1MtBZ5R5/Ed8JQeV4v8DLK aTHqPx9klbJ/IinEl/LhCqdr8pfgH6pXuR//zKbBEad39eq22hAMWfSJscDhcRaAhyDb aT8lXRVOPhaHNMTp1bVVNCBQmzUeYbOMVQIT8Ljpkr8phLOotbBZlDKAv4DQr49yL9ab /mbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xiW9Dv5cHCBjOApbwmC5yH8O2rG9GHHi4Lfgnrz96/8=; b=oYzAOrw8J5woiwqnBEewB2BxZ165q88Xo5kE7Eoalb6scvvKuRb3uxDUrUcbD0pUHA tnN/el1fmX8dQA/c4nWnMmLNL0uGTCU9QTWK/4FwpvoMip2ACvcKHvKTFaMmZ+o044+i SW3BNmvGgixFjrA8PxaGoKtV5T9kKK1gqhR91WPWt2c+vzanQOh8s6fS9B67PeBiv0q3 CP9KmZysZyzxhGxbZTgv1rI5vwIE5unyx1/0RsM6v0xLiuGa6tVY+lj2eBSxejLaIs9d CxT3yVqeWBkEvFJESc/A3j0YgdU2eELMTH2g7d+iGv26HrhKuQyDqxlePoskl3dIbcFr D8KQ== X-Gm-Message-State: AIVw111PdR+7WbOJcaylojBPpl+dLfRVcCD2t9SYIn7uvT1Uj8roVdSf tyBkG1EUsUM1Lc8iIji90DOSOXleSQ== X-Received: by 10.36.110.23 with SMTP id w23mr4332444itc.24.1500277529004; Mon, 17 Jul 2017 00:45:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Mon, 17 Jul 2017 00:45:28 -0700 (PDT) From: Ines Robles Date: Mon, 17 Jul 2017 09:45:28 +0200 Message-ID: To: lp-wan@ietf.org Content-Type: multipart/alternative; boundary="001a114aa0da2e883105547e9510" Archived-At: Subject: [lp-wan] Info session on M2MSAT at IETF99 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: Mon, 17 Jul 2017 07:45:32 -0000 --001a114aa0da2e883105547e9510 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI ---------- Message transf=C3=A9r=C3=A9 ---------- De : *Maria Rita Palattella* Date : samedi 15 juillet 2017 Objet : Fw: Info session on M2MSAT at IETF99 Prague I am writing to you because I am organising at IETF99 in Prague a *Info session about an ongoing project I am leading: M2MSAT* ( https://artes.esa.int/projects/m2msat) The project, funded by ESA, aims to analyse (both via simulations and in a real test bed), *the performance of IoT application protocols* (*CoAP* and MQTT) *when communicating over a satellite link*. IoT networks will be soon integrated with terrestrial networks in the 5G scenarios, and it is fundamental to design adaptation/improvement of IoT protocols not originally designed with the satellite network constrains in mind (link disruption, high packet loss, etc). We are currently running performance evaluation using simulators (OpenSAND, Californium CoAP, MQTT Mosquito). And also setting up a testbed, where we we may collect IoT data from OpenMote nodes, running 6TiSCH. I believe the project may be of interest for different IETF folk, such those working on CoAP, IoT, 6TiSCH, LPWAN, 6lo, etc. It will be great if you can join the meeting, planned for *Monday July, 17th at 6pm*, in *Paris Room (Lobby level, L)* in Hilton Hotel in Prague. I will appreciate also if you can spread the info among folks that could find the project of interest, and could provide us some fruitful feedback. We will also announce the Info session during the 6TiSCH WG meeting planned for Monday 17/7/2017, in the first afternoon session. Thank you. Looking forward to hearing from you. See you in Prague Best Regards, Maria Rita Palattella ------------------------------------------------------------ ----------------- Senior R&T Associate Department 'Environmental Research and Innovation' (ERIN) Luxembourg Institute of Science and Technology (LIST) 41, rue du Brill L-4422 Belvaux, Grand-duchy of Luxembourg email: mariarita.palattella@list.lu, tel: +352 275 888-5055 --001a114aa0da2e883105547e9510 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI

-= --------- Message transf=C3=A9r=C3=A9 ----------
De=C2=A0: Maria Rita= Palattella <mariarita.palattella@list.lu>
Date=C2=A0: samedi 15 j= uillet 2017
Objet=C2=A0: Fw: Info session on M2MSAT at IETF99 Prague
=

I am writing to you because I am organising at IETF99 in = Prague a Info session about an ongoing project I= am leading: M2MSAT=C2=A0(http= s://artes.esa.int/projects/m2msat)<= br>The project, funded by ESA, aims to analyse (both via s= imulations and in a real test bed), the performa= nce of IoT application protocols=C2=A0(<= b>CoAP=C2=A0and MQTT) <= b>when communicating over a satellite link. IoT networks will be soon integrated with terrestrial network= s in the 5G scenarios, and it is fundamental to design adaptation/improveme= nt of IoT protocols not originally designed with the satellite network cons= trains in mind (link disruption, high packet loss, etc). We are currently r= unning performance evaluation using simulators (OpenSAND, Californium CoAP,= MQTT Mosquito). And also setting up a testbed, where we we may collect IoT= data from OpenMote nodes, running 6TiSCH.

I= believe the project may be of interest for different IETF folk, such those= working on CoAP, IoT, 6TiSCH, LPWAN, 6lo, etc.

It will be great if you can join the meeting, planned for Monday July, 17th at 6pm, in Paris Room (Lobby level, L)=C2=A0in Hilton Hotel in Prague.
I will appre= ciate also if you can spread the info=C2=A0 among folks that could find the= project of interest, and could provide us some fruitful feedback.We will also announce the Info session during the 6TiSCH= WG meeting planned for Monday 17/7/2017, in the first afternoon session.

Thank you.
Looking= forward to hearing from you.
See you in Prague<= /font>

Best Regards,
Mar= ia Rita Palattella

-------------------------= ----------------------------------------------------
Senior R&T Associate
Department 'Environmental Re= search and Innovation' (ERIN)
Luxembourg Institute of Science and Te= chnology (LIST)
41, rue du Brill
L-4422 Belvaux, Grand-duchy of Luxem= bourg
email: mariarita.palattella@list.lu, tel: +352 275 888-5055



--001a114aa0da2e883105547e9510-- From nobody Tue Jul 18 06:38: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 6F722131B55; Tue, 18 Jul 2017 06:38:19 -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 q_rdgP6z8nH7; Tue, 18 Jul 2017 06:38:15 -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 C2BA5131B5C; Tue, 18 Jul 2017 06:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3622; q=dns/txt; s=iport; t=1500385094; x=1501594694; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=l5R6Expivo1nCDprMXyPUxVQ2/YowzBKEIk31SFqed4=; b=CjtNA/ZXlDFaEbtCoF2//1hUfGoQqcZ9+EN7WNWh2D59ak4nXcK4NYHK WC377m/yKFlG4L8YTGxGgXn5H+Cqym498WAcQxKpuKcdad23F3AD7lEjS 4IvYSUi4pU1g2wu75AvbR/ZSLU9MP0NWZX/3QZjsVvu7pDxKDHIqKyCD3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQDvDm5Z/5ldJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy0tZIEUB44EkUOWJoIRIQuFGwIagzc/GAECAQEBAQEBAWsohRkCAQM?= =?us-ascii?q?BASEROgsQAgEIEggCERUCAgIlCxUCDgIEAQ0FGYoWEK48giaLDQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2BC4Idg02CDAuCboMmgQ0dGhcoglQwgjEFnzQCh0iMTII?= =?us-ascii?q?MV4R4ilSVVgEfOIEKdRUfKhIBhwN2h0uBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,378,1496102400"; d="scan'208";a="455226633" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2017 13:38:00 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6IDc0rD009169 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Jul 2017 13:38:00 GMT Received: from xch-rtp-014.cisco.com (64.101.220.154) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Jul 2017 09:37:59 -0400 Received: from xch-rtp-014.cisco.com ([64.101.220.154]) by XCH-RTP-014.cisco.com ([64.101.220.154]) with mapi id 15.00.1210.000; Tue, 18 Jul 2017 09:37:59 -0400 From: "Patrick Wetterwald (pwetterw)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "lp-wan@ietf.org" Thread-Topic: [lp-wan] I-D Action: draft-ietf-lpwan-overview-05.txt Thread-Index: AQHS/8sSxrpG3fjyxEupD15MmC7V9w== Date: Tue, 18 Jul 2017 13:37:59 +0000 Message-ID: <33B0795E-6CA0-4BB2-9469-61B5D60DED38@cisco.com> References: <149893334336.489.9442381469735966027@ietfa.amsl.com> In-Reply-To: <149893334336.489.9442381469735966027@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-GB 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.228.216.20] Content-Type: text/plain; charset="utf-8" Content-ID: <391B4955B776C24FB370DCBF4B3DCD62@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-05.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: Tue, 18 Jul 2017 13:38:19 -0000 SGkgU3RlcGhlbiwNCg0KSSBoYXZlIDIgY29tbWVudHMgcmVnYXJkaW5nIHRoZSBkcmFmdC4NCg0K Rmlyc3Qgb25lOiBQYXJhZ3JhcGggMy4g4oCcR2VuZXJpYyB0ZXJtaW5vbG9neeKAnS4gVGhpcyBw YXJhZ3JhcGggc2hvdWxkIHRha2UgaW50byBhY2NvdW50IHRoZSBXSS1TVU4gYXJjaGl0ZWN0dXJl IChhcyBvbmUgb2YgdGhlIHRlY2hub2xvZ3kgaW4gdGhlIHNjb3BlKS4gV0ktU1VOIGFyY2hpdGVj dHVyZSBpbnRyb2R1Y2VzIHRoZSBub3Rpb24gb2YgYm9yZGVyIHJvdXRlciwgcm91dGVycyBhbmQg bGVhZiBub2Rlcy4gV0ktU1VOIGlzIG5vdCB0YWxraW5nIGFib3V0IGdhdGV3YXlzLCByYWRpbyBn YXRld2F5cyBldGMuIE9uZSB3YXkgdG8gc29sdmUgdGhpcyBpcyB0byBhZGQgYW5vdGhlciBkaWFn cmFtIHdpdGggdGhlIFdJLVNVTiBhcHByb2FjaC4NCg0KU2Vjb25kOiBQYXJhZ3JhcGggNC42IHNh eXMgdGhhdCBubyByb3V0aW5nIHByb3RvY29sIGlzIG5lZWRlZC4gVGhpcyBpcyBub3QgY29ycmVj dC4gV0ktU1VOIGlzIHVzaW5nIFJQTCBhcyByb3V0aW5nIHByb3RvY29sIGFuZCBpcyBiYXNlZCBv biBhIG1lc2ggdG9wb2xvZ3kuIFRoaXMgc2hvdWxkIGJlIHJlZmxlY3RlZCBpbiB0aGlzIHBhcmFn cmFwaCBub3QgYXMgYSBnYXAgYnV0IGFzIGV4aXN0aW5nIHRlY2hub2xvZ3kuDQoNCk1hbnkgdGhh bmtzLA0KDQpQYXRyaWNrDQoNCk9uIDAxLzA3LzIwMTcsIDIwOjIyLCAibHAtd2FuIG9uIGJlaGFs ZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxscC13YW4tYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KICAgIA0KICAg IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m IHRoZSBJUHY2IG92ZXIgTG93IFBvd2VyIFdpZGUtQXJlYSBOZXR3b3JrcyBvZiB0aGUgSUVURi4N CiAgICANCiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IExQV0FOIE92ZXJ2aWV3DQogICAg ICAgICAgICBBdXRob3IgICAgICAgICAgOiBTdGVwaGVuIEZhcnJlbGwNCiAgICAJRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtaWV0Zi1scHdhbi1vdmVydmlldy0wNS50eHQNCiAgICAJUGFnZXMgICAg ICAgICAgIDogNDENCiAgICAJRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNy0wMQ0KICAgIA0KICAg IEFic3RyYWN0Og0KICAgICAgIExvdyBQb3dlciBXaWRlIEFyZWEgTmV0d29ya3MgKExQV0FOKSBh cmUgd2lyZWxlc3MgdGVjaG5vbG9naWVzIHdpdGgNCiAgICAgICBjaGFyYWN0ZXJpc3RpY3Mgc3Vj aCBhcyBsYXJnZSBjb3ZlcmFnZSBhcmVhcywgbG93IGJhbmR3aWR0aCwgcG9zc2libHkNCiAgICAg ICB2ZXJ5IHNtYWxsIHBhY2tldCBhbmQgYXBwbGljYXRpb24gbGF5ZXIgZGF0YSBzaXplcyBhbmQg bG9uZyBiYXR0ZXJ5DQogICAgICAgbGlmZSBvcGVyYXRpb24uICBUaGlzIG1lbW8gaXMgYW4gaW5m b3JtYXRpb25hbCBvdmVydmlldyBvZiB0aGUgc2V0IG9mDQogICAgICAgTFBXQU4gdGVjaG5vbG9n aWVzIGJlaW5nIGNvbnNpZGVyZWQgaW4gdGhlIElFVEYgYW5kIG9mIHRoZSBnYXBzIHRoYXQNCiAg ICAgICBleGlzdCBiZXR3ZWVuIHRoZSBuZWVkcyBvZiB0aG9zZSB0ZWNobm9sb2dpZXMgYW5kIHRo ZSBnb2FsIG9mIHJ1bm5pbmcNCiAgICAgICBJUCBpbiBMUFdBTnMuDQogICAgDQogICAgDQogICAg VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1scHdhbi1vdmVydmll dy8NCiAgICANCiAgICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUg YXQ6DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbHB3YW4tb3Zl cnZpZXctMDUNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LWlldGYtbHB3YW4tb3ZlcnZpZXctMDUNCiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtbHB3YW4tb3ZlcnZpZXctMDUNCiAgICANCiAgICANCiAgICBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICANCiAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGxwLXdhbiBtYWlsaW5nIGxpc3QN CiAgICBscC13YW5AaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xwLXdhbg0KICAgIA0KDQo= From nobody Tue Jul 18 10:38: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 4191912EC3A for ; Tue, 18 Jul 2017 10:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hM07lgt3AVf for ; Tue, 18 Jul 2017 10:38:11 -0700 (PDT) Received: from nm19-vm7.access.bullet.mail.bf1.yahoo.com (nm19-vm7.access.bullet.mail.bf1.yahoo.com [216.109.115.102]) (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 3CACB131822 for ; Tue, 18 Jul 2017 10:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1500399490; bh=e8k7XLh9qUhLPzpxBiMV59RN85g2OVab6fhdQ8B2Ohc=; h=Date:Subject:From:To:From:Subject; b=DquCXMWJvL4Owny5MwDv/w7vvpVV4SzJdWgtg0zgYgRSWosFMoHyYqzVTRBtaO+B0znQM2k+YL95BCbdvhEEiwJc44h1IbVpOi+bQZRxZL+rRL76ZehRnGSULQX0wj8s/Dn7Fs2+W45WLaswyIOEwqX83omi+E3FdA9Bh9c+3pk= Received: from [66.196.81.156] by nm19.access.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jul 2017 17:38:10 -0000 Received: from [98.139.244.49] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jul 2017 17:38:10 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.bf1.yahoo.com with NNFMP; 18 Jul 2017 17:38:10 -0000 X-Yahoo-Newman-Id: 330536.99158.bm@smtp111.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Nx4Fyk8VM1m2pjN.rSZFYUgLaimGqZ7hxpkKXF02geoojOI 0zAOoM5m87XpYXTUSqkd72ADojer.6qjR8AonuU1mM4bZsSm_o3l_DCMeQJa rHNlmNjLrNB4QA5TEpooDYFVE45Hb7qvrAO1gvY1hSSZ9l2luxdpstAl.Rnq Mq_QPfpchlAB45j.6Sv4n3rm9JYDDW7NIUKH61JuVjtjkDEeK06MFoYsIZmS HedOQ9TGLsE0b8ftEwH9z4gLvkBuflaYcmHfXWU9Ae_YCHwnSUcHD0gzQtnD cRjYqI5zZjN.32JYg8bltxfWmmxNeplAM22HaSyWQqtnSxAuXkU7XtcuYZiJ ds749n7pQbWgGk4Y930uewhRXhhfKwPGZP2tLoT9lQJXaCDNxtwMwE.GMB46 ycwZFyZfJwkb23.PdaglKvWO5To7P_JCkeu2xUS4ZYaalMO9uQdcQpIi66B_ UJYX1CDEclwWUKL8cKBN9H.cdl7wrywpJFuCPGyH9kUojXncJdbe_UqkssxJ CUxrGOp7a3ILZUcM0H_HkZzxo_w-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- User-Agent: Microsoft-MacOutlook/14.7.3.170325 Date: Tue, 18 Jul 2017 10:38:06 -0700 From: Don Sturek To: Message-ID: Thread-Topic: Comments on the LPWAN Overview draft (draft-ietf-lpwan-overview-05) Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3583219088_195991" Archived-At: Subject: [lp-wan] Comments on the LPWAN Overview draft (draft-ietf-lpwan-overview-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: Tue, 18 Jul 2017 17:38:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3583219088_195991 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello =20 Here are my comments on draft-ietf-lpwan-overview-05 for the Wi-SUN FAN section: 1) [ANSI-4957-000] reference a. We now have published the entire Wi-SUN FAN specification as an ANSI/TIA document set. The exact versions are: =20 i. [ANSI-4957-000a] =AD Overview of Wi-SUN FAN =20 ii. [ANSI-4957-100a] =AD Wi-SUN PHY specification used in FAN =20 iii. [ANSI-4957-200a] =AD Wi-SUN FAN MAC specification =20 iv. [ANSI-4957-210a] =AD Layer 2 routing used in Wi-SUN FAN (MHDS) =20 v. [ANSI-4957-300a] =AD Network Layer used in Wi-SUN FAN =20 vi. [ANSI-4957-400a] =AD Transport Layer used in Wi-SUN FAN (basically just a reference to UDP) =20 vii. [ANSI-4957-500] =AD Security used in Wi-SUN FAN TIA has now published all of the above specifications. I think I would just change the reference to [ANSI-4957] 2) Top of page 21. The ANSI/TIA specifications covering Wi-SUN FAN have been published by TIA 3) Section 2.4.2 =AD The reference to [ANSI-4957-210 ] is actually only describing the layer 2 routing of FAN. Probably should change this to [ANSI-4957] 4) Section 2.4.2 =AD We don=B9t support IEEE 802.15.12 in FAN =20 So onto Charlie=B9s comments, =20 1) Wi-SUN's relatively high bandwidth, i.e. up to 300 kbps [FANTPS], enables remote update and upgrade of devices so that they can handle new applications, extending their working life. Some IoT applications may require on-demand control, e.g. on-demand metering in AMI, device control i= n distribution automation. Wi-SUN supports these requirements by providing high bandwidth, low latency (0.02s) and bi-directional communication *links= * - I think it would be best to clarify that the low latency we are talking about here is on a link basis and not end to end across the mesh =20 Don Sturek =20 =20 =20 --B_3583219088_195991 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

Hello

  

Here are my comments on d= raft-ietf-lpwan-overview-05 for the Wi-SUN FAN section:

1)      [ANSI-4957-000] reference

a. &nbs= p;     We now have published the entire Wi-SUN FAN specification a= s an ANSI/TIA document set.   The exact versions are:<= /o:p>

      &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;  i.      [ANSI-4957-000a] = 211; Overview of Wi-SUN FAN

            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;       ii.      [ANSI-4957-100a] &#= 8211; Wi-SUN PHY specification used in FAN

          =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;            =         iii.      [ANSI-4957-200a] &= #8211; Wi-SUN FAN MAC specification

           &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;      iv.      [ANSI-4957-210a] &#= 8211; Layer 2 routing used in Wi-SUN FAN (MHDS)

         &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;          v.      [ANSI-4957-300a] = 211; Network Layer used in Wi-SUN FAN

           = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;       vi.      [ANSI-4957-400a] &#= 8211; Transport Layer used in Wi-SUN FAN (basically just a reference to UDP)=

    &n= bsp;            =             &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;           vii.      [ANSI-4957-500] &#= 8211; Security used in Wi-SUN FAN

=   =             &nbs= p;            &n= bsp;    TIA has now published all of the above specifications= .  I think I would just change the reference to [ANSI-4957]=

2)       Top of page 21.   The ANSI/TIA specificatio= ns covering Wi-SUN FAN have been published by TIA

3)&nb= sp;     Section 2.4.2 – The reference to  [ANSI-4957-= 210 ] is actually only describing the layer 2 routing of FAN.  Probably= should change this to [ANSI-4957]

4)   =    Section 2.4.2 – We don’t support IEEE 802.15.12= in FAN

=  

So onto Charlie’s c= omments,

 

1)      Wi-SUN's relatively high ban= dwidth, i.e. up to 300 kbps [FANTPS], enables remote update and upgrade of d= evices so that they can handle new applications, extending their working lif= e. Some IoT applications may require on-demand control, e.g. on-demand metering in AMI, device control in distr= ibution automation. Wi-SUN supports these requirements by providing high ban= dwidth, low latency (0.02s) and bi-directional communication *links*&= nbsp;  -   I think it would be best to clarify that the low latency we are talking about here is on a link bas= is and not end to end across the mesh

 

Don Sturek=

 

 

 


--B_3583219088_195991-- From nobody Tue Jul 18 21:08: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 EF25E1274D0 for ; Tue, 18 Jul 2017 21:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIyKhT8wDuDE for ; Tue, 18 Jul 2017 21:08:01 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058D91270AC for ; Tue, 18 Jul 2017 21:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1500437281; bh=UGpUzgBzBB+50q6SxpyJBH15yPFnn/wGskxz z6PgAQE=; h=Received:Subject:References:To:From:Cc: X-Forwarded-Message-Id:Message-ID:Date:User-Agent:MIME-Version: In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace: X-Originating-IP; b=jtM3L+qI3frLaH61bqvdtLoirxhcdXqV7fylmJJBCZeGbo iR9HfxSVuq8Ic9jqkVNtoAC7MrTnxsZVKLy5mdEFZb5sY6OK6vlnFtdihDJy5pt9KtZ f5ecXWJba0eIlawsov/EQjc5bjR1Jixpr1KwTtQ6dbkTIVn2bNpfXNW/qb5A8uQFsnc l6ZX/W5HtFHJxKWm4eJrTB1b8HSSN2rcgfx2jbRljcfUZwrKzWspvnr5+6oMyq+NvdF 2T+8vZcmRgGIDp/X48/0i5Hc5n8Hkk+jQxyYO7Ztm9tlQV2RkXt2fmCUeE2pUOYNa82 aLkYQH5FKq77iwV+NahgJvi7sW/g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=iFlHKgT2kV1LtJZKzvQrkVNPHBRoxU+zEonTLe1VEKSq3rLlt82pmBPys64r4GglGTe3PRYCm2HjXcSU/XZfjhZkSs4dhe2CjjEfi7WBULBL1tfsHKh2VDk9tdTi3v1MelcYtvcqMHnnagwBIworOrIYjF3/TLkJWSQCVKf0YKkJsPDbXaMCR1+MQ/KK+aKdZKR57x5tWdnTmgroofxpSJ7LSish6DN/Ihi0fGmLfeYC3Qz57aoWqY0ufvsHdmvY09cX2VuNhbx6AQm2Gye4zOIxmsO3OK9mmVgPhLesBZF54OLiV0C4lW/Yi0IPcMievxlzfmAw6brAxrOFxu6C7A==; h=Received:Subject:References:To:From:Cc:X-Forwarded-Message-Id:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.157.127] by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1dXgH7-000EnF-I8; Wed, 19 Jul 2017 00:07:49 -0400 References: <6f22c5a9-60f6-3995-f8e5-79f0443ff748@earthlink.net> To: lp-wan From: Charlie Perkins Cc: Bob Heile , Mingui Zhang , Remy Liubing , =?UTF-8?Q?Jonathan_Mu=c3=b1oz?= X-Forwarded-Message-Id: <6f22c5a9-60f6-3995-f8e5-79f0443ff748@earthlink.net> Message-ID: Date: Tue, 18 Jul 2017 21:07:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <6f22c5a9-60f6-3995-f8e5-79f0443ff748@earthlink.net> Content-Type: multipart/mixed; boundary="------------A556DCA9E7EC0E57B422A2BC" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95a430b483b5cfea8607ec5b6c5ae5293a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.157.127 Archived-At: Subject: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN characteristics 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, 19 Jul 2017 04:08:03 -0000 This is a multi-part message in MIME format. --------------A556DCA9E7EC0E57B422A2BC Content-Type: multipart/alternative; boundary="------------FA540C7A4C4309CBFCF5E1E0" --------------FA540C7A4C4309CBFCF5E1E0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello folks, I'd like to suggest some additional text to be included in the Wi-SUN overview section of the document. I think it is important to emphasize the following characteristics. These comments can be viewed as more or less the distillation of information described at longer length in our individual Internet Draft contribution submitted earlier about Wi-SUN. We have received many comments about that draft, and it needs to be significantly revised and resubmitted as soon as possible. But the [lpwan] Overview document is in Last Call, and we don't have time to revise our individual draft before the end of Last Call. Given a little more time after this busy week, I would also like to include a fuller description about the Wi-SUN mesh protocol choices. If that is acceptable, I will provide text next week. Regards, Charlie P. ----------------------------------------------------------------------------------------------------------- -Coverage The range of Wi-SUN FAN is typically 2~3 km in line of sight, matching the needs of neighborhood area networks, campus area networks, or corporate area networks. The range can also be extended via multi-hop networking. - High bandwidth, low latency Wi-SUN's relatively high bandwidth, i.e. up to 300 kbps [FANTPS], enables remote update and upgrade of devices so that they can handle new applications, extending their working life. Some IoT applications may require on-demand control, e.g. on-demand metering in AMI, device control in distribution automation. Wi-SUN supports these requirements by providing high bandwidth, low latency (0.02s) and bi-directional communication. - Low power consumption FAN devices draw less than 2 uA when resting and only 8 mA when listening [COM]. Such devices can maintain a long lifetime even if they are frequently listening. For instance, suppose the device transmits data for 10 ms once every 10 s; theoretically, a battery of 1000 mAh can last more than 10 years. - Mesh topology Wi-SUN FAN mesh networks offer self-forming and self-healing capabilities. When a new device is powered up, it can automatically discover communication peers. If the link is interrupted by obstacles, a device can switch to alternative redundant paths. The reliability of Wi-SUN has been proven for years in harsh and remote environments. - Scalability 10s of millions Wi-SUN FAN devices have been deployed all over the world, including several deployments with more than 1 million devices [COM]. This demonstrates the scalability of Wi-SUN FAN in urban, suburban and rural environments. The following references could be added in the LPWAN overview draft: [COM] Wi-SUN Alliance, “Comparing IoT Networks at a Glanceâ€, May 2017. [FANTPS] Wi-SUN Alliance, "Technical Profile Specification Field Area Network", May 2016. Figure.8 needs a column for Wi-SUN: Another paragraph could be added regarding the Wi-SUN security solution, something along the following lines. Wi-SUN has made it a design goal to rely on industry standard security solutions instead of special-purpose or proprietary methods. In this way, users and equipment vendors can have a high degree of confidence that their system will truly be secure. Moreover it will be easier to provide secure interfaces to other system modules and components, which are more likely to support standard security protocols without special purpose coding. -------------------------------------------------------------------------------------------------------------------------- Regards, Charlie P. --------------FA540C7A4C4309CBFCF5E1E0 Content-Type: multipart/related; boundary="------------0217E3C73D700DF95185ABAD" --------------0217E3C73D700DF95185ABAD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello folks,

I'd like to suggest some additional text to be included in the Wi-SUN overview section of the document.  I think it is important to emphasize the following characteristics.  These comments can be viewed as more or less the distillation of information described at longer length in our individual Internet Draft contribution submitted earlier about Wi-SUN.  We have received many comments about that draft, and it needs to be significantly revised and resubmitted as soon as possible.  But the [lpwan] Overview document is in Last Call, and we don't have time to revise our individual draft before the end of Last Call.

Given a little more time after this busy week, I would also like to include a fuller description about the Wi-SUN mesh protocol choices.  If that is acceptable, I will provide text next week.

Regards,
Charlie P.
-----------------------------------------------------------------------------------------------------------

-Coverage

The range of Wi-SUN FAN is typically 2~3 km in line of sight, matching the needs of neighborhood area networks, campus area networks, or corporate area networks. The range can also be extended via multi-hop networking.

 

- High bandwidth, low latency

Wi-SUN's relatively high bandwidth, i.e. up to 300 kbps [FANTPS], enables remote update and upgrade of devices so that they can handle new applications, extending their working life. Some IoT applications may require on-demand control, e.g. on-demand metering in AMI, device control in distribution automation. Wi-SUN supports these requirements by providing high bandwidth, low latency (0.02s) and bi-directional communication.

 

- Low power consumption

FAN devices draw less than 2 uA when resting and only 8 mA when listening [COM]. Such devices can maintain a long lifetime even if they are frequently listening. For instance, suppose the device transmits data for 10 ms once every 10 s; theoretically, a battery of 1000 mAh can last more than 10 years.

 

- Mesh topology

Wi-SUN FAN mesh networks offer self-forming and self-healing capabilities. When a new device is powered up, it can automatically discover communication peers. If the link is interrupted by obstacles, a device can switch to alternative redundant paths. The reliability of Wi-SUN has been proven for years in harsh and remote environments.

 

- Scalability

10s of millions Wi-SUN FAN devices have been deployed all over the world, including several deployments with more than 1 million devices [COM]. This demonstrates the scalability of Wi-SUN FAN in urban, suburban and rural environments.


 

The following references could be added in the LPWAN overview draft:

[COM] Wi-SUN Alliance, “Comparing IoT Networks at a Glanceâ€, May 2017.

[FANTPS] Wi-SUN Alliance, "Technical Profile Specification Field Area Network", May 2016.

 

Figure.8 needs a column for Wi-SUN:

 

Another paragraph could be added regarding the Wi-SUN security solution, something along the following lines. 

Wi-SUN has made it a design goal to rely on industry standard security solutions instead of special-purpose or proprietary methods.  In this way, users and equipment vendors can have a high degree of confidence that their system will truly be secure.  Moreover it will be easier to provide secure interfaces to other system modules and components, which are more likely to support standard security protocols without special purpose coding.

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

Regards,
Charlie P.

--------------0217E3C73D700DF95185ABAD Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="image001.png" iVBORw0KGgoAAAANSUhEUgAAAiMAAAEpCAIAAADOO7UdAAAAAXNSR0IArs4c6QAAMZZJREFU eF7tndu27LCJRTv5/39OV5o0YQNCoIst26seztjHhRBM0NWy6x//8z//869//ev3Lz4gAAIg AAIgsIPAP3cohU4QAAEQAAEQYAIYaZAMIAACIAACewn8U26d/eMf/9hbG7SDAAiAAAi8moA7 jmBN8+qYwzkQAAEQOIAARpoDggATQAAEQOCbBFoH0nCd8gEcwEH2DMgH5APywY6Vv3ZBn3/f mOFG8ttfw4nnb04s4DUIgAAILCHgjiPYPVvCFkpAAARAAASaBP6cPQMnEAABEAABEFhOANtl y5FCIQiAAAiAwB8C2D1DQoAACIAACOwl8OdEwN6qoB0EQAAEQOCTBP6sab72joCv+dvKcHAg MuAADrKNIB/GxsTyOwJ+BexnrO6xUoj0GDeUAoEbCXCnQYM3fcZ6cNX/8EDIOm1dVuZGFKia CURnz+jZGn70ZtOjNsFwsrxGDF1IfRDYTYD7Deo9+F+uN9mu6bEM+aH229Iv1br17nYc+gMC tRMByRQ5kzieSz0zLrAKBJIEMv0PZpNJmBeLZUcaGT+5HHb/dtfLciHMTpLaQF7hCFbTrh5Z USZNL6aP6kDgUwTczbRPEfiss//sTgHsMGBXqYSPrvOalzW3VsFyIayGAVoy22EmWE3bejHM fDat4fgJBGzf4rbrlqn/flnW30/GKSqVkYTMlQT6a5pScvDgEfuwY3nR0olNsyvzCXWBQJWA Gk7k1NadWXb1Y7DpIrpeoD/SyPXK9fZN1ohhZhIgioPAbgJqOKlObXebB/1LCMy+92xsoeqW GlMVUMAwsyRFoAQEqgRoVcH/VouT/EyHsGPXZMwLlPpPNGVIVNcsI+3eNaG9MhKTK1b1t00a pY01cFRUkrG8e50v2nrjMGMo4iaNlklZCg6rOLgjTatdt9ppIC9bvRqZ5A3jmY4e+TBGz+X2 p2l9jezX/A3aM3rYVT3sWOM8qhTaBWZgMwnp5k//7NlMlSgLAiAAAiAAAnjDJnIABEAABEBg LwG8YXMv30don7n1+ggHk0aCg7rhkeT2VjHkw1hk/QNfyRMBXOXAhr694T/mwPJSk/vR8e3N 4I6lCzM4FuGedGjJ8+1QqiUTryUcbL024brGjN0BlonRrSLIokkOP82lkyy2W1cMXb/iO+H2 24FWM8+hVKnbMalDQKqb4sRe4m/L2os5tPKnxad6vRSUGWH/Pk2skc+2zxxyn2n8Mw7vLhvA Idb0UY2Br8uv3CGBuNl/W0OI5CxLXcBBjZ3KZouiZVILqcuT4HBdt6eZNNKG3rVTFZGzB5kn jCvOK5Utu+O+Sr8kY/sZG9a78nyVv4EeN58DPlX5C1xoVRE9uRnH+EajD69aDelqRNlt/F1L /n31tnien5/x4Genfi15uh7kFefY9dPwHfmcmTTsy7cdHq3V2ZpHxvmz1oaqtsGzZ78wy4+c c7nXSYC+qpr4EXnqI/J8qvIfwfgyN/P58A7Hrb/IcxnZaj5U5fdlUfZtNMpbubRX8yn5lfST F/7nOL8Pa6BZjsSZuRuN0HlTS8NVXm1XslXvgL/dus4UIALBTKtkdnVaRrUnM6pkyTXCY/5e Y9sJtVT5VOV3+zgy0vDqhBtVy0q7o7rbn/P1y61VuRbkFXFmXOE+xe3fjxps7MxDdcenNYmZ FHJnYBmFtilxnmSKU5O8K+5JC2Mx198z83yJv1Ul1XyoylftqcoPvvdMtajnzqSqvPbJd4dt VXVVfp/lVc02eZA/rX7ha2Ssv8/N82q7yMhX86Eqn7FhTGZwTWN7Pbf6zPR8zO4zS5G/amrp 7mnY6Sf3v9I13hKxSlx5LntXhu2oN8PzhHyoZnt1CRJwiOf+J8AZtuHMPB92Z0nBaqYtqXRS Sf+9Z+yV7ESUq/yVe11qaGnb0UN10Uzua7vxtihaV+ywJLsSWYrHG/KoxVOxzXuXl4znE2Qz a7N8ulFu5ZXyWprhZlQ39C1HuhbGmkvtQkWT5ijSU74S+9ttX1Uak/kwUJ07Q1qe5wOGTebD QI1qoqnywYKy+S+T8GL7OaWdtanM5oszrBqG5fJf87cFEByCFrI8685XiHxAPsxkqZs/a3bP ZsxCWRAAARAAgXcTwBs23x1feAcCIAAC9xN48AH8++HBAhAAARAAgQQB7J4lIEEEBEAABEBg ggBGmgl4KAoCIAACIJAg8Oe9Z088pp3wsSnyNX9bIMCByIADOMg2gnwY611dbljTjMFEKRAA ARAAgSwBjDRZUpADARAAARAYJNB6iBTXCSg4gINsWsgH5APywQ42Qbug9wn130YzOII9oRie heZ9+VveWnFajiAfkA/qPg3axUAjxTsCBqChCAiAAAiAwCyBwd/cnK0W5UEABEAABD5DAG+j +Uyo4SgIgAAI3EQAZ89uAo9qQQAEQOAzBPDes8+EGo6CAAiAwE0E/qxpvvZM7Nf8beUYOBAZ cAAH2UaQD2Oj0sg7An5l5GesYpQCARAAARD4MoHo7Bkdi5YfDPJfzhX4DgIgAAJjBGonAvAc 0xhllAIBEACBLxOojTRMyt1Vo4u0361WP61duEBPS9WXowXfQQAEQOCJBDpvo1EDBq1p7MsG +ArJK7GWfKCHarGq1iJ235qwtopHaAMHChM4gINssMiHse7L5dZZ07Tu0wQnBewO279fr/b/ HzI9uQvHYkn5MS4oBQIgAAIgsJXA4O6ZGoG6IwHL2421re5BOQiAAAiAwO0EOmfPkvbFZ9Lk t/95g/T/7YzhAwIgAAIg8AUCf9575t44kRR47dK6f8ObYyzA92wG9LS22lbtn67S8/REAQeK IDiAg2zLyIexns3l1hlpxmraWmph+Beq2urybuXggB4WPaxtZWgXYz2PfyKge4tlrLJ9pR5n 8D4U0AwCIAACjyCAN2w+IkwwEgRAAAQeTABv2Hxw8FaZHh/oWFXL+XrAgXcRzw/WBRYiH8Yg u9z692nkE5RjFR9batM+rAs6uel3C+3dHOiBKkqDJIdbcmY3B+lUksMT88E9LjQT0Fsg/Ay+ Jh+SmRAA3GTncMj8+zRddVUQqyYCq/R0HVwuQMTkI0f5Kqq085qvl2QOPMC8ybs8z6/lA2U+ N4E8KFeSuq03ZY7Kh/mO7hFwBp/cnMyerxV/RCp8LSg3+ot8uBH+aVXLFf9pti20p/PeM15C qgVRa4Esr6uHb+SDNe5zObL5uXrIGLsFIXdmSgvtfatO1iyrYNuskcs3HEopcgEHtReRyR9e CQ3HtwRh326J1PydfHCTKhP3TD9QjeyY/DXtQqVHpn9zm4YsmOHMSsbgBKX80Ku42tkWFVMt RInF39pexp3T2cEsqIX8dNttvsvYmkkcCdtyeNBVf1inlieBq3ArBzmrcP1tzWbm41ult5XD 1/LBwsxcsY13X1C66bGvarevC/jku1+397N9+NauxuXW2T3jMvESb3g34KefP93AdwXYjGF7 ulXkBVqbyyfYlvdihyTlEn1IvxyNgpQ4Kr5VMsgH6gTd+K7tB6qhOUe+xWfSwmT7mqwlLh69 94zHPdkpLLSGhjH+LNR8jiqMK24sOOgqtWQ+tLrmc4I7YMnH88GN7xf6gWSqtPKfJ/qTy6wb 21f/REBmJODJqQSavxiHwdWTjNwhYi9wYSFJSYOyq8Xnrdze6lcrSb4W31JjCQaPVXlyAv/o eRq5uaE2OpTpaqZG37Yuym9Vp6OgWz1uvbExtGZ355KTE4RSu5L9qfqbLFTarpz8buLAa2K1 RWb9lat7yYGud+NbatiB8CYObjt/cT60/E3GncjY0F/ZIjh1d1Qa5HO3X3U7VU7puB1d1pTc dtQ/e7aqGd+lJ54y7MikuzwdrndTDztsz10FwWFrD3tXWIfrRT6MoXO59XfPxio7pxTGknNi AUtAAAS+SQBv2Pxm3OE1CIAACFxH4M/Zs1U3oK4zf66mr/nbogUOvGs0l1AvKY18QD7MpLKb P9Hu2a+A/MzU/crIfY2P8pf+O5MVk8Vnqt5R1vJJ1vJKDtzkS3lSEk7iPVlMhn5tf3JaUkUj Dd3hkI8+TMbsZbdMvsZH+TsfzXkNAwm5rwVaPsm6ShySOgfIrCoi3WEmSeUlFEmdx4qpO+dr +5Pg4YFbgPwzH9rTTL+FV1DpB/nkk+e0YMGe3QTOHxF3E5jU/7L+pHPKWY26/F+VRurwu3pW 4Eec5SfPg08GTxVX3g0ofwefPAeZADKUtlvhHJC5Yc/7d5Wo5LHAZdRUXWRVqwo7TOY5tFKl lA+tdsFmV+0fSGC3yBIOTF5qc/sNyYHssXmirq/yNNYzzyHQ7yov5Y/sVIMO9vrpoO+aaod2 JLACVpHbAQViFICWQLfgqjybzyQ3Mx7HJ89B9hSyO2hlkepl4uyyKaHyiv7bGu1kcdlHt1qv zaI8h2CkcUe+TLOSBcfsP61dJOMVdK/dhFnl8qYRd8lIM9yfuH3sVmKtjv13vf/es1YMfv7z Z5X1svPaoX+VnV090njZO3cLxgIn8PnZcP0sKejZW3lyl5HEZ57SXfZPpqgaaCeTf1M7Wujj NapewGHwyU3ZnGSjoinn/Fja0n9NXOdreT2fQ/rBp+fJfKa9WwPiS/Hd3Z9ckEWFkSbYW5ic ubCfLT2r9G8F+kE++bjkJWdiVKqlJDxj1aayj7B/7YzkES6vCvcF/ckqUzN6ohMBKq5qL14t k+V/3Y1FV75VRVD1/IJJDmwzLeFYPpnAx/FyNbjtnAB2UfBiN5Z39dBF0pDRw0pYmIqrCY0N fdC2M0il8Up5Kc+H7c8YmZFZxYFjzTSSHDhecT+Q8WVGZpJDt2qlv9uIWKHNLrcf221/y0G3 3ue9YXMhvoWqull1ssBaDjPaZsrOE7639nn7V2kAByK5m8PT9ZdGmsLu2ao8ntQzswqZrBrF uwRoXuaufraW7SqHAAicRkCuuZfbtnsYqxrs/JBMVQXkQQAEQAAEQCAg8GdNMzYVfS7fr/kb rHafG8SFliMfeNdoIdXnqkI+jMXO5dbfPfsVow/Xqv7rWoMgjQUJpUAABEDgfQQ67z2jzT76 8OCRuVOSkYlpYqx6X7bBIxAAgW8S6PxqgBwwtt6/+iZ9eA0CIAACXyDQ3z0LNvdbG2t2e40l 3Y04V8+v3sw23ReCBB9BAARA4NEEBt979vNZviBBbqzRdQlFbsHJjbjWdVLOVTyaL4wHARAA ARAYX9OU2LXWNErJ/N2dklUQBgEQAAEQuIDARSONXADZRc8FfqIKEAABEACBuwhEZ8/UEYCF D522zpW513EI7a7kQL0gAAIgsIRA/71n9nCz7fq7LytURbpv3CPfqNS+LbWFY+eSYNylBBw4 3/Yl213BHagX+YB8GEgbLuLmT3+kGavyEcn6CCPH+JdKgQN6FpkwyAfkQ6kDUcJu/oyfPXNN 4Tv/mBvOhAplQQAEQOBNBPZuT72JFHwBARAAARAYI3DR2bMx41AKBEAABEDgBQT+3Kd5gT9w AQRAAARA4DQCWNOcFhHYAwIgAAJvI4Dfp3lbRAf8wRNLBA0cwEE2H+TDQGfSakeLz56NWYZS IAACIAACLyaA3bMXBxeugQAIgMDZBFoPxOA6xQ0cwEG2YOQD8gH5YMe0//6QpmwhX3s2+Gv+ tuY24MD3J/DEMe2zgwM4DC+F/HcEDKtDQRAAARAAARDIEMB9mgwlyIAACIAACIwTwNtoxtmh JAiAAAiAQIYA1jQZSpABARAAARAYJ4CRZpwdSoIACIAACGQI/PnNza89E/s1f1sJAQ5EBhzA QbYR5ENmCLEy/k8nB6ec3QInH3+sns6syo9xP79UksPafFj7g6pLtCU55AfskxtLkJbgwCPu jgjadqQ64V/t9grHq/rVDhfiPm3klDM9d0OeX29xtY8+38KqR0fJy0yYz4e1wVqrbQy75fPN SfFaDu9jGPOxmazkJZBW/0x9PX0OARi996zl81g7RKn3ETihf38fVXgEAgGB7uChlhRd+Wto j5wI4J9wpq1tOWbyV/aiFeYrUiGvWwNVgfw11FCLG3QZ0DiOLkCbV1yLTIZuvh0YHTeZB/L/ QNdKJrlxlH2I7U/y/UbQL5WMvFeYxolDFiILUfx5nqa1P+teJxY0q20J8JzXFbalmLKaLMfX GUfL/havqvxC7kepynOQDUDGSGrgv1vxDeJV0qP0573Ylw+qg3DXfF0+XW67k2cJSWlkq5dw UXTDGvPp9kt5evMcgkyzfHhyRiNNq33Z/naAWB7CgKTL7c/Zs6pSZiFHlF819FHa3L04Jdza jXH12ypUjaxc/lH1EfI2jtdvmqlQnhwU3h+XM1M3A0lANpaxPD+ThryFsNzCOB9sv7TcgHmF Lh/uo9+3rBnZPYunhNzSMsFgYXdwshpkM+ZQtSqywtd3kRkIT5RRJLlhTE4DW3pKcT+NJzFx 20Ur/x/t7wX8X8ynNVO/gOrWKlaONFVD5aKEUqe1TKler1oC+TEC3WXlmNpuqbvq7RpWEpjP /1J1twhX5+ZBZMe+usXrfKWWT3em3p3MKZ1d+by1M5L9+zQcYLm0l1XK6a1qPOSk1KC0qezp VlGVj9EcEoOZ+C0pm+TgNnUVfbXWGYuXtSep50djZtma5BCs6dVXbj5Ti6Cvkn7NODWQIas4 SB9jfxkFdxe2V2n1Mxz0FswBAlRkkkM3TxSfVj8Z+JX56uLkaXHrjzTDcTq/4KZMOt9xZSE4 bO1ZkA+PI4B8mAmZ25/cuXs24wzKggAIgAAIPIUAflzvKZGCnSAAAiDwVAJ/1jTvuNGaD8XX /O1uHOfRvVIS+cC7Rq+Mb9Up5EOVWJA/0fNBY9U8qFTp/oQ67PAgN7umJjkQAXVrN3m/UZbt 2qMEbINPVjpQUVLz8pvPrqnJuFTd7MpP1ntXnnT9qgq4HFr9gM1wd6BqHcaLT079LA/0q7LS TelC3I6sX60TCjyctBqLf58G43Ym/4gdfzLQMjKZqs+RkYlFfyf75ZKk9ZfrKvHfx00lg+o7 qnEP5PN49zk7oPmuPBkwtVok6AfcYFHGUv6zgM1nMkO2Kdu+rP5YngYnNxa2Hbl+de0ppTpO BPSTzQ7RD+0C+q4mJErpldD3BpEv50Mrfu/Lk2o/0BobWnOpu1pC1a8xO6OR5mcBfWh45L/l f92LLDBm04NKMRbVriQ06Y6U5yJJzqwnkL8LneuXypMuh7uMX1hvJu6Kg9tYVHOzobft7hGN 7sV5Qv11dXzNy7v6uUY7WtgrC/OcF2F5+6P3nrVWT+SD/FB9vEJkgbwdyylco9BC4BhIIHQx 4EbC6l/WQLUwzO6qeavvtjm1/FLXZXfp5k9stuyk7l1DEAF3kiE3RqQ7pTyxmZPJn9Ma3V15 sjX5FyqXcwWldmu3OdCOltgzuHvWammyn+V+c2F4blelJptudxMYGXOzEa3qv4bPwNzNtqWq a63O+hqXVS3VkbLq7IBT946+rsG35MkAuoEith/gSUayX+Z5eaZ2XqBYpHQlH32u1y2i/MrY lpTpjDTsmHJGtbS8n0mzjhWT+dGaswfGl7gF+ltxOZZb3FO/O38G8uQpcdxtZ6m97DbGLlLl lbE+Op/5Y/qrTErjX0l59JubeUXJYTyv8CjJyalZAIe/4olJaXpyI6V8C8kY+az8SVqbFGM+ VfkM2Ntl3pQncT/Ag+IA80w/MKPfmiR9Cfxa2C+l3ntmuz/VKiif3IsD3C8rUurWpXfcftRF pZC+lY0tQERlXQ0ExP12SUtOcpDtgcLtcpAu295zIFVaSpbnSZJDN9XjuLeinMmTuN2p7mOY T56DW8VdeTLsb6ugy8H2A2qc4NZKfygaNnmsvMqQqn45d3GTSrbBVlemlLRQuP2PL6z6hSU9 1/KQb1I42aI2WZVXu8r+VXrylp8pCQ7cOX6qHyiNNGembmvI3xrHVntxr0/95uaDoL/M1F8s 0S2+LKZwBwTWEpjc9o+NqfY/hUMLaylAGwiAAAiAwEcIDJ5y/ggduAkCIAACIDBPQN+yntcI DSAAAiAAAiAgCWBNg3wAARAAARDYSwC/T7OX7yO022PEjzB7uZHgQEjBARxmGpebPzh7NoMU ZUEABEAABPoEsHvWZwQJEAABEACBKQKtR3twnbCCAzjIBoZ8QD4gH+yQE7QLeo9O6m00U0PZ wYWrDx8d7MqUaeDA+/Jbn6meCtKFhZEPyIeZdPPfETCjEWVBAARAAARAoEsA92m6iCAAAiAA AiAwRQBvo5nCh8IgAAIgAAJdAljTdBFBAARAAARAYIoARpopfCgMAiAAAiDQJfDnNze/9mzw 1/xtZQM4EBlwAAfZRpAP3fHDFXC5DZ5yVroeejZ08jQnQVA/InkjCmlPKUWSHGwCxT+gOcZH 1mLZ8rc7OCc52DFphzFUyybNcXpM1tvKk1JOKuHh3J6s1P5m5Qva+wyTTNllp5xJkfx8c/CX WUh/Z/qFfawytWcSpSXDPnLoZftXFxWNJB+VWko/62x5uo+tmupek/+7AzqTDEHZVp7MVHcC iq+195l42bJr3nt2Qh6s5ZLXdk3vlrfndsl/Pw/8f6u96laMnQqV8mpyJj7DrWTnTEUoezsB tPexEPxZnifbaiDm7qrJHY/WjoraFSnpGfN8ye6Ecod7HNd+qpGttcKyjw42plo8pUel3YZk 3C0xLqg0yOu8EOnWEueVxGV79q7yTJIklVyZ/8rTTF4l19YBkCSHvAaVD6oJxPksa4nbV6An E30rYzm8o72P0ciXcvNnZKRRPWbQlcgq3SApAe5ebQNTSdaSzONYNdLQ8MD/umpdN6Wpqzi0 uv4YS75nCXo6GTJlhuLTMqY70rT05O3fysHtmOK8jROjNX6zF5uAzPN086TKp+V+VU+pT2i1 SrougQdt7fD2PgwkWdDNnz9nz5KKaGiRH06s3x/yoxRyq+vuNqzSk/doRlLtF1FGBhyCrrZk RovnfE8RmCHjnrTW8ukWZHoZyW46dZVUBXbnf9IeOYwN5FuyljExt3+IVT2lf/hUex+Lvi21 +Hka1QK7XQDHTHWOVT2rcKzSc6P9ajq5yqOL9RDAbqVbx9Ru7VagGvdW/lerrtZb1X+a/Gn+ 3mjPU9r7yEiT9y0vGafyKj37GkzcLbr2y4vU4/C/M3ZS0t9IzO39M8NGYLbL565hJs82LzkW 8Zb+3fWOWbuv1PX+or1Xo7nyPg3tGkkLKB7uRSlmu4wxPWXn555XYCPZTbmbYTnwFSqoktUd aUoclFq3FhdRsstWQ6Nyh/9rIVg+QaSCWpaMxHHVmRExSOlSvCRAmwxu/rSaUreJlZpGMh9a Om2/H7eLwPiWqjHOJQgUZRmX17T3KoeqvJs/gyNNte4z5Sdb1JlODVgFDgQNHMAhngEPNK4P FnHb0cju2QfZwWUQAAEQAIFhAs42zrAuFAQBEAABEAABS+DPmub6G2v3huRr/rZogwPvGt2b kIfUjnxAPsykops/g2/YnLHjnLLz+/Jr78TeRWYrB3uH303E1sGz5C36JehKHFonF5ZYcq+S EgdranAi4F6/qrX7d7a913xUNV8mL12guKhTWu5hDSujTkP89ARJghMBOr7zLco9P3ZZGq2q aB8He3rHPYfGYi35VZ7GevIcFtqZr/QaCHEnkrThHXxsaAb8ujG+sf1qEFKn7NzztMnuznUZ JwKSbSclduUEPGXQTUKtY80tPtXrN7n1n2ptQ0Lc743INbW/I+52xXmNXxhptmTpL3jyw9u+ dJGmjRxyluTr9qtYfosPlyi1ec+sLql/cSVB3FXQpZsyuCpVXhb3mI9FZBvLmXxsY18SX7cf 4JQN+o0lC9Nu2yg9IY77NP1XngTEVUfZmsurhepPoZJ0V7J2rtHV000OV8BWVNWT5CAbCf/t PhzHiKqWzMgnObTEgngRn3jnUMIJtikCVTO+y7JJDgvbhZv/3Fl3N22uaRdJLEosbsXKx4CD mx4lbjz8UCkuG/glJV2x/EWsaaaa5y9g8uPOQVQvLPvQ7q6LnCvN6JlyMlG4xSEoSkWsQOt6 wor7RYJ4dWOt+nqpSjnGqko6L6bDcdxh5O3tgg3goUJdiWnH9tuWHiTDQFiDtUjJi1LVGGlK uLLCquftNjaOvZojVPVk7TtG7ll3aLrYVsVrlZ6uwQ8VuJ2PnA9Rm+VPBmnJ/kB/q9/I2ODK 7JvnrfnNzWHHHl3QTj1a7uQlu1OhA4m1vLNTp5bkKj7XwNnkVwDhWXxkFILpsxusMQjX8Kn6 ohzMuEZV8L/78lnO8AK/FtqD956tv0/zyw+VVRRX96LaM1Fz/DE91QR1N1tLSgLX5FcuB6pI pXt3FVgyLylc4mD96sZd+igdJFX2CpudzJ+km12xEgerjclIs7suMIQWjev5uBy6cbfjRDK+ RNIdaVSlyrBWvKwYtzWuiMPn+tWyR5rqJoBtvxhppkaabqN9hMBkz/IIHzNGgkPcg2QYvknm KfmQHGmWh6ZU7+Bvbi43GgpBAARAAARKBH59fTAcTm73xZZUh2G8YbMUWQiDAAiAAAiUCeDs WRkZCoAACIAACJQI/LlPUyoJYRAAARAAARDIEMCaJkMJMiAAAiAAAuME8Ps04+xeU1KdUX6N X1VHwIGIgQM4VNuOlHfzB2fPZpCiLAiAAAiAQJ8Ads/6jCABAiAAAiCwhUDrIW1cJ9zgAA6y 4SEfkA/IBzsU8Rve8I4AvCMg+qHWLbOYU5VWH0Y71Y9Zu8CB79Pc8lak2fjdXd7NH+ye3R0W 1A8CIAACbyeAkebtEYZ/IAACIHA3AbyN5u4IoH4QAAEQeDsBrGneHmH4BwIgAAJ3E8BIc3cE UD8IgAAIvJ3An9/c/NqzwV/zt5XM4EBkwAEcZBtBPowNfy63zilnVebiM3+7T1tu1d/6Dbsg eFvtub5eJtD6rcmxPN5XqvUbhVzjZP7fFd8qMddOiuYMgXkNSUdWcV6lR5nd6lRtB61+qNRt R5aqvCLbYJLevFj5lDMVkJ+LB3k3rS+2YZg7cSs1zplmPGznvoLS/SqKfVblNbPN/3367P96 2+FPKb6n5XnJeHeBWNUQcw74rK1oONytgrJnkKa28i1uR9ZZV+dyL6oKa+89OzyEVechDwIg AAKvJHDaTGXwRMDPDfnhULnX6SLJ2L/pK3md/2thdYXZgDOzp8tNms1MFJwzXStZFeQJh9ii OCe43TgqU1uWB3riRtFqL/v6l59muXvjtmXZD1j7VS/RjW+Q/24/EPQbpeR8lrCNy5n2/9l7 JaNVBsj/8r6hFaMsdK9TBvBXSoySxtVsFSpVMndb+gPurv61cQoct760+LewrzJ1HwfV8cX5 w0C48XTlVxEgPWvzP2gOQXXdNA7aS0ttlVLQ7mzjDdq13QJxjY/7jVLnsIrAWj0u/xZk29+2 2oU00o2LakfVNBiWd137c/bMquYdavqDO47WXExpSO62sVhSfhjBEws+nQmn0Az8ZL7NVNEq K3fV5cxGmjRWLzUo+pCGZKxte3GNUdBkRVWDue9Qy5qqnpaPQXyTTAJLFnIY8LdaRHa53bJx XNw16F1NaXD3TI1A89nQZRoLMFN3OJ1UXi3OHUe1IOTj7r7UCLfCXJX/rGd+GLAjujVypp2q QXEt3lU8XavWcljr+Ly2fFzu5RCNNPkesyVpr+d1dmOwUFW3LggcReD60MdzebJHrlEyFkoZ tWcgaWdUXRCdeG0aGDlgf6lISfgCUANVdF2g1OJ/ZRVxXGbmFgOORCtLuZ61CwKFgO2uXv/V IlsjN0uFjP/b0k8CrEo5Vl3QVOXz6Nl+FekSN6mkpTBvUpQE5gbbKrWkR3bTBMTlIDOEiwTy S4xUfbqMl2Iusy7OT87SmfZi8zyoVA1ak4mtisd5aNu1asUWQikf3Pxp9QOZuOTTZhJjqyJ3 XFFTGTtC2JGmFRebtxePNy63zomAfFROkKxmRlX+BB932AAOdmyY5/xcqs+1fD5qwcxjrfIX a3PzZ/A+zWmYfr6heZwWlA/aQ3mIbPxg6OFyTECfSwYvEAABEAABEFhL4M+axt1AXFvfUdq+ 5m9p4/ioSF1jDPJB3v+4hvnJtSAfxqLjchvcPZO7BF+Ox1s5lPwi4bGkLJVStVxWL0boUpi6 wtdkS9eMMwVaWV29fpp3tfee8ZRHHc3+ZurQnSH5eQeHql+XnWxRFV1TbxDTaww4rctI2gNu SVBKrJVU1etjte8rNbimSdLZZ/eZmt/a9bzVrzOzCFaBwPsIjJxyDk55qYmMehii9ZDE8Pn6 yR4wcCQT6bdyaPlFwZUxHX5epJQnv0pZfu3zSVZboD941IazJfBLJX8mwe6SsQng+iXjwonB 2x5s/HO5TfYPY+GjSt0QlK6P1b6klMut80torYpbLSpouqqf4g5L9lb2otyvk0nckiyRms+k t3IIehYbL+pxVIdSahWyuJsnNg3cK3Er7eaP30Laj7W6XssMZIHAqVLGXiOc98t1thUsOR7b bDmQ23z/MBCvt440g7tn8uaEXJH8MMmPAs3p1V2LrNIzEOlSkbdyaPlVhcNxpILJveZ8ngQz oSV5WPI3Fu7m/MK6dquSsw0V4uVVv4lbFw6PbbJTlTO55PVuRdcLDI40LUNVD9XNEganpg9V PdeD63YryoWuPE1738qB+qPLwvT0/LkM1ExFlKv8mVGFsnLB5zaW1oi+e6RfFZrBs2fJ6ld1 Lqv0JM1OiuWtykvGVa/SM19LxhIpQ/1Rq1RGWzIortgS/UuUzHhxTtkSipLwOT7eZUlr5K5e v8v+Vr0jJwJo6i01ytW0vd4SlsO4Wv24Rbp6qnDVAqJa/MUcAtT0FQ8b7vgR50OLW7dSDhDp t13Y8jykGtllmbED+S9ZdZf7A9m4qohtF5n2Tt5Jv57Obb5/KEWEIas8qV4vVbpD2OU2ONLs sO96nRdn0vUOJmsEBx5RTh4AktGcF0M+IB9mssjNn85vbs7Uh7IgAAIgAAIg8O+NAUzikAcg AAIgAAJbCeANm1vxPkM57tnybskzArbZSuQD8mEmxdz8wX2af99b/vhnfl9++WGNWyLi38kU b0YYs8reGB/Tw6Xm4xUbkD8RMOnI4cX3cc6ceCI4wYmb7kkBiTc+ubM2EP59mrV1QNsHCVBi yc+bJsXV7eXgRNyq3HBN2sf83fFdFZS8nhZPCqtsRzzYqOty7sKlSEb+qw5GW/37csbSWPzk Zh43JF9MoNo7vxjFK11DfNeGtcVzFedVema8xtmzGXoo2yHwmzTJD0nzFf67dZ3nXCU9a6NC M1A5+yNjpM1cI12XAtIYe73ql0SnNNt6Leflc9iS/YE9JT1r43umtlWRWqVnntLgGzbnKz5B A3UiJ1hyrw3zHFRC85OVCq+sSO4A8HUlMKxnjKfLgUca9Uwi/1eVain5maTcsZJdPjy82bwN jA9KuaBcw6TkcFzujW81K+bbRatGt73QXIGLqHyz/GVYbRJW9VThBPIuN+yeLST8XVWt+zTu XNW2ge54v0pPNULcZtwbqiVtXR+tNi4yULZkW1f4rfHtOr5JoMWTpiNuuPl6MhlW6VlFYOS9 Z6vqhp7XE1AtqttIuENX06KqnoVg5Z7PQrXXqGrxXFV7NS4HxncVirV6ui0lWd0qPcnqAjGs aeYZfl1Dfi84LxkzXaUnEznuTF3hwJIrjZS2La83rzAveU58MzmwViZPyUratTVdiUeUjJ61 PlpteJ4G92n0TxUM5Fxm35l2Bn7/toS53vx9Amnq/PSttdktmzfXQl7wV7J2/orMY3+tHhdF wCdGp+oNeHY7egXzHfGtJna3B68qlBGxqeuOQK2cUflm00/ZltEz7I4q6HLDiQCMNAtGmlU5 eq+efT3Ls/x6K4dqFMChSoynVnbah92zMZgoBQIPIEA3meZXew9wFSaeTQBZeHZ8YB0IgAAI PJ/An/s0z3cHHoAACIAACBxHALtnx4UEBoEACIDAywhgpHlZQOEOCIAACBxH4M97z/IHvY/z Y8igr/nbggQORAYcwEG2EeTDULfqtyOsacZgohQIgAAIgECWAEaaLCnIgQAIgAAILCbQOoOP 6wQaHMBBNjnkA/IB+WAHIX6ZE95Gg3cE4B0B/2kgeMiR79PgYU+6bwcOAysYlxt2zwZIoggI gAAIgECBAH5zswALoiAAAiAAAgMEsDwcgIYiIAACIAACBQLYPSvAgigIgAAIgMAAAbz3bAAa ioAACIAACBQI/FnTfO2Z2K/528oLcCAy4AAOso0gHwojiRB1ufVPObd+yK9qRKDnrtOE/m/D /f9vKVYdVPIH+huMNPY054vjXuJghSUZblQ3HoddFSn2FO2CR9xMu7Adq/vbsj+d3d+cVapa v6QZ/MBra8KUr9r+qqzUmclz/5Rzt2RXINkjB3pWVZG0JBZbZcxT/G3RAIcMGaKUYbVvgpyp fb5prKrlfe2Cc+C/TymK2Spf/P3BcwJZRIaGhCmj1HBi9VBBl2dLT0a/O3nK53kr03AiYL4N QsMXCewbOb5IEz63CdglQjzq229jeaWfR0Re2C0Jzp9Tzq1VM9XN5lZXi8GqvLX50FpFyuvz k6yv+VvaNSI4r4x7iYMrrDbQWk3DvW4vyrZN37r5LxuL2jHjMC3ZSUO7iHfPVLugeNklSHDd fiXTrKWtlYrWnsD+2CpVsJXn8djj754NTM3k+o6WY9Kg1irPNU4tEqWfrp6S8iVDMa9PbdUt DkG9j/C3Zf/X4h7nj5r6cQNu5S0lkuyPmKfMsUAPF6eWbA0gg2UVq5pAq/GyU1/oB7rd6y8u 9FGjjnt9a2gWKm+lWbWKzu4ZU1tVX9U+1Xg4ZnKAlBf577GKvuZvixI4ZPLHHWzcFO12Upnq WIY7MjWouHPJkmbkQzdSPD+w606eZEglcuaxJBZSyTXtdEnn379PM9l3L4TLUzk7N5ThdNcN eTO+5m/QuRCKPLpNktfEfYnxC/Owas/uSKFdUETO4XCmPa287b/3zB2oq81gUn53K3LnIJM2 zxS/0t+WnV+L+1i84q0qN47yIs0W+d8xG6hUsJ82o5bLIh8k57VblHF7d5fOC+Oi9Lsr43l/ oxMB7L80haq0K0ceYFWvve/6fPtUTF/vb7B8UTvL3Kgkk9fEPckhEGM+xITptdqFbAXullcr FVVFQeNSNsx0DWgXHK9Mu1BTB45R5rocMIL2pb5SnbDtn6W864LMK9VF22Tm6pJJ5Y5V/bNn bntzdalWt2QmtVVJywtb6Tv8nexhg/jmSW4N6KTyd3gxCaHUitEu5mm/T4ObFf8c2KihIrZg 6/rTUX7N33gu/524Pz1vd9uPdrGb8Jv04w2bb4omfAEBEACBEwngDZsnRuVimwbWtRdbeE11 4KC27K/BfmwtyIex0Ljc+mfPgsq+Fomv+Rtvo41l4WtK/ZJhST4EepbovwD4U+xciMLdQ17C YYmShZ6uUpV6nqZVWfIowipbr9ETRPqV/g4MJ5/isDv5A5hHcUa74Exw73ivCpY903xNv7e7 lv5Is9sC6AcBEAABEHg3gc7v08iJTOtouQSkJj7y3DeP1asG//nA2LnJu/0Nli/2IQ8Wfl/c 8xzirWP1RJed9bsPn/10uo/UuO0oiIvU08rbsTaCdkHc3LWLe5GF5bfD+dCqeiya15fyual8 tcNAi6zF4SaoGmyOgljKpBf4W+phXxz3EodYWFFq/TcppuqKS1W7wnyPg3axZKQJeoyxyOYj eK+kmz/X7Z6ds5S5Jgxf87dF9ZUcuC3du6suH+f+mUQfDgRfkX9ck/xBLciH20NwiwFTZ89u sRiVgsAJBGzPfpdVNOzxh82QF+23d1n71nrPyYczCRfWNHbb8UyXVln1NX+DbaJVSN+k54S+ +5YUvaXS8zPnhHw4mVLqvWeUW+6dYfJNruKlt+qOqNxqOGER3boV8VZ/g7HEDQc4uMS4q7X5 rHrhuF38lO+QV+cUBnoftAuCFnBoHZORuTEQ37jegVDeUsS/z6fGiRMGgMvotDLpMgMOqQgc VrXwZN90SNyrM4/DzV5u3nw0xzQ8vT269hd2z5YHEgpB4E0EaD5rN5da19/k+6d8SR4DGcuH pw8zzemLXNN8Kl3gLAiAAAiAwDUE/pw9+9q9vq/5G+yWXJNth9eCfOBdxMMjdY15yIcxzi43 7J79gfljJD9joF9QChxmgogeaoYeyr6SAEaa/4aVdkjl55tdBjhkmnqQG586VpNhBRkQGPnN ze9QQ5dBsQaH7+Q8PAWBHQQ6b9jcUeU5OtUxj+DUh5rAtp4T6j4/VNJzGShw4PsTyTFVxrH1 aIUMXxB3PsiUrPqCrHjr8acqOnCoEgvaEUaaf2V6BNULyBSkToTHGPXH7ysWtonb1TMW6Wop 1zCpxDplU+qVHAKS8bxEDT+t/HGhVcO3XB49bHXmsTwEj1bo5g/ee/Ynpq37NPEdcu5HutPS VXp2JyI47CbM+rs5c5klqAgE9hHAiYAUW9XzdnsH3hJRw3tVT8q4C4Wq9r+Vw4XIURUIvIEA Rpr/RjF/0iwvGefIKj1rMzFvVV7yiRySVFdBSFYHMRB4IgHcp+nfp/nFNb6TT4G3C538/Q+Z Ot0F0/I8S9r5QQ6ZAdI9EaBSInkSxM2i5eHuKsR9GkIEDt1UcQVcbhhp/ow0Y2SfXgotCj2L zGHkA/Jhpk/zTwTMaERZEAABEAABEOgS+PP7NF1pCIAACIAACIBAlQBOBFSJQR4EQAAEQKBG ACNNjRekQQAEQAAEqgT0zzZXy0MeBEAABEAABGICf9Y0eDIA6QICIAACIDBDwB1HsHs2gxRl QQAEQAAE+gTw3rM+I0iAAAiAAAhMEWg9kY7rhBUcwEE2MOQD8gH5YIecoF3QyxL/PE+DZ4On Bm0UBgEQAIHPE/DfEYBTAJ9PDAAAARAAgb0EcCJgL19oBwEQAAEQwPM0yAEQAAEQAIG9BP4X YjIQ15AjxbMAAAAASUVORK5CYII= --------------0217E3C73D700DF95185ABAD-- --------------FA540C7A4C4309CBFCF5E1E0-- --------------A556DCA9E7EC0E57B422A2BC Content-Type: application/octet-stream; name="Figure 8 terminology.EFX" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Figure 8 terminology.EFX" Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsgICAgICANCnxGdW5jdGlvbi98ICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICBXaS1TVU4gIHwgICAgICAgICAgICB8ICAgICAgDQp8VGVjaC4gICAg fCAgTE9SQVdBTiB8ICBOQi1JT1QgIHwgIFNJR0ZPWCAgfCAgICBGQU4gICB8ICAgIElFVEYg ICAgfCAgICAgIA0KKy0tLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0t LSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsgICAgICANCnxTZW5zb3IsICB8ICAgICAgICAg IHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgICB8ICAgICAg DQp8QWN0dWF0b3IsfCAgIEVuZCAgICB8ICAgVXNlciAgIHwgICBFbmQgICAgfCAgTGVhZiAg ICB8ICAgRGV2aWNlICAgfCAgICAgIA0KfERldmljZSwgIHwgIERldmljZSAgfCBFcXVpcG1l bnR8ICBQb2ludCAgIHwgIE5vZGUgICAgfCAgIChEZXYpICAgIHwgICAgICANCnxPYmplY3Qg ICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgICB8ICAgICAgDQorLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0tLS0t LS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKyAgICAgIA0KfFRyYW5zY2VpLXwgICAgICAg ICAgfCBFdm9sdmVkICB8ICBCYXNlICAgIHwgIFJvdXRlciAgfCAgIFJBRElPICAgIHwgICAg ICANCnx2ZXIgICAgICB8IEdhdGV3YXkgIHwgTm9kZSBCICAgfCBTdGF0aW9uICB8ICBOb2Rl ICAgIHxHQVRFV0FZKFJHVyl8ICAgICAgDQorLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0t LS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKyAgICAgIA0KfCBTZXJ2 ZXIgIHwgIE5ldHdvcmsgfCBQRE4gR1cvICB8IFNlcnZpY2UgIHwgIEJvcmRlciAgfE5ldHdv cmsgICAgIHwgICAgICANCnwgICAgICAgICB8ICBTZXJ2ZXIgIHwgIFNDRUYgICAgfCBDZW50 ZXIgICB8ICBSb3V0ZXIgIHxHYXRld2F5KE5HVyl8ICAgICAgDQorLS0tLS0tLS0tKy0tLS0t LS0tLS0rLS0tLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKyAg ICAgIA0KfFNlY3VyaXR5IHwgICBKb2luICAgfCAgIEhvbWUgICB8UmVnaXN0cmEtIHxBdXRo ZW50aS0gfCAgIExQV0FOLSAgIHwgICAgICANCnwgU2VydmVyICB8ICBTZXJ2ZXIgIHxTdWJz Y3JpYmVyfHRpb24gICAgICB8Y2F0aW9uICAgIHwgICAgQUFBICAgICB8ICAgICAgDQp8ICAg ICAgICAgfCAgICAgICAgICB8ICBTZXJ2ZXIgIHxBdXRob3JpdHkgfFNlcnZlciAgICB8ICAg U0VSVkVSICAgfCAgICAgIA0KKy0tLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0rLS0t LS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsgICAgICANCnxBcHBsaWNhLSB8QXBw bGljYS0gIHxBcHBsaWNhLSAgfCBOZXR3b3JrICB8QXBwbGljYS0gIHxBUFBMSUNBVElPTiB8 ICAgICAgDQp8dGlvbiAgICAgfHRpb24gICAgICB8dGlvbiAgICAgIHwgQXBwbGljYS0gfHRp b24gICAgICB8KEFwcCkgICAgICAgfCAgICAgIA0KfCAgICAgICAgIHxTZXJ2ZXIgICAgfFNl cnZlciAgICB8IHRpb24gICAgIHwgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICANCist LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K --------------A556DCA9E7EC0E57B422A2BC-- From nobody Wed Jul 19 01:01: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 0E696131BFE for ; Wed, 19 Jul 2017 01:01:58 -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 xQVD5B9hmwoO for ; Wed, 19 Jul 2017 01:01:51 -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 226EB131C1D for ; Wed, 19 Jul 2017 01:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5506; q=dns/txt; s=iport; t=1500451310; x=1501660910; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mq811j3Sp3pYVma6kmCFT1qekEgtgFJY3BP0DGyzHMY=; b=bYIRmtX5wqFI9XTz4ZepSDID4yTwz5TjzbNxIEV5CsToqhn9yn2aQz2F anpnD5jA0kKaWVYgbb3IeVjkooXsNElT5/7awQnUO1EONu1GgB0dXQBSt rXGaSuHVYbcXdKPhHHNcjsvs3qzgCzODvV2hcuUYbKj+kcLg5JUjnz+Nn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACdEW9Z/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZIEBEweOBJFhlgSCESELhRsCGoM+PxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMBASEROgsMBAIBCBEBAwEBAwIREgMCAgIlCxQBAgYIAgQOBQgRihYQr?= =?us-ascii?q?n+CJosHAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELgh2DTYFhgySDJoENHTEoglS?= =?us-ascii?q?CYQWfOQKHSYxFghVXhHiKVJVbAR84gQp1FR8qhxZ2h0aBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,380,1496102400"; d="scan'208";a="271764065" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2017 08:01:47 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6J81lBq021662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Jul 2017 08:01:47 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Jul 2017 03: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, 19 Jul 2017 03:01:46 -0500 From: "Pascal Thubert (pthubert)" To: "Patrick Wetterwald (pwetterw)" CC: "lp-wan@ietf.org" Thread-Topic: [lp-wan] I-D Action: draft-ietf-lpwan-overview-05.txt Thread-Index: AQHS/8sSxrpG3fjyxEupD15MmC7V96Jayidg Date: Wed, 19 Jul 2017 08:01:40 +0000 Deferred-Delivery: Wed, 19 Jul 2017 08:01:35 +0000 Message-ID: <665c265cd7e94dabb947c47707e6bcd0@XCH-RCD-001.cisco.com> References: <149893334336.489.9442381469735966027@ietfa.amsl.com> <33B0795E-6CA0-4BB2-9469-61B5D60DED38@cisco.com> In-Reply-To: <33B0795E-6CA0-4BB2-9469-61B5D60DED38@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.61.216.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-05.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: Wed, 19 Jul 2017 08:01:58 -0000 SGVsbG8gUGF0cmljazoNCg0KVGhlcmUgaXMgYSBtYXRjaCB0byBiZSBmb3VuZCBiZXR3ZWVuIHdo YXQgV2ktU3VuIGRvZXMgYW5kIHdoYXQgTFBXQU4gaXMgY2hhcnRlcmVkIHRvIGNvdmVyLg0KDQox KSBJdCBpcyBnb29kIHRvIG1lbnRpb24gYXMgYW4gb3ZlcnZpZXcgdGhhdCBXaS1TdW4gRkFOIGNh biBkbyBtZXNoLCBoYXMgcm91dGluZyBhbmQgNkxvV1BBTi4gSXQgd291bGQgYmUgZ29vZCB0byB2 ZXJ5IGJyaWVmbHkgcG9zaXRpb24gdGhlIHByb2ZpbGVzIGFuZCB3aGljaCBvZiB0aG9zZSBxdWFs aWZ5IGFzIExQV0FOLg0KDQpPVE9ILCBMUFdBTiBpcyBleHBsaWNpdGx5IGNoYXJ0ZXJlZCBvdXRz aWRlIG9mIHJvdXRpbmcgYW5kIDZMb1dQQU4sIHNvIHRoZXJlIHNob3VsZCBub3QgYmUgdG9vIG11 Y2ggZW1waGFzaXMgb24gdGhpcyBzaW5jZSB0aGlzIGlzIG5vdCB3aGF0IHRoZSBMUFdBTiByZWFk ZXIgaXMgYWZ0ZXIuIFdoYXQgdGhlIExQV0FOIHJlYWRlciBpcyBhZnRlciBpcyB0aGUgZWRnZSBi ZXR3ZWVuIHRoZSBsb3cgcG93ZXIgZW5kIG9iamVjdHMgYW5kIHRoZSBmaXJzdCByb3V0ZXIsIHdo aWNoIGFwcGVhcnMgbGlrZSBhIExQV0FOIHN0YXIuIFRoaXMgaXMgd2hlcmUgYW4gaW50ZXJzZWN0 aW9uIHdpdGggTFBXQU4gdGVjaG5vbG9neSBpcyBob3BlZnVsbHkgdG8gYmUgZm91bmQuIEFuZCB0 aGVuIHdlIGNhbiB1c2UgdGhlIG5lZWRzIGV4cHJlc3NlZCBpbiB0aGUgb3ZlcnZpZXcgdG8gZGVy aXZlIHRoZSBuZXh0IGNoYXJ0ZXIgaXRlbXMuIA0KDQoyKSBpcyB2ZXJ5IGNsb3NlIHRvIDEpLiBB ZnRlciBhIGJyaWVmIGRlc2NyaXB0aW9uIG9mIHRoZSBtZXNoIHdoZXJlIHJvdXRpbmcgaGFwcGVu cywgZm9jdXMgc2hvdWxkIG1vdmUgdG8gYWNjZXNzIHdoZXJlIExQV0FOIG9wZXJhdGVzIGJ5IGNo YXJ0ZXIuDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBscC13YW4gW21haWx0bzpscC13YW4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFBhdHJpY2sgV2V0dGVyd2FsZCAocHdldHRlcncpDQpTZW50OiBtYXJkaSAxOCBqdWls bGV0IDIwMTcgMTU6MzgNClRvOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc7IGktZC1hbm5vdW5j ZUBpZXRmLm9yZw0KQ2M6IGxwLXdhbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtscC13YW5dIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtbHB3YW4tb3ZlcnZpZXctMDUudHh0DQoNCkhpIFN0ZXBoZW4s DQoNCkkgaGF2ZSAyIGNvbW1lbnRzIHJlZ2FyZGluZyB0aGUgZHJhZnQuDQoNCkZpcnN0IG9uZTog UGFyYWdyYXBoIDMuIOKAnEdlbmVyaWMgdGVybWlub2xvZ3nigJ0uIFRoaXMgcGFyYWdyYXBoIHNo b3VsZCB0YWtlIGludG8gYWNjb3VudCB0aGUgV0ktU1VOIGFyY2hpdGVjdHVyZSAoYXMgb25lIG9m IHRoZSB0ZWNobm9sb2d5IGluIHRoZSBzY29wZSkuIFdJLVNVTiBhcmNoaXRlY3R1cmUgaW50cm9k dWNlcyB0aGUgbm90aW9uIG9mIGJvcmRlciByb3V0ZXIsIHJvdXRlcnMgYW5kIGxlYWYgbm9kZXMu IFdJLVNVTiBpcyBub3QgdGFsa2luZyBhYm91dCBnYXRld2F5cywgcmFkaW8gZ2F0ZXdheXMgZXRj LiBPbmUgd2F5IHRvIHNvbHZlIHRoaXMgaXMgdG8gYWRkIGFub3RoZXIgZGlhZ3JhbSB3aXRoIHRo ZSBXSS1TVU4gYXBwcm9hY2guDQoNClNlY29uZDogUGFyYWdyYXBoIDQuNiBzYXlzIHRoYXQgbm8g cm91dGluZyBwcm90b2NvbCBpcyBuZWVkZWQuIFRoaXMgaXMgbm90IGNvcnJlY3QuIFdJLVNVTiBp cyB1c2luZyBSUEwgYXMgcm91dGluZyBwcm90b2NvbCBhbmQgaXMgYmFzZWQgb24gYSBtZXNoIHRv cG9sb2d5LiBUaGlzIHNob3VsZCBiZSByZWZsZWN0ZWQgaW4gdGhpcyBwYXJhZ3JhcGggbm90IGFz IGEgZ2FwIGJ1dCBhcyBleGlzdGluZyB0ZWNobm9sb2d5Lg0KDQpNYW55IHRoYW5rcywNCg0KUGF0 cmljaw0KDQpPbiAwMS8wNy8yMDE3LCAyMDoyMiwgImxwLXdhbiBvbiBiZWhhbGYgb2YgaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIiA8bHAtd2FuLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICANCiAgICBBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBv dmVyIExvdyBQb3dlciBXaWRlLUFyZWEgTmV0d29ya3Mgb2YgdGhlIElFVEYuDQogICAgDQogICAg ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBMUFdBTiBPdmVydmlldw0KICAgICAgICAgICAgQXV0 aG9yICAgICAgICAgIDogU3RlcGhlbiBGYXJyZWxsDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtbHB3YW4tb3ZlcnZpZXctMDUudHh0DQogICAgCVBhZ2VzICAgICAgICAgICA6IDQx DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMTctMDctMDENCiAgICANCiAgICBBYnN0cmFjdDoN CiAgICAgICBMb3cgUG93ZXIgV2lkZSBBcmVhIE5ldHdvcmtzIChMUFdBTikgYXJlIHdpcmVsZXNz IHRlY2hub2xvZ2llcyB3aXRoDQogICAgICAgY2hhcmFjdGVyaXN0aWNzIHN1Y2ggYXMgbGFyZ2Ug Y292ZXJhZ2UgYXJlYXMsIGxvdyBiYW5kd2lkdGgsIHBvc3NpYmx5DQogICAgICAgdmVyeSBzbWFs bCBwYWNrZXQgYW5kIGFwcGxpY2F0aW9uIGxheWVyIGRhdGEgc2l6ZXMgYW5kIGxvbmcgYmF0dGVy eQ0KICAgICAgIGxpZmUgb3BlcmF0aW9uLiAgVGhpcyBtZW1vIGlzIGFuIGluZm9ybWF0aW9uYWwg b3ZlcnZpZXcgb2YgdGhlIHNldCBvZg0KICAgICAgIExQV0FOIHRlY2hub2xvZ2llcyBiZWluZyBj b25zaWRlcmVkIGluIHRoZSBJRVRGIGFuZCBvZiB0aGUgZ2FwcyB0aGF0DQogICAgICAgZXhpc3Qg YmV0d2VlbiB0aGUgbmVlZHMgb2YgdGhvc2UgdGVjaG5vbG9naWVzIGFuZCB0aGUgZ29hbCBvZiBy dW5uaW5nDQogICAgICAgSVAgaW4gTFBXQU5zLg0KICAgIA0KICAgIA0KICAgIFRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbHB3YW4tb3ZlcnZpZXcvDQogICAgDQog ICAgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxwd2FuLW92ZXJ2aWV3LTA1DQog ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWxwd2Fu LW92ZXJ2aWV3LTA1DQogICAgDQogICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLWxwd2FuLW92ZXJ2aWV3LTA1DQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICBscC13YW4gbWFpbGluZyBsaXN0DQogICAgbHAtd2Fu QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13 YW4NCiAgICANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCmxwLXdhbiBtYWlsaW5nIGxpc3QNCmxwLXdhbkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scC13YW4NCg== From nobody Wed Jul 19 04:20: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 DEA81131CA0 for ; Wed, 19 Jul 2017 04:20:06 -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 W8GIGlqro-SZ for ; Wed, 19 Jul 2017 04:20:03 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EF9131CB4 for ; Wed, 19 Jul 2017 04:20:03 -0700 (PDT) Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id C0E1D1720F7; Wed, 19 Jul 2017 13:20:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter18-d.gandi.net (mfilter18-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id mBlCec4cXm7j; Wed, 19 Jul 2017 13:20:00 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.158] (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 5A5801720ED; Wed, 19 Jul 2017 13:19:59 +0200 (CEST) To: Carles Gomez Montenegro Cc: lp-wan , BARTHEL Dominique IMT/OLPS From: Arun Message-ID: Date: Wed, 19 Jul 2017 13:19:49 +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="ejVSNIovXCng9VsClHVubUR8H91E12Sv4" Archived-At: Subject: [lp-wan] need for MAX_ACK_REQUESTS? 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, 19 Jul 2017 11:20:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ejVSNIovXCng9VsClHVubUR8H91E12Sv4 Content-Type: multipart/mixed; boundary="m26GtQVohf9rc8QQxBaLHvOEd2CcfiKdB"; protected-headers="v1" From: Arun To: Carles Gomez Montenegro Cc: lp-wan , BARTHEL Dominique IMT/OLPS Message-ID: Subject: need for MAX_ACK_REQUESTS? --m26GtQVohf9rc8QQxBaLHvOEd2CcfiKdB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Carles, all, Do we still need this variable MAX_ACK_REQUESTS ? MAX_FRAG_RETRIES is going to be the same (during retransmission we only send the last fragment of the received bitmap which would be considered as ACK REQUEST). correct? if this is already discussed in the thread of Dominique's review please point me to the same. thanks, --=20 Arunprabhu Kandasamy arun at ackl.io 2 bis rue de la Ch=C3=A2taigneraie 35510 Cesson-S=C3=A9vign=C3=A9=20 France=20 Phone: +33 (0)2.99.12.24.14 --m26GtQVohf9rc8QQxBaLHvOEd2CcfiKdB-- --ejVSNIovXCng9VsClHVubUR8H91E12Sv4 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 iQIcBAEBCAAGBQJZb0BVAAoJENe8HNMjzJQRJcYP/jusfbGTRSFynEV3DL/uayEW jhUBeCdihK8p/iizBLobwJ9JyaHxtxtjiVZfdPyocYI2JdXUJb4yPIjlW9z3CQFG RsbdOUQFwoSArRseChAZmJDoQWlj3cpoO5QXndsMbL2+MTFDpbefvNO1GcxSOlYf NWIrbfIk/rCF1i8msZE2Iy4X5oMYMu+mM8UMKH/zMkjYNYivpdlhmXnpkroJNAFA yTvHUx/7gK02kyY0SZb9co66kP/GoaIDzIPs1wLK7tCbNRa/f58iTJNLioxZkq6T YKVXRTtOuGp/p6kmG9VQEXUMqDlFaw7WHBTmlFVc6A1JyTi4BuQr9tlNN3UECH8V 08WLI+t2eWKyl2HB6NBkM3sGIIb39YIrGTW2vvFhV0+vr2xy9/LlTdfEGk9w4imC F8pplUSwyhIfMY6UscQJbQZ0hOKYv0VqEQeTb5IyJ9NEGydZJIXRZE3GV4Cdojbu q0IDdByUT6MXMy8iZk+kO7NL+FzARS1iJbMp2MvROAXsqZ5Amoa5bwcc5PCBKa72 tiJwxIZ+hGoxgK0fokwt8g431oFFzPGu+vnbkS9KOgEnuC4GVUYxMUfBaK4tCR8s 0JsoqxjJbbZ2ByUFp0W2+vkvmzHE2wSlyQJPuahcBNtokCdPZSZ33bW12oXQhPbs ZEytAAnM+M8kVNsjjRvz =qkSA -----END PGP SIGNATURE----- --ejVSNIovXCng9VsClHVubUR8H91E12Sv4-- From nobody Wed Jul 19 04:42:10 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 5DC6E131CC7 for ; Wed, 19 Jul 2017 04:42:08 -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 lQmwLBo9DTOt for ; Wed, 19 Jul 2017 04:42:06 -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 439EE13178B for ; Wed, 19 Jul 2017 04:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6192; q=dns/txt; s=iport; t=1500464526; x=1501674126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zTgceiGc8NVsYN9QOdySjSI3R3uhYjBubcd1j9lH7NU=; b=jey5ScMrRTbEgZ4znf+w/5zrvt06UVQyWA6Jox9RM/5z5tdL0g/E6J/K q2jZHw4YYZboZNU88HmPZuTBKgBPp1OgFXqZ9Er/sc4IGXd7soWNkb3aW dYc7L1LuQZ5oZhCU0OLcfpTKh16XCuhNk/nV+pBJUR+ikkZn/jT8maC21 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAABbRW9Z/5ldJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZIEBEweOBJE+IpYEghEhC4UbAhqDRD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDAQEhEToLDAQCAQgRAQMBAQMCERIDAgICJQsUAQIGCAIEDgUZihYQr?= =?us-ascii?q?yWCJosGAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELgh2DTYFhKwuCboMmgQ0dMSi?= =?us-ascii?q?CVDCCMQWXRId1AodJjE6CDFeEeIpUlVsBHziBCnUVHyoSAYcDdodGgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,380,1496102400"; d="scan'208";a="271838388" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2017 11:41:56 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6JBfuqD032614 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Jul 2017 11:41:56 GMT Received: from xch-rtp-014.cisco.com (64.101.220.154) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Jul 2017 07:41:55 -0400 Received: from xch-rtp-014.cisco.com ([64.101.220.154]) by XCH-RTP-014.cisco.com ([64.101.220.154]) with mapi id 15.00.1210.000; Wed, 19 Jul 2017 07:41:55 -0400 From: "Patrick Wetterwald (pwetterw)" To: "Pascal Thubert (pthubert)" CC: "lp-wan@ietf.org" Thread-Topic: [lp-wan] I-D Action: draft-ietf-lpwan-overview-05.txt Thread-Index: AQHTAIQFxrpG3fjyxEupD15MmC7V9w== Date: Wed, 19 Jul 2017 11:41:55 +0000 Message-ID: <4DA564CA-BF27-4364-96EF-1AFA685D93F5@cisco.com> References: <149893334336.489.9442381469735966027@ietfa.amsl.com> <33B0795E-6CA0-4BB2-9469-61B5D60DED38@cisco.com> <665c265cd7e94dabb947c47707e6bcd0@XCH-RCD-001.cisco.com> In-Reply-To: <665c265cd7e94dabb947c47707e6bcd0@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-GB 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.61.215.129] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] I-D Action: draft-ietf-lpwan-overview-05.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: Wed, 19 Jul 2017 11:42:08 -0000 SGkgUGFzY2FsLg0KDQpTbyBiYXNpY2FsbHkgeW91IGFncmVlIHdpdGggbXkgY29tbWVudHPCoDo9 KQ0KDQpUaGFua3MsDQoNClBhdHJpY2sNCg0KDQpPbiAxOS8wNy8yMDE3LCAxMDowMSwgIlBhc2Nh bCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5jb20+IHdyb3RlOg0KDQogICAg SGVsbG8gUGF0cmljazoNCiAgICANCiAgICBUaGVyZSBpcyBhIG1hdGNoIHRvIGJlIGZvdW5kIGJl dHdlZW4gd2hhdCBXaS1TdW4gZG9lcyBhbmQgd2hhdCBMUFdBTiBpcyBjaGFydGVyZWQgdG8gY292 ZXIuDQogICAgDQogICAgMSkgSXQgaXMgZ29vZCB0byBtZW50aW9uIGFzIGFuIG92ZXJ2aWV3IHRo YXQgV2ktU3VuIEZBTiBjYW4gZG8gbWVzaCwgaGFzIHJvdXRpbmcgYW5kIDZMb1dQQU4uIEl0IHdv dWxkIGJlIGdvb2QgdG8gdmVyeSBicmllZmx5IHBvc2l0aW9uIHRoZSBwcm9maWxlcyBhbmQgd2hp Y2ggb2YgdGhvc2UgcXVhbGlmeSBhcyBMUFdBTi4NCiAgICANCiAgICBPVE9ILCBMUFdBTiBpcyBl eHBsaWNpdGx5IGNoYXJ0ZXJlZCBvdXRzaWRlIG9mIHJvdXRpbmcgYW5kIDZMb1dQQU4sIHNvIHRo ZXJlIHNob3VsZCBub3QgYmUgdG9vIG11Y2ggZW1waGFzaXMgb24gdGhpcyBzaW5jZSB0aGlzIGlz IG5vdCB3aGF0IHRoZSBMUFdBTiByZWFkZXIgaXMgYWZ0ZXIuIFdoYXQgdGhlIExQV0FOIHJlYWRl ciBpcyBhZnRlciBpcyB0aGUgZWRnZSBiZXR3ZWVuIHRoZSBsb3cgcG93ZXIgZW5kIG9iamVjdHMg YW5kIHRoZSBmaXJzdCByb3V0ZXIsIHdoaWNoIGFwcGVhcnMgbGlrZSBhIExQV0FOIHN0YXIuIFRo aXMgaXMgd2hlcmUgYW4gaW50ZXJzZWN0aW9uIHdpdGggTFBXQU4gdGVjaG5vbG9neSBpcyBob3Bl ZnVsbHkgdG8gYmUgZm91bmQuIEFuZCB0aGVuIHdlIGNhbiB1c2UgdGhlIG5lZWRzIGV4cHJlc3Nl ZCBpbiB0aGUgb3ZlcnZpZXcgdG8gZGVyaXZlIHRoZSBuZXh0IGNoYXJ0ZXIgaXRlbXMuIA0KICAg IA0KICAgIDIpIGlzIHZlcnkgY2xvc2UgdG8gMSkuIEFmdGVyIGEgYnJpZWYgZGVzY3JpcHRpb24g b2YgdGhlIG1lc2ggd2hlcmUgcm91dGluZyBoYXBwZW5zLCBmb2N1cyBzaG91bGQgbW92ZSB0byBh Y2Nlc3Mgd2hlcmUgTFBXQU4gb3BlcmF0ZXMgYnkgY2hhcnRlci4NCiAgICANCiAgICBUYWtlIGNh cmUsDQogICAgDQogICAgUGFzY2FsDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCiAgICBGcm9tOiBscC13YW4gW21haWx0bzpscC13YW4tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFBhdHJpY2sgV2V0dGVyd2FsZCAocHdldHRlcncpDQogICAgU2VudDogbWFyZGkg MTgganVpbGxldCAyMDE3IDE1OjM4DQogICAgVG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzsg aS1kLWFubm91bmNlQGlldGYub3JnDQogICAgQ2M6IGxwLXdhbkBpZXRmLm9yZw0KICAgIFN1Ympl Y3Q6IFJlOiBbbHAtd2FuXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWxwd2FuLW92ZXJ2aWV3LTA1 LnR4dA0KICAgIA0KICAgIEhpIFN0ZXBoZW4sDQogICAgDQogICAgSSBoYXZlIDIgY29tbWVudHMg cmVnYXJkaW5nIHRoZSBkcmFmdC4NCiAgICANCiAgICBGaXJzdCBvbmU6IFBhcmFncmFwaCAzLiDi gJxHZW5lcmljIHRlcm1pbm9sb2d54oCdLiBUaGlzIHBhcmFncmFwaCBzaG91bGQgdGFrZSBpbnRv IGFjY291bnQgdGhlIFdJLVNVTiBhcmNoaXRlY3R1cmUgKGFzIG9uZSBvZiB0aGUgdGVjaG5vbG9n eSBpbiB0aGUgc2NvcGUpLiBXSS1TVU4gYXJjaGl0ZWN0dXJlIGludHJvZHVjZXMgdGhlIG5vdGlv biBvZiBib3JkZXIgcm91dGVyLCByb3V0ZXJzIGFuZCBsZWFmIG5vZGVzLiBXSS1TVU4gaXMgbm90 IHRhbGtpbmcgYWJvdXQgZ2F0ZXdheXMsIHJhZGlvIGdhdGV3YXlzIGV0Yy4gT25lIHdheSB0byBz b2x2ZSB0aGlzIGlzIHRvIGFkZCBhbm90aGVyIGRpYWdyYW0gd2l0aCB0aGUgV0ktU1VOIGFwcHJv YWNoLg0KICAgIA0KICAgIFNlY29uZDogUGFyYWdyYXBoIDQuNiBzYXlzIHRoYXQgbm8gcm91dGlu ZyBwcm90b2NvbCBpcyBuZWVkZWQuIFRoaXMgaXMgbm90IGNvcnJlY3QuIFdJLVNVTiBpcyB1c2lu ZyBSUEwgYXMgcm91dGluZyBwcm90b2NvbCBhbmQgaXMgYmFzZWQgb24gYSBtZXNoIHRvcG9sb2d5 LiBUaGlzIHNob3VsZCBiZSByZWZsZWN0ZWQgaW4gdGhpcyBwYXJhZ3JhcGggbm90IGFzIGEgZ2Fw IGJ1dCBhcyBleGlzdGluZyB0ZWNobm9sb2d5Lg0KICAgIA0KICAgIE1hbnkgdGhhbmtzLA0KICAg IA0KICAgIFBhdHJpY2sNCiAgICANCiAgICBPbiAwMS8wNy8yMDE3LCAyMDoyMiwgImxwLXdhbiBv biBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8bHAtd2FuLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQogICAg DQogICAgICAgIA0KICAgICAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgICAgIFRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgb3ZlciBMb3cgUG93ZXIgV2lkZS1BcmVh IE5ldHdvcmtzIG9mIHRoZSBJRVRGLg0KICAgICAgICANCiAgICAgICAgICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBMUFdBTiBPdmVydmlldw0KICAgICAgICAgICAgICAgIEF1dGhvciAgICAgICAg ICA6IFN0ZXBoZW4gRmFycmVsbA0KICAgICAgICAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1scHdhbi1vdmVydmlldy0wNS50eHQNCiAgICAgICAgCVBhZ2VzICAgICAgICAgICA6IDQxDQog ICAgICAgIAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA3LTAxDQogICAgICAgIA0KICAgICAgICBB YnN0cmFjdDoNCiAgICAgICAgICAgTG93IFBvd2VyIFdpZGUgQXJlYSBOZXR3b3JrcyAoTFBXQU4p IGFyZSB3aXJlbGVzcyB0ZWNobm9sb2dpZXMgd2l0aA0KICAgICAgICAgICBjaGFyYWN0ZXJpc3Rp Y3Mgc3VjaCBhcyBsYXJnZSBjb3ZlcmFnZSBhcmVhcywgbG93IGJhbmR3aWR0aCwgcG9zc2libHkN CiAgICAgICAgICAgdmVyeSBzbWFsbCBwYWNrZXQgYW5kIGFwcGxpY2F0aW9uIGxheWVyIGRhdGEg c2l6ZXMgYW5kIGxvbmcgYmF0dGVyeQ0KICAgICAgICAgICBsaWZlIG9wZXJhdGlvbi4gIFRoaXMg bWVtbyBpcyBhbiBpbmZvcm1hdGlvbmFsIG92ZXJ2aWV3IG9mIHRoZSBzZXQgb2YNCiAgICAgICAg ICAgTFBXQU4gdGVjaG5vbG9naWVzIGJlaW5nIGNvbnNpZGVyZWQgaW4gdGhlIElFVEYgYW5kIG9m IHRoZSBnYXBzIHRoYXQNCiAgICAgICAgICAgZXhpc3QgYmV0d2VlbiB0aGUgbmVlZHMgb2YgdGhv c2UgdGVjaG5vbG9naWVzIGFuZCB0aGUgZ29hbCBvZiBydW5uaW5nDQogICAgICAgICAgIElQIGlu IExQV0FOcy4NCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1scHdhbi1vdmVydmlldy8NCiAgICAgICAgDQog ICAgICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAg ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbHB3YW4tb3ZlcnZp ZXctMDUNCiAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLWxwd2FuLW92ZXJ2aWV3LTA1DQogICAgICAgIA0KICAgICAgICBBIGRpZmYgZnJvbSB0 aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWxwd2FuLW92ZXJ2aWV3LTA1DQogICAg ICAgIA0KICAgICAgICANCiAgICAgICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgICAgICB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KICAgICAgICANCiAgICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgICAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KICAgICAgICANCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgbHAtd2FuIG1haWxpbmcgbGlzdA0KICAg ICAgICBscC13YW5AaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9scC13YW4NCiAgICAgICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBscC13YW4gbWFpbGluZyBsaXN0DQog ICAgbHAtd2FuQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9scC13YW4NCiAgICANCg0K From nobody Wed Jul 19 04:49:39 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 31B55131CD5 for ; Wed, 19 Jul 2017 04:49:38 -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 ONjdd79842hp for ; Wed, 19 Jul 2017 04:49:32 -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 E4F69129AC4 for ; Wed, 19 Jul 2017 04:49:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2162DBE24; Wed, 19 Jul 2017 12:49:30 +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 PG4fFWmop0kG; Wed, 19 Jul 2017 12:49:28 +0100 (IST) Received: from [31.133.148.54] (dhcp-9436.meeting.ietf.org [31.133.148.54]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E4854BDF9; Wed, 19 Jul 2017 12:49:27 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500464968; bh=30pXKzoVNOvH3sN1y7GQOvb6TrI/vBmTNMliMIJh+h8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ajmavml14VaKprB4VueUHRP7hngECRTRFHNatEniwFXS1xjmm1SfzPmQ7XZ3LPDX/ XIFlnU1fhAwwp5hNL1cySsF8Gadc9PO8rVlfo5/rWEsKaJPSJNlHRgKkD6Wn9pHRZo 5lUpACwS0wijJFAyZyeCAfIxxhfIctFnj+HILkMA= To: Alper Yegin Cc: lp-wan@ietf.org References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie> <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <21ed1f55-f415-73b2-757f-447212333955@cs.tcd.ie> Date: Wed, 19 Jul 2017 12:49:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="499SXrOPNvFxQeNW56Ju0CGTfW5stSMTM" 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, 19 Jul 2017 11:49:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --499SXrOPNvFxQeNW56Ju0CGTfW5stSMTM Content-Type: multipart/mixed; boundary="EKbm25hRdrRWPx3vCTCCEqlxQbjenvbs4"; protected-headers="v1" From: Stephen Farrell To: Alper Yegin Cc: lp-wan@ietf.org Message-ID: <21ed1f55-f415-73b2-757f-447212333955@cs.tcd.ie> Subject: Re: [lp-wan] lpwan-overview comments References: <59F856E1230C43D5A7CE1018F7C2DCA8@WeiGengyuPC> <259da1ec-041f-875b-813b-3e20844e822d@cs.tcd.ie> <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> In-Reply-To: <715019FF-4331-43C0-82EA-829EA5176BF3@actility.com> --EKbm25hRdrRWPx3vCTCCEqlxQbjenvbs4 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Alper, Sorry for the slow response, but I'm doing edits on this now so... On 01/07/17 20:18, Alper Yegin wrote: > Hi Stephen, >=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. >>> >>> >>> >>> AppEUI is being renamed as JoinEUI in LoRaWAN 1.1, and in fact it ide= ntifies 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 tha= t uniquely identifies >>> >>> the entity able to process the JoinReq frame. >>> >>> >>> So, we better not treat it as application identifier, but as identifi= er 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 >> >> So I just don't understand how that can be correct, sorry;-) >> >> A join-request is processed by a NS (or, in 1.1 a JS). There are very >> few of those, maybe 1 per n/w. There are many more device-types, which= >> do mostly map 1:1 with AppEUIs. And the same device-types can be found= >> in many networks. >> >> So the suggested text just seems incorrect to me. >> >> I'd say we're better to just stick with 1.0.2 terms tbh. >> >=20 > If we want to strictly stick with the LW1.0.2 definition, than it=E2=80= =99d be: >=20 > AppEUI IEEE EUI64 application id that identifies the entity processesin= g Join-request >=20 > In practice, it identifies the JS. So my issue with saying that is that one JS will like be the JS for many AppEUIs so it's an N:1 mapping between AppEUI and JS identifiers (be those IP addresses or names), so saying that an AppEUI "identifies" a JS seems wrong to me still. Would it work for you if we say it like this: " AppEUI: IEEE EUI64 corresponding to the join server for an application " That also calls for a definition of the JS I guess, so I can also add: - Join Server: The Join Server (JS) is a server on the Internet side of an NS that processes join requests from end-devices. Cheers, S. Cheers, S. >=20 > Note that: > - NS and JS may be co-located or separated. This is true for both LW1.0= =2Ex and LW1.1 specs. > - The entity that processes the Join-request and generates Join-accept = is the JS. > - Single NS may be connected to multiple JSs. > - Spec is based on 1:1 relationship between the end-device and JS. (Obv= iously, implementations can extend that). > - If the NS knows the identify of the JS to process an incoming Join-re= quest based on the DevEUI, then AppEUI (which is later renamed to JoinEUI= in LW1.1) has no significance. Otherwise, the NS relies on the AppEUI (J= oinEUI) to identify the JS to process the request. >=20 > I just elaborated on these details, not to suggest including in the dra= ft, but to point out that the significance of the AppEUI is to =E2=80=9C = identify(ies) the entity able to process the JoinReq frame.=E2=80=9D as s= tated in the LW1.0.2 spec. As long as we capture that, it is OK if the dr= aft also refers to it as =E2=80=9Capplication id=E2=80=9D. (The reason na= me of the Join-request field morphed from AppEUI into JoniEUI in LW1.1 is= basically this.) >=20 > Regards, >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> Cheers, >> S. >> >>> >>> >>> >>> >>> Thanks Stephen. >>> >>> Alper >>> >>> >>> >>> _______________________________________________ >>> 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 >=20 --EKbm25hRdrRWPx3vCTCCEqlxQbjenvbs4-- --499SXrOPNvFxQeNW56Ju0CGTfW5stSMTM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZb0dEAAoJEC88hzaAX42ig5IH/33w0Q/59THGHMvOVZ+P+HCk Ci+xHUpDudFRHC1BxxReyRnUmqnbYUZDr06mcHtuSBxXjO1bDEearfZo08geFDWQ cpUDjJbCTV6Rc7/+18U+RJjCwL/8+hagy534GIgqvOu++BzWKNBrzgCCPwf7DGxj 47pT76+QiAzrfkhqC1yMfiE7PovLkyoYL9tMM0Ub7ezLoHxWc5isOLzttzG6DwYq fPTBjy3RlHuojkFJTJeveOdnd7vvrs5nHpCsG6NvwRlwnEnqbBGk1KWMfDMqnEU8 khQJX431prVpzotTW3fWnpiw/FPAlgp+fDrEJAvpdEFlgZbSHx9XFfYGVYZVXjY= =NdOw -----END PGP SIGNATURE----- --499SXrOPNvFxQeNW56Ju0CGTfW5stSMTM-- From nobody Wed Jul 19 04:58: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 A24AB131CD9 for ; Wed, 19 Jul 2017 04:58:53 -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 8rdjWa7m1Jth for ; Wed, 19 Jul 2017 04:58:51 -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 2D918131CD8 for ; Wed, 19 Jul 2017 04:58: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 v6JBwlHK008433; Wed, 19 Jul 2017 13:58:47 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 414431D53C1; Wed, 19 Jul 2017 13:58:46 +0200 (CEST) Received: from 88.208.109.142 by webmail.entel.upc.edu with HTTP; Wed, 19 Jul 2017 13:58:37 +0200 Message-ID: In-Reply-To: References: Date: Wed, 19 Jul 2017 13:58:37 +0200 From: "Carles Gomez Montenegro" To: "Arun" Cc: "lp-wan" , "BARTHEL Dominique IMT/OLPS" 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: Delayed for 00:28:51 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Wed, 19 Jul 2017 13:58:47 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] need for MAX_ACK_REQUESTS? 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, 19 Jul 2017 11:58:54 -0000 Hi Arun, Thanks for commenting on this. Currently, MAX_ACK_REQUESTS applies only to the last fragment in a window, which can be viewed also as an "ACK request". MAX_FRAG_RETRIES applies to the previous fragments in the window. I have been thinking about this several times, and I see two options: 1.- Keep the two parameters. There might be reasons for setting MAX_ACK_REQUESTS to a higher value than MAX_FRAG_RETRIES. It may be specially critical to get an ACK (which gives feedback on the delivery of all fragments in the window), while one might want to be careful regarding how many times a fragment (from the rest of fragments in the window) is resent. In addition, it is possible to set the two parameters to the same value if desired. 2.- Remove MAX_ACK_REQUESTS and have just MAX_FRAG_RETRIES applying to all fragments. Which are your (and other) opinions on this? Thanks, Carles > Hi Carles, all, > > Do we still need this variable MAX_ACK_REQUESTS ? > MAX_FRAG_RETRIES is going to be the same (during retransmission we only > send the last fragment of the received bitmap which would be considered > as ACK REQUEST). correct? > > if this is already discussed in the thread of Dominique's review please > point me to the same. > > thanks, > > -- > > Arunprabhu Kandasamy > arun at ackl.io From nobody Wed Jul 19 07:11:47 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 6690D13188D for ; Wed, 19 Jul 2017 07:11:46 -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 uW-rXk04vcKy for ; Wed, 19 Jul 2017 07:11:44 -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 9BA0D131473 for ; Wed, 19 Jul 2017 07:11:44 -0700 (PDT) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 04F05FB8C2; Wed, 19 Jul 2017 16:11:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id vUrlHjHXeg50; Wed, 19 Jul 2017 16:11:41 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.158] (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 702F6FB8CF; Wed, 19 Jul 2017 16:11:40 +0200 (CEST) To: Carles Gomez Montenegro Cc: lp-wan , BARTHEL Dominique IMT/OLPS References: From: Arun Message-ID: Date: Wed, 19 Jul 2017 16:11:33 +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="FXHhTf3Lmr4TUtdu7vKohTEj4CSThRKdD" Archived-At: Subject: Re: [lp-wan] need for MAX_ACK_REQUESTS? 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, 19 Jul 2017 14:11:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FXHhTf3Lmr4TUtdu7vKohTEj4CSThRKdD Content-Type: multipart/mixed; boundary="Md9d5A0vRuvvkje05O7whx5EHNRACuFkJ"; protected-headers="v1" From: Arun To: Carles Gomez Montenegro Cc: lp-wan , BARTHEL Dominique IMT/OLPS Message-ID: Subject: Re: [lp-wan] need for MAX_ACK_REQUESTS? References: In-Reply-To: --Md9d5A0vRuvvkje05O7whx5EHNRACuFkJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Carles, I'm not clear about the purpose of having retry counter for each fragment= s. My understanding is as follows (w.r.t. ACK always) : - whenever there is a retransmission the receiver would expect the ACK_REQUEST packet to be least the CFN in the bitmap. we resend (at the same time increment retry counter for this fragment) only last fragment in case of timer expiry. when the counter reaches MAX_FRAG_RETRIES for CFN =3D1, what do we do? we cannot try resending CFN !=3D1 (in this case cfn=3D4) because the receiver would still expect CFN=3D1 for ACK_REQUEST or to send bitmap. So, I think it would be good to have only variable, can be MAX_ACK_REQUES= T. Tx Rx + + | | | cfn=3D6 | expected ACK_REQ_PACKET =3D cfn_0 +-------------------------> | cfn=3D5 | +-------------------------> | cfn=3D4 | +--------------------X----> | cfn=3D3 | +--------------------X----> | cfn=3D2 | +-------------------------> | cfn=3D1 | +--------------------X----> | cfn=3D0 | +-------------------------> | ACK:11001011 |expected ACK_REQ_PACKET =3D cfn_1 <-------------------------+ | cfn=3D4 | +-------------------X-----> | cfn=3D3 | +-------------------------> | cfn=3D1 | +-------------------X-----> timer expired | ACK:11011011 |expected ACK_REQ_PACKET =3D cfn_1 <--X----------------------+ | cfn=3D1 | +-------------------------> timer expired | ACK:11011011 |expected ACK_REQ_PACKET =3D cfn_1 <--X----------------------+ reached MAX_ACK_REQ | | discard cfn=3D1 | cfn=3D4?? | +-------------------------> wait until cfn=3D1 to= send ACK | | | | regards, On 19/07/2017 13:58, Carles Gomez Montenegro wrote: > Hi Arun, > > Thanks for commenting on this. > > Currently, MAX_ACK_REQUESTS applies only to the last fragment in a wind= ow, > which can be viewed also as an "ACK request". MAX_FRAG_RETRIES applies = to > the previous fragments in the window. > > I have been thinking about this several times, and I see two options: > > 1.- Keep the two parameters. There might be reasons for setting > MAX_ACK_REQUESTS to a higher value than MAX_FRAG_RETRIES. It may be > specially critical to get an ACK (which gives feedback on the delivery = of > all fragments in the window), while one might want to be careful regard= ing > how many times a fragment (from the rest of fragments in the window) is= > resent. In addition, it is possible to set the two parameters to the sa= me > value if desired. > > 2.- Remove MAX_ACK_REQUESTS and have just MAX_FRAG_RETRIES applying to = all > fragments. > > Which are your (and other) opinions on this? > > Thanks, > > Carles > > > >> Hi Carles, all, >> >> Do we still need this variable MAX_ACK_REQUESTS ? >> MAX_FRAG_RETRIES is going to be the same (during retransmission we on= ly >> send the last fragment of the received bitmap which would be considere= d >> as ACK REQUEST). correct? >> >> if this is already discussed in the thread of Dominique's review plea= se >> point me to the same. >> >> thanks, >> >> -- >> >> Arunprabhu Kandasamy >> arun at ackl.io --=20 Arunprabhu Kandasamy arun at ackl.io 2 bis rue de la Ch=C3=A2taigneraie 35510 Cesson-S=C3=A9vign=C3=A9=20 France=20 Phone: +33 (0)2.99.12.24.14 --Md9d5A0vRuvvkje05O7whx5EHNRACuFkJ-- --FXHhTf3Lmr4TUtdu7vKohTEj4CSThRKdD 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 iQIcBAEBCAAGBQJZb2iVAAoJENe8HNMjzJQRlJwP/3dFRjeo4TdxHHXQd7Z1ggZV PS+ZM/yPEF+uYc49cB3LXl4g2C34Wv6usPvyFYWFc7k+xGjS3R7SXzsRq8dXLDsT aDTYWUaBnO1z0CzDoa78M4nFOpZ5sGMpJsZCWcfjbVBhNcJkKqbrW0o8rTP5Xd0O g76+E8tr6JsliZaVUFvvVNRLoHYzauTjqJFRW8j4RTKI6MQPn6GacsjCndLiwn9Q kCxM3JjqzoUEaHvReaS/hF2XGzeO8jYJ83rG3gx0Kv+dpwlhls1jZ3111FKdYrtl qiCYmTlyT1nNfZhEsvFKdCLit3PhIPebnAG7OlMqekh3z+1p0humUUNfAPh44lfm Lz/d1TC8ar9XtKYyCSne8ERCRyjg2w9hy14fsgy0b8TCGYyNy0zpw4QXPlkekufq Bp3i0ohn1iNqnFdpmvWmlRVUF2R9MpgQCTeQB1S+9MM1pjVXpHEzfU3+5nLrBjr1 V3gwceqJ7/oe9WfBQLEFQYAr+HvJ5BwP+sYHbyxG8lA4hnd29FCuNsZpiBQPyVI0 HT5zPm9W5cnXulF/gOwhKZ6nydqspQPxUqDc5y5U9SX23xjT3LE72L7qzdaONngI NF0P9DIznG3fGa96OV8umJ4B5e6s1i38oh2BluXmhLaHOxG0U4EpPKUQJaZflu15 L8Uau5cIXkxIcmoa+pSa =VqNQ -----END PGP SIGNATURE----- --FXHhTf3Lmr4TUtdu7vKohTEj4CSThRKdD-- From nobody Wed Jul 19 08:20: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 E58B5131D70 for ; Wed, 19 Jul 2017 08:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 f1fMap8-tP-V for ; Wed, 19 Jul 2017 08:20:21 -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 83CD4131D39 for ; Wed, 19 Jul 2017 08:20:21 -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 v6JFKHMq041548; Wed, 19 Jul 2017 17:20:17 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 91FD01D53C1; Wed, 19 Jul 2017 17:20:16 +0200 (CEST) Received: from 88.208.109.142 by webmail.entel.upc.edu with HTTP; Wed, 19 Jul 2017 17:20:07 +0200 Message-ID: <6627d2074d9c4fc56c035b7d283acf19.squirrel@webmail.entel.upc.edu> In-Reply-To: References: Date: Wed, 19 Jul 2017 17:20:07 +0200 From: "Carles Gomez Montenegro" To: "Arun" Cc: "lp-wan" , "BARTHEL Dominique IMT/OLPS" 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 06:14:59 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 19 Jul 2017 17:20:17 +0200 (CEST) Archived-At: Subject: Re: [lp-wan] need for MAX_ACK_REQUESTS? 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, 19 Jul 2017 15:20:24 -0000 Hi Arun, Thanks for your response. Yes, I understand your example is correct. On your question, the same problem will happen anyway when any applicable "MAX_" parameter is reached. The main reason I can see for having two separate parameters is that a sender may want to resend the last fragment "many times" (say, e.g. 5) to request for an ACK. But when the ACK is received, maybe a sender cannot afford to resend as many times each specific fragment reported to be lost (imagine a "large window", say of 30 fragments where 8 out of those need to be resent). Maybe doing up to 5 retries for each lost fragment is too much, but a lower number of retries could be acceptable. Maybe a more simple option is to reduce the number of "MAX_" parameters to only 1 (you favor that to be MAX_ACK_REQUESTS), and if a sender determines from an ACK that there have been too many losses (and maybe it is not worth trying to recover all of them since link quality appears to be low), it can always abort. Thoughts? Carles > Hi Carles, > I'm not clear about the purpose of having retry counter for each > fragments. > > My understanding is as follows (w.r.t. ACK always) : > - whenever there is a retransmission the receiver would expect the > ACK_REQUEST packet to be least the CFN in the bitmap. > we resend (at the same time increment retry counter for this fragment) > only last fragment in case of timer expiry. when the counter reaches > MAX_FRAG_RETRIES for CFN =1, what do we do? > we cannot try resending CFN !=1 (in this case cfn=4) because the > receiver would still expect CFN=1 for ACK_REQUEST or to send bitmap. > So, I think it would be good to have only variable, can be > MAX_ACK_REQUEST. > > > > Tx Rx > + + > | | > | cfn=6 | expected > ACK_REQ_PACKET = cfn_0 > +-------------------------> > | cfn=5 | > +-------------------------> > | cfn=4 | > +--------------------X----> > | cfn=3 | > +--------------------X----> > | cfn=2 | > +-------------------------> > | cfn=1 | > +--------------------X----> > | cfn=0 | > +-------------------------> > | ACK:11001011 |expected > ACK_REQ_PACKET = cfn_1 > <-------------------------+ > | cfn=4 | > +-------------------X-----> > | cfn=3 | > +-------------------------> > | cfn=1 | > +-------------------X-----> > timer expired | ACK:11011011 |expected > ACK_REQ_PACKET = cfn_1 > <--X----------------------+ > | cfn=1 | > +-------------------------> > timer expired | ACK:11011011 |expected > ACK_REQ_PACKET = cfn_1 > <--X----------------------+ > reached MAX_ACK_REQ | | > discard cfn=1 | cfn=4?? | > +-------------------------> wait until cfn=1 to > send ACK > | | > | | > regards, > > On 19/07/2017 13:58, Carles Gomez Montenegro wrote: >> Hi Arun, >> >> Thanks for commenting on this. >> >> Currently, MAX_ACK_REQUESTS applies only to the last fragment in a >> window, >> which can be viewed also as an "ACK request". MAX_FRAG_RETRIES applies >> to >> the previous fragments in the window. >> >> I have been thinking about this several times, and I see two options: >> >> 1.- Keep the two parameters. There might be reasons for setting >> MAX_ACK_REQUESTS to a higher value than MAX_FRAG_RETRIES. It may be >> specially critical to get an ACK (which gives feedback on the delivery >> of >> all fragments in the window), while one might want to be careful >> regarding >> how many times a fragment (from the rest of fragments in the window) is >> resent. In addition, it is possible to set the two parameters to the >> same >> value if desired. >> >> 2.- Remove MAX_ACK_REQUESTS and have just MAX_FRAG_RETRIES applying to >> all >> fragments. >> >> Which are your (and other) opinions on this? >> >> Thanks, >> >> Carles >> >> >> >>> Hi Carles, all, >>> >>> Do we still need this variable MAX_ACK_REQUESTS ? >>> MAX_FRAG_RETRIES is going to be the same (during retransmission we >>> only >>> send the last fragment of the received bitmap which would be considered >>> as ACK REQUEST). correct? >>> >>> if this is already discussed in the thread of Dominique's review >>> please >>> point me to the same. >>> >>> thanks, >>> >>> -- >>> >>> Arunprabhu Kandasamy >>> arun at ackl.io > > -- > Arunprabhu Kandasamy > arun at ackl.io > > 2 bis rue de la Châtaigneraie > 35510 Cesson-Sévigné > France > Phone: +33 (0)2.99.12.24.14 > > > From nobody Wed Jul 19 09:35:46 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 AACFA12F3CB for ; Wed, 19 Jul 2017 09:35:38 -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 JEHEwqPGgJJz for ; Wed, 19 Jul 2017 09:35:36 -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 3D8E0127077 for ; Wed, 19 Jul 2017 09:35:36 -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 9E347A80F5; Wed, 19 Jul 2017 18:35:34 +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 J-AMO23R_hwj; Wed, 19 Jul 2017 18:35:33 +0200 (CEST) X-Originating-IP: 192.44.77.204 Received: from [192.168.1.158] (nat-asr-incub-b204.rennes.enst-bretagne.fr [192.44.77.204]) (Authenticated sender: arun@acklio.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 4A7EBA80CE; Wed, 19 Jul 2017 18:35:32 +0200 (CEST) To: Carles Gomez Montenegro Cc: lp-wan , BARTHEL Dominique IMT/OLPS References: <6627d2074d9c4fc56c035b7d283acf19.squirrel@webmail.entel.upc.edu> From: Arun Message-ID: <8cf063e5-b0cc-ba05-98ec-1de7b4de336d@ackl.io> Date: Wed, 19 Jul 2017 18:35:28 +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: <6627d2074d9c4fc56c035b7d283acf19.squirrel@webmail.entel.upc.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0BrflpmC5N2bDSLNGTFPhrxjqfocMjOkW" Archived-At: Subject: Re: [lp-wan] need for MAX_ACK_REQUESTS? 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, 19 Jul 2017 16:35:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0BrflpmC5N2bDSLNGTFPhrxjqfocMjOkW Content-Type: multipart/mixed; boundary="EfjvSV1PCaGalhwwOfWXAUkSaN6OOAvKE"; protected-headers="v1" From: Arun To: Carles Gomez Montenegro Cc: lp-wan , BARTHEL Dominique IMT/OLPS Message-ID: <8cf063e5-b0cc-ba05-98ec-1de7b4de336d@ackl.io> Subject: Re: [lp-wan] need for MAX_ACK_REQUESTS? References: <6627d2074d9c4fc56c035b7d283acf19.squirrel@webmail.entel.upc.edu> In-Reply-To: <6627d2074d9c4fc56c035b7d283acf19.squirrel@webmail.entel.upc.edu> --EfjvSV1PCaGalhwwOfWXAUkSaN6OOAvKE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Thanks Carles for the explanation. Yes, I agree. Keeping a lower value of retries seems reasonable in case of large window. I prefer to have simpler option, MAX_ACK_REQUEST to decide when to abort but will wait for inputs from others as well. On 19/07/2017 17:20, Carles Gomez Montenegro wrote: > Hi Arun, > > Thanks for your response. > > Yes, I understand your example is correct. On your question, the same > problem will happen anyway when any applicable "MAX_" parameter is > reached. > > The main reason I can see for having two separate parameters is that a > sender may want to resend the last fragment "many times" (say, e.g. 5) = to > request for an ACK. But when the ACK is received, maybe a sender cannot= > afford to resend as many times each specific fragment reported to be lo= st > (imagine a "large window", say of 30 fragments where 8 out of those nee= d > to be resent). Maybe doing up to 5 retries for each lost fragment is to= o > much, but a lower number of retries could be acceptable. > > Maybe a more simple option is to reduce the number of "MAX_" parameters= to > only 1 (you favor that to be MAX_ACK_REQUESTS), and if a sender determi= nes > from an ACK that there have been too many losses (and maybe it is not > worth trying to recover all of them since link quality appears to be lo= w), > it can always abort. > > Thoughts? > > Carles > > > > >> Hi Carles, >> I'm not clear about the purpose of having retry counter for each >> fragments. >> >> My understanding is as follows (w.r.t. ACK always) : >> - whenever there is a retransmission the receiver would expect the >> ACK_REQUEST packet to be least the CFN in the bitmap. >> we resend (at the same time increment retry counter for this fragment= ) >> only last fragment in case of timer expiry. when the counter reaches >> MAX_FRAG_RETRIES for CFN =3D1, what do we do? >> we cannot try resending CFN !=3D1 (in this case cfn=3D4) because the >> receiver would still expect CFN=3D1 for ACK_REQUEST or to send bitmap.= >> So, I think it would be good to have only variable, can be >> MAX_ACK_REQUEST. >> >> >> >> Tx Rx >> + + >> | | >> | cfn=3D6 | expected >> ACK_REQ_PACKET =3D cfn_0 >> +-------------------------> >> | cfn=3D5 | >> +-------------------------> >> | cfn=3D4 | >> +--------------------X----> >> | cfn=3D3 | >> +--------------------X----> >> | cfn=3D2 | >> +-------------------------> >> | cfn=3D1 | >> +--------------------X----> >> | cfn=3D0 | >> +-------------------------> >> | ACK:11001011 |expected >> ACK_REQ_PACKET =3D cfn_1 >> <-------------------------+ >> | cfn=3D4 | >> +-------------------X-----> >> | cfn=3D3 | >> +-------------------------> >> | cfn=3D1 | >> +-------------------X-----> >> timer expired | ACK:11011011 |expected >> ACK_REQ_PACKET =3D cfn_1 >> <--X----------------------+ >> | cfn=3D1 | >> +-------------------------> >> timer expired | ACK:11011011 |expected >> ACK_REQ_PACKET =3D cfn_1 >> <--X----------------------+ >> reached MAX_ACK_REQ | | >> discard cfn=3D1 | cfn=3D4?? | >> +-------------------------> wait until cfn=3D1= to >> send ACK >> | | >> | | >> regards, >> >> On 19/07/2017 13:58, Carles Gomez Montenegro wrote: >>> Hi Arun, >>> >>> Thanks for commenting on this. >>> >>> Currently, MAX_ACK_REQUESTS applies only to the last fragment in a >>> window, >>> which can be viewed also as an "ACK request". MAX_FRAG_RETRIES applie= s >>> to >>> the previous fragments in the window. >>> >>> I have been thinking about this several times, and I see two options:= >>> >>> 1.- Keep the two parameters. There might be reasons for setting >>> MAX_ACK_REQUESTS to a higher value than MAX_FRAG_RETRIES. It may be >>> specially critical to get an ACK (which gives feedback on the deliver= y >>> of >>> all fragments in the window), while one might want to be careful >>> regarding >>> how many times a fragment (from the rest of fragments in the window) = is >>> resent. In addition, it is possible to set the two parameters to the >>> same >>> value if desired. >>> >>> 2.- Remove MAX_ACK_REQUESTS and have just MAX_FRAG_RETRIES applying t= o >>> all >>> fragments. >>> >>> Which are your (and other) opinions on this? >>> >>> Thanks, >>> >>> Carles >>> >>> >>> >>>> Hi Carles, all, >>>> >>>> Do we still need this variable MAX_ACK_REQUESTS ? >>>> MAX_FRAG_RETRIES is going to be the same (during retransmission we >>>> only >>>> send the last fragment of the received bitmap which would be conside= red >>>> as ACK REQUEST). correct? >>>> >>>> if this is already discussed in the thread of Dominique's review >>>> please >>>> point me to the same. >>>> >>>> thanks, >>>> >>>> -- >>>> >>>> Arunprabhu Kandasamy >>>> arun at ackl.io >> -- >> Arunprabhu Kandasamy >> arun at ackl.io >> >> 2 bis rue de la Ch=C3=83=C2=A2taigneraie >> 35510 Cesson-S=C3=83=C2=A9vign=C3=83=C2=A9 >> France >> Phone: +33 (0)2.99.12.24.14 >> >> >> > --=20 Arunprabhu Kandasamy arun at ackl.io 2 bis rue de la Ch=C3=A2taigneraie 35510 Cesson-S=C3=A9vign=C3=A9=20 France=20 Phone: +33 (0)2.99.12.24.14 --EfjvSV1PCaGalhwwOfWXAUkSaN6OOAvKE-- --0BrflpmC5N2bDSLNGTFPhrxjqfocMjOkW 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 iQIcBAEBCAAGBQJZb4pQAAoJENe8HNMjzJQRFJoP/A+Dm2JPojfXO3+jkeLx0sCp RDAPZWE+2AmZtxPmhyQ42SkdVBzyr+P9qciJMbMJOqjuHkWjswEuR3Vq7Up8oNNM /Ud8ZLya7UsvILx1x4Wbk5QXibmljrR94Rn6O1JzWe59JijXA+9TR09csig5J1ZU 9gp5jE5j2XTi0sxFdW1HDNSTj3bWpYGN/Sgvi4PAbQ3GLyw7AByH8MpZjbNxijf9 eymE9sJVhTbVcOXByX9h0fN+GU1DHcYS14q0S4MzqxfkwivGueBVWKQYDGV7h1RN c45K5FDa/eXlC8ab7jZzR+0KtsqgBVfGdNTVohz6RqW7doh/cXz8kdNChnm8qw3j KmLzpH0kU50VOizjvwCbvCq83SWTtu1ngEo043fCM5slI0xjxl6TpYYDt+qpjkqh /6CdUCfvBx+gzJdQ/ousBQC3RALPH8n0ETDbWp4O9Cts6l0sge7vyoJadE3kyxTo ajpwAWQmbjj2Fw8uglByOlkNGtF83yzfWtfhO8wKJUgIQRU9mE9c3vyHWQEO+SVJ Gv7Y5wSG+pgOieIU/pSsTzNZWd1ofYLmW5AWMixSwHE38e49+ij1j0qX5C9Q0BZt mRJc3xUUyDDoYToI9t9FMTq8sItuHXseVdSRK6l5GzXYjVN15hfXFwRL16NNDLdE zoYIFYutpAfPCqZFbYp9 =DxgM -----END PGP SIGNATURE----- --0BrflpmC5N2bDSLNGTFPhrxjqfocMjOkW-- From nobody Wed Jul 19 12:10:17 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 01212131B3B for ; Wed, 19 Jul 2017 12:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TthCHMxfPtLS for ; Wed, 19 Jul 2017 12:10:13 -0700 (PDT) Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (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 55647131B97 for ; Wed, 19 Jul 2017 12:10:13 -0700 (PDT) Received: from [10.0.1.4] ([24.13.37.133]) by :SMTPAUTH: with SMTP id XuLtdns8eznf6XuLudLYiO; Wed, 19 Jul 2017 12:09:42 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-BF0A3E94-35C3-4EAF-B552-5E12A480372D Mime-Version: 1.0 (1.0) From: "Pat.kinney@kinneyconsultingllc.com" X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Wed, 19 Jul 2017 14:09:41 -0500 Cc: lp-wan , Bob Heile , Mingui Zhang , =?utf-8?Q?Jonathan_Mu=C3=B1oz?= , Remy Liubing Content-Transfer-Encoding: 7bit Message-Id: References: <6f22c5a9-60f6-3995-f8e5-79f0443ff748@earthlink.net> To: Charlie Perkins X-CMAE-Envelope: MS4wfKPpB9kaPeitO8H2R20G3nJSeoXASzlC77KgMbsY/DATSPGPg8GG3Mhll753Hz1P3xKpFYQqtdhtmpQPnVKW5KVRzFD62u5fQscjBs63rCy6Z66dD2i3 6+CMycs6ew2fdL4WVHt0viSfCTyCD3WiuBWYyIuJY4Tc4g29LpkF7B+UVGlh0cR683DX6nMEeXUKQD6LbbHHa2ZStddE5paPrnKwQFSxA8ltjE+Tb+f4SavG 3XdTXCYb4l1RDN9zCEkFfBJof7+4tBwR97u2wJSrsliN8OROvoD2SEi0LgsXlZY3QRp8Vy5GnFmVPuIrp4mMrWxbtJ5PG9Ut13dlpxBJsj2gskq7aigDxkBf iR67+cbt Archived-At: Subject: Re: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN characteristics 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, 19 Jul 2017 19:10:16 -0000 --Apple-Mail-BF0A3E94-35C3-4EAF-B552-5E12A480372D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You raised some very good points about Wi-SUN, Charlie. =20 Perhaps another point could be the ability to change the PHY characteristics= such as modulations, packet size, or FEC; or change out the whole PHY for a= different band. Patrick Kinney Kinney Consulting +1.847.960.3715 pat.kinney@kinneyconsultingllc.com > On Jul 18, 2017, at 23:07, Charlie Perkins = wrote: >=20 >=20 > Hello folks, >=20 > I'd like to suggest some additional text to be included in the Wi-SUN over= view section of the document. I think it is important to emphasize the foll= owing characteristics. These comments can be viewed as more or less the dis= tillation of information described at longer length in our individual Intern= et Draft contribution submitted earlier about Wi-SUN. We have received many= comments about that draft, and it needs to be significantly revised and res= ubmitted as soon as possible. But the [lpwan] Overview document is in Last C= all, and we don't have time to revise our individual draft before the end of= Last Call. >=20 > Given a little more time after this busy week, I would also like to includ= e a fuller description about the Wi-SUN mesh protocol choices. If that is a= cceptable, I will provide text next week. >=20 > Regards, > Charlie P. > --------------------------------------------------------------------------= --------------------------------- > -Coverage >=20 > The range of Wi-SUN FAN is typically 2~3 km in line of sight, matching the= needs of neighborhood area networks, campus area networks, or corporate are= a networks. The range can also be extended via multi-hop networking. >=20 > =20 >=20 > - High bandwidth, low latency >=20 > Wi-SUN's relatively high bandwidth, i.e. up to 300 kbps [FANTPS], enables r= emote update and upgrade of devices so that they can handle new applications= , extending their working life. Some IoT applications may require on-demand c= ontrol, e.g. on-demand metering in AMI, device control in distribution autom= ation. Wi-SUN supports these requirements by providing high bandwidth, low l= atency (0.02s) and bi-directional communication. >=20 > =20 >=20 > - Low power consumption >=20 > FAN devices draw less than 2 uA when resting and only 8 mA when listening [= COM]. Such devices can maintain a long lifetime even if they are frequently l= istening. For instance, suppose the device transmits data for 10 ms once eve= ry 10 s; theoretically, a battery of 1000 mAh can last more than 10 years. >=20 > =20 >=20 > - Mesh topology >=20 > Wi-SUN FAN mesh networks offer self-forming and self-healing capabilities.= When a new device is powered up, it can automatically discover communicatio= n peers. If the link is interrupted by obstacles, a device can switch to alt= ernative redundant paths. The reliability of Wi-SUN has been proven for year= s in harsh and remote environments. >=20 > =20 >=20 > - Scalability >=20 > 10s of millions Wi-SUN FAN devices have been deployed all over the world, i= ncluding several deployments with more than 1 million devices [COM]. This de= monstrates the scalability of Wi-SUN FAN in urban, suburban an= d rural environments. >=20 >=20 >=20 > =20 >=20 > The following references could be added in the LPWAN overview draft: >=20 > [COM] Wi-SUN Alliance, =E2=80=9CComparing IoT Networks at a Glance=E2=80=9D= , May 2017. >=20 > [FANTPS] Wi-SUN Alliance, "Technical Profile Specification Field Area Netw= ork", May 2016. >=20 > =20 >=20 > Figure.8 needs a column for Wi-SUN: >=20 > >=20 > =20 >=20 > Another paragraph could be added regarding the Wi-SUN security solution, s= omething along the following lines. =20 >=20 > Wi-SUN has made it a design goal to rely on industry standard security sol= utions instead of special-purpose or proprietary methods. = In this way, users and equipment vendors can have a high degree of confiden= ce that their system will truly be secure. Moreover it will be easier to pr= ovide secure interfaces to other system modules and components, which are mo= re likely to support standard security protocols without special purpose cod= ing. >=20 > --------------------------------------------------------------------------= ------------------------------------------------ >=20 > Regards, > Charlie P. >=20 >
> _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan --Apple-Mail-BF0A3E94-35C3-4EAF-B552-5E12A480372D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You raised some very good points about= Wi-SUN, Charlie.  
Perhaps another= point could be the ability to change the PHY characteristics such as modula= tions, packet size, or FEC; or change out the whole PHY for a different band= .

Patrick Kinney
Kinney Consulting

On Jul 18, 2017, at 23:07, Charli= e Perkins <charles.perki= ns@earthlink.net> wrote:

= =20 =20 =20
Hello folks,

I'd like to suggest some additional text to be included in the Wi-SUN overview section of the document.  I think it is important to emphasize the following characteristics.  These comments can be viewed as more or less the distillation of information described at longer length in our individual Internet Draft contribution submitted earlier about Wi-SUN.  We= have received many comments about that draft, and it needs to be significantly revised and resubmitted as soon as possible.  But= the [lpwan] Overview document is in Last Call, and we don't have time to revise our individual draft before the end of Last Call.
=
Given a little more time after this busy week, I would also like to include a fuller description about the Wi-SUN mesh protocol choices.  If that is acceptable, I will provide text next week.=

Regards,
Charlie P.
----------------------------------------------------------------------------= -------------------------------

-Coverage

The range of Wi-SUN= FAN is typically 2~3 km in line of sight, matching the needs of neighborhood area networks, campus area networks, or corporate area networks. The range can also be extended via multi-hop networking.

 

- High bandwidth, low latency

Wi-SUN's relatively= high bandwidth, i.e. up to 300 kbps [FANTPS], enables remote update and upgrade of devices so that they can handle new applications, extending their working life. Some IoT applications may require on-demand control, e.g. on-demand metering in AMI, device control in distribution automation. Wi-SUN supports these requirements by providing high bandwidth, low latency (0.02s) and bi-directional communication.

 

- Low power consumption

FAN devices draw less than 2 uA when resting and only 8 mA when listening [COM]. Such devices can maintain a long lifetime even if they are frequently listening. For instance, suppose the device transmits data for 10 ms once every 10 s; theoretically, a battery of 1000 mAh can last more than 10 years.

 

- Mesh topology

Wi-SUN FAN mesh networks offer self-forming and self-healing capabilities. When a new device is powered up, it can automatically discover communication peers. If the link is interrupted by obstacles, a device can switch to alternative redundant paths. The reliability of Wi-SUN has been proven for years in harsh and remote environments.

 

- Scalability<= /o:p>

10s of millions Wi-SUN FAN devices have been deployed all over the world, including several deployments with more than 1 million devices [COM]. This demonstrates the scalability of Wi-SUN FAN in urban, suburban and rural environments.


 

The following references could be added in the LPWAN overview draft:

[COM] Wi-SUN Alliance, =E2=80=9CComparing IoT Networks at a Glance=E2=80=9D, M= ay 2017.

[FANTPS] Wi-SUN Alliance, "Technical Profile Specification Field Area Network", May 2016.

 

Figure.8 needs a column for Wi-SUN:

<image001.png>= ;

 

Another paragraph could be added regarding the Wi-SUN security solution, something along the following lines. 

Wi-SUN has made it a design goal to rely on industry standard security solutions instead of special-purpose or proprietary methods.  In this way, users and equipmen= t vendors can have a high degree of confidence that their system will truly be secure.  Moreover it will be easier to provide secure interfaces to other system modules and components, which are more likely to support standard security protocols without special purpose coding.

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

Regards,
Charlie P.

=20
<Figure 8 terminology.E= FX>
______________= _________________________________
lp-wan mailing list=
lp-wan@ietf.org
<= span>https://www.ie= tf.org/mailman/listinfo/lp-wan
= --Apple-Mail-BF0A3E94-35C3-4EAF-B552-5E12A480372D-- From nobody Wed Jul 19 19:08:39 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 5AAC612EACC for ; Wed, 19 Jul 2017 19:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LGlsa7pGfd9 for ; Wed, 19 Jul 2017 19:08:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F7B126C2F for ; Wed, 19 Jul 2017 19:08:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKW61983; Thu, 20 Jul 2017 02:08:29 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Jul 2017 03:08:28 +0100 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.222]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Thu, 20 Jul 2017 10:08:15 +0800 From: "Liubing (Remy)" To: "Patrick Wetterwald (pwetterw)" , Charlie Perkins , lp-wan CC: Bob Heile , =?utf-8?B?Sm9uYXRoYW4gTXXDsW96?= Thread-Topic: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN characteristics Thread-Index: AQHTAESas+RCO3nO0kChksG2lNL9laJa/oCAgADzvGA= Date: Thu, 20 Jul 2017 02:08:15 +0000 Message-ID: References: <6f22c5a9-60f6-3995-f8e5-79f0443ff748@earthlink.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.180.83] Content-Type: multipart/alternative; boundary="_000_BB09947B5326FE42BA3918FA28765C2ED2D79BDGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5970109E.002C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.222, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3d2d7fe40d39b51769ec050abb75a490 Archived-At: Subject: Re: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN characteristics 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, 20 Jul 2017 02:08:35 -0000 --_000_BB09947B5326FE42BA3918FA28765C2ED2D79BDGGEMM506MBSchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gZm9sa3MsDQpJIGFncmVlIHdpdGggQ2hhcmxpZSBhbmQgUGF0cmljayBXZXR0ZXJ3YWxk IHRoYXQgV2ktU1VOIEZBTiB1c2VzIHNvbWUgZGlmZmVyZW50IHRlcm1pbm9sb2dpZXMgYW5kIHNo b3VsZCBiZSBpbGx1c3RyYXRlZCBhcyBhIGNvbHVtbiBpbiBGaWd1cmUuOCBvZiB0aGUgTFBXQU4g b3ZlcnZpZXcgZHJhZnQuDQoNCkFzIG1lbnRpb25lZCBieSBQYXRyaWNrIEtpbm5leSwgdGhlIHBh Y2tldCBzaXplIG9mIFdpLVNVTiBjYW4gYWxzbyBiZSBpbmNsdWRlZC4NCg0KQmVzdCByZWdhcmRz LA0KUmVteQ0KRnJvbTogUGF0Lmtpbm5leUBraW5uZXljb25zdWx0aW5nbGxjLmNvbSBbbWFpbHRv OnBhdC5raW5uZXlAa2lubmV5Y29uc3VsdGluZ2xsYy5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVs eSAyMCwgMjAxNyAzOjEwIEFNDQpUbzogQ2hhcmxpZSBQZXJraW5zDQpDYzogbHAtd2FuOyBCb2Ig SGVpbGU7IFpoYW5nbWluZ3VpIChNYXJ0aW4pOyBKb25hdGhhbiBNdcOxb3o7IExpdWJpbmcgKFJl bXkpDQpTdWJqZWN0OiBSZTogW2xwLXdhbl0gQ29tbWVudHMgdG8gdGhlIFtscHdhbl0gT3ZlcnZp ZXcgcmU6IFdpLVNVTiBjaGFyYWN0ZXJpc3RpY3MNCg0KWW91IHJhaXNlZCBzb21lIHZlcnkgZ29v ZCBwb2ludHMgYWJvdXQgV2ktU1VOLCBDaGFybGllLg0KUGVyaGFwcyBhbm90aGVyIHBvaW50IGNv dWxkIGJlIHRoZSBhYmlsaXR5IHRvIGNoYW5nZSB0aGUgUEhZIGNoYXJhY3RlcmlzdGljcyBzdWNo IGFzIG1vZHVsYXRpb25zLCBwYWNrZXQgc2l6ZSwgb3IgRkVDOyBvciBjaGFuZ2Ugb3V0IHRoZSB3 aG9sZSBQSFkgZm9yIGEgZGlmZmVyZW50IGJhbmQuDQoNClBhdHJpY2sgS2lubmV5DQpLaW5uZXkg Q29uc3VsdGluZw0KKzEuODQ3Ljk2MC4zNzE1DQpwYXQua2lubmV5QGtpbm5leWNvbnN1bHRpbmds bGMuY29tPG1haWx0bzpwYXQua2lubmV5QGtpbm5leWNvbnN1bHRpbmdsbGMuY29tPg0KDQpPbiBK dWwgMTgsIDIwMTcsIGF0IDIzOjA3LCBDaGFybGllIFBlcmtpbnMgPGNoYXJsZXMucGVya2luc0Bl YXJ0aGxpbmsubmV0PG1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4+IHdyb3Rl Og0KDQpIZWxsbyBmb2xrcywNCg0KSSdkIGxpa2UgdG8gc3VnZ2VzdCBzb21lIGFkZGl0aW9uYWwg dGV4dCB0byBiZSBpbmNsdWRlZCBpbiB0aGUgV2ktU1VOIG92ZXJ2aWV3IHNlY3Rpb24gb2YgdGhl IGRvY3VtZW50LiAgSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gZW1waGFzaXplIHRoZSBmb2xs b3dpbmcgY2hhcmFjdGVyaXN0aWNzLiAgVGhlc2UgY29tbWVudHMgY2FuIGJlIHZpZXdlZCBhcyBt b3JlIG9yIGxlc3MgdGhlIGRpc3RpbGxhdGlvbiBvZiBpbmZvcm1hdGlvbiBkZXNjcmliZWQgYXQg bG9uZ2VyIGxlbmd0aCBpbiBvdXIgaW5kaXZpZHVhbCBJbnRlcm5ldCBEcmFmdCBjb250cmlidXRp b24gc3VibWl0dGVkIGVhcmxpZXIgYWJvdXQgV2ktU1VOLiAgV2UgaGF2ZSByZWNlaXZlZCBtYW55 IGNvbW1lbnRzIGFib3V0IHRoYXQgZHJhZnQsIGFuZCBpdCBuZWVkcyB0byBiZSBzaWduaWZpY2Fu dGx5IHJldmlzZWQgYW5kIHJlc3VibWl0dGVkIGFzIHNvb24gYXMgcG9zc2libGUuICBCdXQgdGhl IFtscHdhbl0gT3ZlcnZpZXcgZG9jdW1lbnQgaXMgaW4gTGFzdCBDYWxsLCBhbmQgd2UgZG9uJ3Qg aGF2ZSB0aW1lIHRvIHJldmlzZSBvdXIgaW5kaXZpZHVhbCBkcmFmdCBiZWZvcmUgdGhlIGVuZCBv ZiBMYXN0IENhbGwuDQoNCkdpdmVuIGEgbGl0dGxlIG1vcmUgdGltZSBhZnRlciB0aGlzIGJ1c3kg d2VlaywgSSB3b3VsZCBhbHNvIGxpa2UgdG8gaW5jbHVkZSBhIGZ1bGxlciBkZXNjcmlwdGlvbiBh Ym91dCB0aGUgV2ktU1VOIG1lc2ggcHJvdG9jb2wgY2hvaWNlcy4gIElmIHRoYXQgaXMgYWNjZXB0 YWJsZSwgSSB3aWxsIHByb3ZpZGUgdGV4dCBuZXh0IHdlZWsuDQoNClJlZ2FyZHMsDQpDaGFybGll IFAuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQotQ292ZXJhZ2UNCg0KVGhlIHJhbmdlIG9mIFdpLVNVTiBGQU4gaXMgdHlwaWNhbGx5IDJ+MyBr bSBpbiBsaW5lIG9mIHNpZ2h0LCBtYXRjaGluZyB0aGUgbmVlZHMgb2YgbmVpZ2hib3Job29kIGFy ZWEgbmV0d29ya3MsIGNhbXB1cyBhcmVhIG5ldHdvcmtzLCBvciBjb3Jwb3JhdGUgYXJlYSBuZXR3 b3Jrcy4gVGhlIHJhbmdlIGNhbiBhbHNvIGJlIGV4dGVuZGVkIHZpYSBtdWx0aS1ob3AgbmV0d29y a2luZy4NCg0KDQoNCi0gSGlnaCBiYW5kd2lkdGgsIGxvdyBsYXRlbmN5DQoNCldpLVNVTidzIHJl bGF0aXZlbHkgaGlnaCBiYW5kd2lkdGgsIGkuZS4gdXAgdG8gMzAwIGticHMgW0ZBTlRQU10sIGVu YWJsZXMgcmVtb3RlIHVwZGF0ZSBhbmQgdXBncmFkZSBvZiBkZXZpY2VzIHNvIHRoYXQgdGhleSBj YW4gaGFuZGxlIG5ldyBhcHBsaWNhdGlvbnMsIGV4dGVuZGluZyB0aGVpciB3b3JraW5nIGxpZmUu IFNvbWUgSW9UIGFwcGxpY2F0aW9ucyBtYXkgcmVxdWlyZSBvbi1kZW1hbmQgY29udHJvbCwgZS5n LiBvbi1kZW1hbmQgbWV0ZXJpbmcgaW4gQU1JLCBkZXZpY2UgY29udHJvbCBpbiBkaXN0cmlidXRp b24gYXV0b21hdGlvbi4gV2ktU1VOIHN1cHBvcnRzIHRoZXNlIHJlcXVpcmVtZW50cyBieSBwcm92 aWRpbmcgaGlnaCBiYW5kd2lkdGgsIGxvdyBsYXRlbmN5ICgwLjAycykgYW5kIGJpLWRpcmVjdGlv bmFsIGNvbW11bmljYXRpb24uDQoNCg0KDQotIExvdyBwb3dlciBjb25zdW1wdGlvbg0KDQpGQU4g ZGV2aWNlcyBkcmF3IGxlc3MgdGhhbiAyIHVBIHdoZW4gcmVzdGluZyBhbmQgb25seSA4IG1BIHdo ZW4gbGlzdGVuaW5nIFtDT01dLiBTdWNoIGRldmljZXMgY2FuIG1haW50YWluIGEgbG9uZyBsaWZl dGltZSBldmVuIGlmIHRoZXkgYXJlIGZyZXF1ZW50bHkgbGlzdGVuaW5nLiBGb3IgaW5zdGFuY2Us IHN1cHBvc2UgdGhlIGRldmljZSB0cmFuc21pdHMgZGF0YSBmb3IgMTAgbXMgb25jZSBldmVyeSAx MCBzOyB0aGVvcmV0aWNhbGx5LCBhIGJhdHRlcnkgb2YgMTAwMCBtQWggY2FuIGxhc3QgbW9yZSB0 aGFuIDEwIHllYXJzLg0KDQoNCg0KLSBNZXNoIHRvcG9sb2d5DQoNCldpLVNVTiBGQU4gbWVzaCBu ZXR3b3JrcyBvZmZlciBzZWxmLWZvcm1pbmcgYW5kIHNlbGYtaGVhbGluZyBjYXBhYmlsaXRpZXMu IFdoZW4gYSBuZXcgZGV2aWNlIGlzIHBvd2VyZWQgdXAsIGl0IGNhbiBhdXRvbWF0aWNhbGx5IGRp c2NvdmVyIGNvbW11bmljYXRpb24gcGVlcnMuIElmIHRoZSBsaW5rIGlzIGludGVycnVwdGVkIGJ5 IG9ic3RhY2xlcywgYSBkZXZpY2UgY2FuIHN3aXRjaCB0byBhbHRlcm5hdGl2ZSByZWR1bmRhbnQg cGF0aHMuIFRoZSByZWxpYWJpbGl0eSBvZiBXaS1TVU4gaGFzIGJlZW4gcHJvdmVuIGZvciB5ZWFy cyBpbiBoYXJzaCBhbmQgcmVtb3RlIGVudmlyb25tZW50cy4NCg0KDQoNCi0gU2NhbGFiaWxpdHkN Cg0KMTBzIG9mIG1pbGxpb25zIFdpLVNVTiBGQU4gZGV2aWNlcyBoYXZlIGJlZW4gZGVwbG95ZWQg YWxsIG92ZXIgdGhlIHdvcmxkLCBpbmNsdWRpbmcgc2V2ZXJhbCBkZXBsb3ltZW50cyB3aXRoIG1v cmUgdGhhbiAxIG1pbGxpb24gZGV2aWNlcyBbQ09NXS4gVGhpcyBkZW1vbnN0cmF0ZXMgdGhlIHNj YWxhYmlsaXR5IG9mIFdpLVNVTiBGQU4gaW4gdXJiYW4sIHN1YnVyYmFuIGFuZCBydXJhbCBlbnZp cm9ubWVudHMuDQoNCg0KDQoNCg0KVGhlIGZvbGxvd2luZyByZWZlcmVuY2VzIGNvdWxkIGJlIGFk ZGVkIGluIHRoZSBMUFdBTiBvdmVydmlldyBkcmFmdDoNCg0KW0NPTV0gV2ktU1VOIEFsbGlhbmNl LCDigJxDb21wYXJpbmcgSW9UIE5ldHdvcmtzIGF0IGEgR2xhbmNl4oCdLCBNYXkgMjAxNy4NCg0K W0ZBTlRQU10gV2ktU1VOIEFsbGlhbmNlLCAiVGVjaG5pY2FsIFByb2ZpbGUgU3BlY2lmaWNhdGlv biBGaWVsZCBBcmVhIE5ldHdvcmsiLCBNYXkgMjAxNi4NCg0KDQoNCkZpZ3VyZS44IG5lZWRzIGEg Y29sdW1uIGZvciBXaS1TVU46DQoNCjxpbWFnZTAwMS5wbmc+DQoNCg0KDQpBbm90aGVyIHBhcmFn cmFwaCBjb3VsZCBiZSBhZGRlZCByZWdhcmRpbmcgdGhlIFdpLVNVTiBzZWN1cml0eSBzb2x1dGlv biwgc29tZXRoaW5nIGFsb25nIHRoZSBmb2xsb3dpbmcgbGluZXMuDQoNCg0KV2ktU1VOIGhhcyBt YWRlIGl0IGEgZGVzaWduIGdvYWwgdG8gcmVseSBvbiBpbmR1c3RyeSBzdGFuZGFyZCBzZWN1cml0 eSBzb2x1dGlvbnMgaW5zdGVhZCBvZiBzcGVjaWFsLXB1cnBvc2Ugb3IgcHJvcHJpZXRhcnkgbWV0 aG9kcy4gIEluIHRoaXMgd2F5LCB1c2VycyBhbmQgZXF1aXBtZW50IHZlbmRvcnMgY2FuIGhhdmUg YSBoaWdoIGRlZ3JlZSBvZiBjb25maWRlbmNlIHRoYXQgdGhlaXIgc3lzdGVtIHdpbGwgdHJ1bHkg YmUgc2VjdXJlLiAgTW9yZW92ZXIgaXQgd2lsbCBiZSBlYXNpZXIgdG8gcHJvdmlkZSBzZWN1cmUg aW50ZXJmYWNlcyB0byBvdGhlciBzeXN0ZW0gbW9kdWxlcyBhbmQgY29tcG9uZW50cywgd2hpY2gg YXJlIG1vcmUgbGlrZWx5IHRvIHN1cHBvcnQgc3RhbmRhcmQgc2VjdXJpdHkgcHJvdG9jb2xzIHdp dGhvdXQgc3BlY2lhbCBwdXJwb3NlIGNvZGluZy4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpSZWdhcmRzLA0K Q2hhcmxpZSBQLg0KDQo8RmlndXJlIDggdGVybWlub2xvZ3kuRUZYPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxwLXdhbiBtYWlsaW5nIGxpc3QNCmxw LXdhbkBpZXRmLm9yZzxtYWlsdG86bHAtd2FuQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9scC13YW4NCg== --_000_BB09947B5326FE42BA3918FA28765C2ED2D79BDGGEMM506MBSchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi57qv 5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrn uq/mlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8gZm9sa3Ms PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdpdGgg Q2hhcmxpZSBhbmQgUGF0cmljayBXZXR0ZXJ3YWxkIHRoYXQgV2ktU1VOIEZBTiB1c2VzIHNvbWUg ZGlmZmVyZW50IHRlcm1pbm9sb2dpZXMgYW5kIHNob3VsZCBiZSBpbGx1c3RyYXRlZCBhcyBhIGNv bHVtbiBpbiBGaWd1cmUuOA0KIG9mIHRoZSBMUFdBTiBvdmVydmlldyBkcmFmdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgbWVudGlvbmVkIGJ5IFBhdHJpY2sgS2lubmV5 LCB0aGUgcGFja2V0IHNpemUgb2YgV2ktU1VOIGNhbiBhbHNvIGJlIGluY2x1ZGVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZW15PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBQYXQua2lubmV5QGtpbm5leWNvbnN1bHRpbmdsbGMuY29tIFttYWlsdG86cGF0 Lmtpbm5leUBraW5uZXljb25zdWx0aW5nbGxjLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgSnVseSAyMCwgMjAxNyAzOjEwIEFNPGJyPg0KPGI+VG86PC9iPiBDaGFybGllIFBlcmtp bnM8YnI+DQo8Yj5DYzo8L2I+IGxwLXdhbjsgQm9iIEhlaWxlOyBaaGFuZ21pbmd1aSAoTWFydGlu KTsgSm9uYXRoYW4gTXXDsW96OyBMaXViaW5nIChSZW15KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW2xwLXdhbl0gQ29tbWVudHMgdG8gdGhlIFtscHdhbl0gT3ZlcnZpZXcgcmU6IFdpLVNVTiBj aGFyYWN0ZXJpc3RpY3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ WW91IHJhaXNlZCBzb21lIHZlcnkgZ29vZCBwb2ludHMgYWJvdXQgV2ktU1VOLCBDaGFybGllLiAm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UGVyaGFw cyBhbm90aGVyIHBvaW50IGNvdWxkIGJlIHRoZSBhYmlsaXR5IHRvIGNoYW5nZSB0aGUgUEhZIGNo YXJhY3RlcmlzdGljcyBzdWNoIGFzIG1vZHVsYXRpb25zLCBwYWNrZXQgc2l6ZSwgb3IgRkVDOyBv ciBjaGFuZ2Ugb3V0IHRoZSB3aG9sZSBQSFkgZm9yIGEgZGlmZmVyZW50IGJhbmQuPGJyPg0KPGJy Pg0KUGF0cmljayBLaW5uZXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPktpbm5leSBDb25zdWx0aW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiYjNDM7MS44NDcuOTYwLjM3MTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0ibWFpbHRvOnBhdC5raW5uZXlAa2lubmV5Y29uc3VsdGluZ2xsYy5jb20iPnBhdC5raW5u ZXlAa2lubmV5Y29uc3VsdGluZ2xsYy5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpPbiBKdWwgMTgsIDIwMTcsIGF0 IDIzOjA3LCBDaGFybGllIFBlcmtpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpjaGFybGVzLnBlcmtp bnNAZWFydGhsaW5rLm5ldCI+Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5I ZWxsbyBmb2xrcyw8YnI+DQo8YnI+DQpJJ2QgbGlrZSB0byBzdWdnZXN0IHNvbWUgYWRkaXRpb25h bCB0ZXh0IHRvIGJlIGluY2x1ZGVkIGluIHRoZSBXaS1TVU4gb3ZlcnZpZXcgc2VjdGlvbiBvZiB0 aGUgZG9jdW1lbnQuJm5ic3A7IEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGVtcGhhc2l6ZSB0 aGUgZm9sbG93aW5nIGNoYXJhY3RlcmlzdGljcy4mbmJzcDsgVGhlc2UgY29tbWVudHMgY2FuIGJl IHZpZXdlZCBhcyBtb3JlIG9yIGxlc3MgdGhlIGRpc3RpbGxhdGlvbiBvZiBpbmZvcm1hdGlvbiBk ZXNjcmliZWQNCiBhdCBsb25nZXIgbGVuZ3RoIGluIG91ciBpbmRpdmlkdWFsIEludGVybmV0IERy YWZ0IGNvbnRyaWJ1dGlvbiBzdWJtaXR0ZWQgZWFybGllciBhYm91dCBXaS1TVU4uJm5ic3A7IFdl IGhhdmUgcmVjZWl2ZWQgbWFueSBjb21tZW50cyBhYm91dCB0aGF0IGRyYWZ0LCBhbmQgaXQgbmVl ZHMgdG8gYmUgc2lnbmlmaWNhbnRseSByZXZpc2VkIGFuZCByZXN1Ym1pdHRlZCBhcyBzb29uIGFz IHBvc3NpYmxlLiZuYnNwOyBCdXQgdGhlIFtscHdhbl0gT3ZlcnZpZXcgZG9jdW1lbnQNCiBpcyBp biBMYXN0IENhbGwsIGFuZCB3ZSBkb24ndCBoYXZlIHRpbWUgdG8gcmV2aXNlIG91ciBpbmRpdmlk dWFsIGRyYWZ0IGJlZm9yZSB0aGUgZW5kIG9mIExhc3QgQ2FsbC48YnI+DQo8YnI+DQpHaXZlbiBh IGxpdHRsZSBtb3JlIHRpbWUgYWZ0ZXIgdGhpcyBidXN5IHdlZWssIEkgd291bGQgYWxzbyBsaWtl IHRvIGluY2x1ZGUgYSBmdWxsZXIgZGVzY3JpcHRpb24gYWJvdXQgdGhlIFdpLVNVTiBtZXNoIHBy b3RvY29sIGNob2ljZXMuJm5ic3A7IElmIHRoYXQgaXMgYWNjZXB0YWJsZSwgSSB3aWxsIHByb3Zp ZGUgdGV4dCBuZXh0IHdlZWsuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpDaGFybGllIFAuPGJy Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPi1Db3ZlcmFnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgcmFuZ2Ugb2YgV2ktU1VOIEZBTiBp cyB0eXBpY2FsbHkgMn4zIGttIGluIGxpbmUgb2Ygc2lnaHQsIG1hdGNoaW5nIHRoZSBuZWVkcyBv ZiBuZWlnaGJvcmhvb2QgYXJlYSBuZXR3b3JrcywgY2FtcHVzIGFyZWEgbmV0d29ya3MsIG9yIGNv cnBvcmF0ZSBhcmVhIG5ldHdvcmtzLiBUaGUgcmFuZ2UgY2FuIGFsc28gYmUgZXh0ZW5kZWQgdmlh IG11bHRpLWhvcCBuZXR3b3JraW5nLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIEhpZ2gg YmFuZHdpZHRoLCBsb3cgbGF0ZW5jeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaS1TVU4ncyByZWxhdGl2ZWx5IGhpZ2gg YmFuZHdpZHRoLCBpLmUuIHVwIHRvIDMwMCBrYnBzIFtGQU5UUFNdLCBlbmFibGVzIHJlbW90ZSB1 cGRhdGUgYW5kIHVwZ3JhZGUgb2YgZGV2aWNlcyBzbyB0aGF0IHRoZXkgY2FuIGhhbmRsZSBuZXcg YXBwbGljYXRpb25zLCBleHRlbmRpbmcgdGhlaXIgd29ya2luZyBsaWZlLiBTb21lIElvVCBhcHBs aWNhdGlvbnMgbWF5IHJlcXVpcmUNCiBvbi1kZW1hbmQgY29udHJvbCwgZS5nLiBvbi1kZW1hbmQg bWV0ZXJpbmcgaW4gQU1JLCBkZXZpY2UgY29udHJvbCBpbiBkaXN0cmlidXRpb24gYXV0b21hdGlv bi4gV2ktU1VOIHN1cHBvcnRzIHRoZXNlIHJlcXVpcmVtZW50cyBieSBwcm92aWRpbmcgaGlnaCBi YW5kd2lkdGgsIGxvdyBsYXRlbmN5ICgwLjAycykgYW5kIGJpLWRpcmVjdGlvbmFsIGNvbW11bmlj YXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gTG93IHBvd2VyIGNvbnN1bXB0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZBTiBkZXZpY2VzIGRyYXcgbGVzcyB0aGFuIDIgdUEgd2hlbiByZXN0aW5nIGFu ZCBvbmx5IDggbUEgd2hlbiBsaXN0ZW5pbmcgW0NPTV0uIFN1Y2ggZGV2aWNlcyBjYW4gbWFpbnRh aW4gYSBsb25nIGxpZmV0aW1lIGV2ZW4gaWYgdGhleSBhcmUgZnJlcXVlbnRseSBsaXN0ZW5pbmcu IEZvciBpbnN0YW5jZSwgc3VwcG9zZSB0aGUgZGV2aWNlIHRyYW5zbWl0cyBkYXRhIGZvcg0KIDEw IG1zIG9uY2UgZXZlcnkgMTAgczsgdGhlb3JldGljYWxseSwgYSBiYXR0ZXJ5IG9mIDEwMDAgbUFo IGNhbiBsYXN0IG1vcmUgdGhhbiAxMCB5ZWFycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0g TWVzaCB0b3BvbG9neTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5XaS1TVU4gRkFOIG1lc2ggbmV0d29ya3Mgb2ZmZXIgc2Vs Zi1mb3JtaW5nIGFuZCBzZWxmLWhlYWxpbmcgY2FwYWJpbGl0aWVzLiBXaGVuIGEgbmV3IGRldmlj ZSBpcyBwb3dlcmVkIHVwLCBpdCBjYW4gYXV0b21hdGljYWxseSBkaXNjb3ZlciBjb21tdW5pY2F0 aW9uIHBlZXJzLiBJZiB0aGUgbGluayBpcyBpbnRlcnJ1cHRlZCBieSBvYnN0YWNsZXMsIGEgZGV2 aWNlIGNhbiBzd2l0Y2gNCiB0byBhbHRlcm5hdGl2ZSByZWR1bmRhbnQgcGF0aHMuIFRoZSByZWxp YWJpbGl0eSBvZiBXaS1TVU4gaGFzIGJlZW4gcHJvdmVuIGZvciB5ZWFycyBpbiBoYXJzaCBhbmQg cmVtb3RlIGVudmlyb25tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gU2NhbGFiaWxp dHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+MTBzIG9mIG1pbGxpb25zIFdpLVNVTiBGQU4gZGV2aWNlcyBoYXZlIGJlZW4g ZGVwbG95ZWQgYWxsIG92ZXIgdGhlIHdvcmxkLCBpbmNsdWRpbmcgc2V2ZXJhbCBkZXBsb3ltZW50 cyB3aXRoIG1vcmUgdGhhbiAxIG1pbGxpb24gZGV2aWNlcyBbQ09NXS4gVGhpcyBkZW1vbnN0cmF0 ZXMgdGhlIHNjYWxhYmlsaXR5IG9mIFdpLVNVTiBGQU4gaW4gdXJiYW4sIHN1YnVyYmFuIGFuZA0K IHJ1cmFsIGVudmlyb25tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgZm9sbG93aW5nIHJlZmVyZW5jZXMgY291bGQgYmUgYWRkZWQgaW4gdGhl IExQV0FOIG92ZXJ2aWV3IGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5bQ09NXSBXaS1TVU4gQWxsaWFuY2UsIDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PkNvbXBhcmluZyBJb1QgTmV0d29ya3MgYXQgYSBHbGFuY2U8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+4oCdPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4sDQogTWF5IDIwMTcuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPltGQU5UUFNdIFdpLVNVTiBBbGxpYW5jZSwgJnF1b3Q7VGVjaG5pY2FsIFByb2ZpbGUgU3Bl Y2lmaWNhdGlvbiBGaWVsZCBBcmVhIE5ldHdvcmsmcXVvdDssIE1heSAyMDE2LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+RmlndXJlLjggbmVlZHMgYSBjb2x1bW4gZm9yIFdpLVNVTjo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jmx0O2ltYWdlMDAxLnBuZyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFub3RoZXIg cGFyYWdyYXBoIGNvdWxkIGJlIGFkZGVkIHJlZ2FyZGluZyB0aGUgV2ktU1VOIHNlY3VyaXR5IHNv bHV0aW9uLCBzb21ldGhpbmcgYWxvbmcgdGhlIGZvbGxvd2luZyBsaW5lcy4mbmJzcDsNCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPldpLVNVTiBoYXMgbWFkZSBpdCBhIGRlc2lnbiBnb2FsIHRvIHJl bHkgb24gaW5kdXN0cnkgc3RhbmRhcmQgc2VjdXJpdHkgc29sdXRpb25zIGluc3RlYWQgb2Ygc3Bl Y2lhbC1wdXJwb3NlIG9yIHByb3ByaWV0YXJ5IG1ldGhvZHMuJm5ic3A7IEluIHRoaXMgd2F5LCB1 c2VycyBhbmQgZXF1aXBtZW50IHZlbmRvcnMgY2FuIGhhdmUgYSBoaWdoIGRlZ3JlZSBvZiBjb25m aWRlbmNlIHRoYXQNCiB0aGVpciBzeXN0ZW0gd2lsbCB0cnVseSBiZSBzZWN1cmUuJm5ic3A7IE1v cmVvdmVyIGl0IHdpbGwgYmUgZWFzaWVyIHRvIHByb3ZpZGUgc2VjdXJlIGludGVyZmFjZXMgdG8g b3RoZXIgc3lzdGVtIG1vZHVsZXMgYW5kIGNvbXBvbmVudHMsIHdoaWNoIGFyZSBtb3JlIGxpa2Vs eSB0byBzdXBwb3J0IHN0YW5kYXJkIHNlY3VyaXR5IHByb3RvY29scyB3aXRob3V0IHNwZWNpYWwg cHVycG9zZSBjb2RpbmcuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPlJlZ2FyZHMsPGJyPg0KQ2hhcmxpZSBQLjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZs dDtGaWd1cmUgOCB0ZXJtaW5vbG9neS5FRlgmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpscC13YW4gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmxwLXdhbkBp ZXRmLm9yZyI+bHAtd2FuQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbHAtd2FuIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xwLXdhbjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BB09947B5326FE42BA3918FA28765C2ED2D79BDGGEMM506MBSchina_-- From nobody Thu Jul 20 00:30:00 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 28682126B72 for ; Thu, 20 Jul 2017 00:29:59 -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 1U2yAqzqc9S5 for ; Thu, 20 Jul 2017 00:29:56 -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 4FAE7126557 for ; Thu, 20 Jul 2017 00:29:56 -0700 (PDT) Received: from [IPv6:2001:67c:1232:144:e40e:9672:7f3a:b731] (unknown [IPv6:2001:67c:1232:144:e40e:9672:7f3a:b731]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 31B4BA8100; Thu, 20 Jul 2017 09:29:52 +0200 (CEST) From: Alexander Pelov Message-Id: <28167D32-774A-47B5-9A2B-026CBB2ED873@ackl.io> Content-Type: multipart/alternative; boundary="Apple-Mail=_534A9EAD-98C6-407B-AC27-40747784FEC3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Jul 2017 09:29:56 +0200 In-Reply-To: Cc: "Patrick Wetterwald (pwetterw)" , Charlie Perkins , lp-wan , Bob Heile , =?utf-8?Q?Jonathan_Mu=C3=B1oz?= To: "Liubing (Remy)" References: <6f22c5a9-60f6-3995-f8e5-79f0443ff748@earthlink.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN characteristics 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, 20 Jul 2017 07:29:59 -0000 --Apple-Mail=_534A9EAD-98C6-407B-AC27-40747784FEC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, It seems to me that you have several points that you would wish = emphasize, with the majority of them already present in the current = LPWAN Overview draft. For example, Section 2.4.2 already mentions the = characteristics you wanted to add - mesh network, RPL, MHDS, multi-PHY, = multi-throughput.=20 I=E2=80=99d like to get back to one of the non-goals of the LPWAN = Overview document: provide an extensive description of one of the = baseline technologies. Another non-goal - have a document that gets = constantly updated to reflect the ongoing developments and publications = in these very dynamic technologies.=20 We wanted to have a snapshot that allows to grasp the essential approach = of each of the technologies. If the need is expressed by the individual = technology contributors, then individual, more dynamic, rich, and = up-to-date submissions are welcome. Charlie, Bob and Mingui have now = submitted a dedicated document and it seems the perfect place to be this = venue. The same was done for the other baseline technologies. I think the document reaches these goals. In addition, get the = impression that you are looking to improve the document beyond the point = of our stated non-goals. In this sense, I feel that the current document = covers most (if not all) of your editorial requests. I think that with = the following minor modifications we can strike the right balance = between our goals and avoiding the non-goals: - Check references with updated ones - Add reference to the draft-heile-lpwan-wisun-overview-00 document - Add column with WI-SUN terminology Does that sound reasonable to you? Alexander > Le 20 juil. 2017 =C3=A0 04:08, Liubing (Remy) = a =C3=A9crit : >=20 > Hello folks, > I agree with Charlie and Patrick Wetterwald that Wi-SUN FAN uses some = different terminologies and should be illustrated as a column in = Figure.8 of the LPWAN overview draft. > =20 > As mentioned by Patrick Kinney, the packet size of Wi-SUN can also be = included. > =20 > Best regards, > Remy > From: Pat.kinney@kinneyconsultingllc.com = [mailto:pat.kinney@kinneyconsultingllc.com]=20 > Sent: Thursday, July 20, 2017 3:10 AM > To: Charlie Perkins > Cc: lp-wan; Bob Heile; Zhangmingui (Martin); Jonathan Mu=C3=B1oz; = Liubing (Remy) > Subject: Re: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN = characteristics > =20 > You raised some very good points about Wi-SUN, Charlie. =20 > Perhaps another point could be the ability to change the PHY = characteristics such as modulations, packet size, or FEC; or change out = the whole PHY for a different band. >=20 > Patrick Kinney > Kinney Consulting > +1.847.960.3715 > pat.kinney@kinneyconsultingllc.com = >=20 > On Jul 18, 2017, at 23:07, Charlie Perkins = > = wrote: >=20 > =20 > Hello folks, >=20 > I'd like to suggest some additional text to be included in the Wi-SUN = overview section of the document. I think it is important to emphasize = the following characteristics. These comments can be viewed as more or = less the distillation of information described at longer length in our = individual Internet Draft contribution submitted earlier about Wi-SUN. = We have received many comments about that draft, and it needs to be = significantly revised and resubmitted as soon as possible. But the = [lpwan] Overview document is in Last Call, and we don't have time to = revise our individual draft before the end of Last Call. >=20 > Given a little more time after this busy week, I would also like to = include a fuller description about the Wi-SUN mesh protocol choices. If = that is acceptable, I will provide text next week. >=20 > Regards, > Charlie P. > = --------------------------------------------------------------------------= --------------------------------- > -Coverage >=20 > The range of Wi-SUN FAN is typically 2~3 km in line of sight, matching = the needs of neighborhood area networks, campus area networks, or = corporate area networks. The range can also be extended via multi-hop = networking. >=20 > =20 >=20 > - High bandwidth, low latency >=20 > Wi-SUN's relatively high bandwidth, i.e. up to 300 kbps [FANTPS], = enables remote update and upgrade of devices so that they can handle new = applications, extending their working life. Some IoT applications may = require on-demand control, e.g. on-demand metering in AMI, device = control in distribution automation. Wi-SUN supports these requirements = by providing high bandwidth, low latency (0.02s) and bi-directional = communication. >=20 > =20 >=20 > - Low power consumption >=20 > FAN devices draw less than 2 uA when resting and only 8 mA when = listening [COM]. Such devices can maintain a long lifetime even if they = are frequently listening. For instance, suppose the device transmits = data for 10 ms once every 10 s; theoretically, a battery of 1000 mAh can = last more than 10 years. >=20 > =20 >=20 > - Mesh topology >=20 > Wi-SUN FAN mesh networks offer self-forming and self-healing = capabilities. When a new device is powered up, it can automatically = discover communication peers. If the link is interrupted by obstacles, a = device can switch to alternative redundant paths. The reliability of = Wi-SUN has been proven for years in harsh and remote environments. >=20 > =20 >=20 > - Scalability >=20 > 10s of millions Wi-SUN FAN devices have been deployed all over the = world, including several deployments with more than 1 million devices = [COM]. This demonstrates the scalability of Wi-SUN FAN in urban, = suburban and rural environments. >=20 >=20 >=20 >=20 > =20 >=20 > The following references could be added in the LPWAN overview draft: >=20 > [COM] Wi-SUN Alliance, =E2=80=9CComparing IoT Networks at a Glance=E2=80= =9D, May 2017. >=20 > [FANTPS] Wi-SUN Alliance, "Technical Profile Specification Field Area = Network", May 2016. >=20 > =20 >=20 > Figure.8 needs a column for Wi-SUN: >=20 > >=20 > =20 >=20 > Another paragraph could be added regarding the Wi-SUN security = solution, something along the following lines. =20 >=20 >=20 > Wi-SUN has made it a design goal to rely on industry standard security = solutions instead of special-purpose or proprietary methods. In this = way, users and equipment vendors can have a high degree of confidence = that their system will truly be secure. Moreover it will be easier to = provide secure interfaces to other system modules and components, which = are more likely to support standard security protocols without special = purpose coding. >=20 >=20 > = --------------------------------------------------------------------------= ------------------------------------------------ >=20 > Regards, > Charlie P. >=20 >=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 --Apple-Mail=_534A9EAD-98C6-407B-AC27-40747784FEC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

It seems to me that you have several points that you would = wish emphasize, with the majority of them already present in the current = LPWAN Overview draft. For example, Section 2.4.2 already mentions the = characteristics you wanted to add - mesh network, RPL, MHDS, multi-PHY, = multi-throughput. 

I=E2=80=99d like to get back to one of the non-goals of the = LPWAN Overview document: provide an extensive description of one of the = baseline technologies. Another non-goal - have a document that gets = constantly updated to reflect the ongoing developments and publications = in these very dynamic technologies. 

We wanted to have a snapshot that = allows to grasp the essential approach of each of the technologies. If = the need is expressed by the individual technology contributors, then = individual, more dynamic, rich, and up-to-date submissions are welcome. = Charlie, Bob and Mingui have now submitted a dedicated document and = it seems the perfect place to be this venue. The same was done for the = other baseline technologies.

I think the document reaches these = goals. In addition, get the impression that you are looking to improve = the document beyond the point of our stated non-goals. In this sense, I = feel that the current document covers most (if not all) of your = editorial requests. I think that with the following minor modifications = we can strike the right balance between our goals and avoiding the = non-goals:
- Check references with updated = ones
- Add reference to = the draft-heile-lpwan-wisun-overview-00 document
- Add column with WI-SUN terminology

Does that sound reasonable to = you?

Alexander



Le 20 juil. 2017 =C3=A0 04:08, Liubing (Remy) <remy.liubing@huawei.com> a =C3=A9crit :

Hello = folks,
I agree with = Charlie and Patrick Wetterwald that Wi-SUN FAN uses some different = terminologies and should be illustrated as a column in Figure.8 of the = LPWAN overview draft.
 
As mentioned = by Patrick Kinney, the packet size of Wi-SUN can also be included.
 
Best = regards,
Remy
From: Pat.kinney@kinneyconsultingllc.com [mailto:pat.kinney@kinneyconsultingllc.com] 
Sent: Thursday, July 20, 2017 = 3:10 AM
To: Charlie Perkins
Cc: lp-wan; Bob Heile; = Zhangmingui (Martin); Jonathan Mu=C3=B1oz; Liubing (Remy)
Subject: Re: [lp-wan] Comments to = the [lpwan] Overview re: Wi-SUN characteristics
 
You raised some very good = points about Wi-SUN, Charlie.  
Perhaps another point could = be the ability to change the PHY characteristics such as modulations, = packet size, or FEC; or change out the whole PHY for a different = band.

Patrick Kinney
Kinney Consulting
+1.847.960.3715
pat.kinney@kinneyconsultingllc.com


On Jul 18, 2017, at 23:07, Charlie Perkins <charles.perkins@earthlink.net> wrote:

 
Hello = folks,

I'd like to suggest some additional = text to be included in the Wi-SUN overview section of the = document.  I think it is important to emphasize the following = characteristics.  These comments can be viewed as more or less the = distillation of information described at longer length in our individual = Internet Draft contribution submitted earlier about Wi-SUN.  We = have received many comments about that draft, and it needs to be = significantly revised and resubmitted as soon as possible.  But the = [lpwan] Overview document is in Last Call, and we don't have time to = revise our individual draft before the end of Last Call.
Given a little more time after this busy week, I would also = like to include a fuller description about the Wi-SUN mesh protocol = choices.  If that is acceptable, I will provide text next week.

Regards,
Charlie P.
---------------------------------------------------------------= --------------------------------------------

-Coverage

The range of Wi-SUN FAN is typically 2~3 km in line of sight, = matching the needs of neighborhood area networks, campus area networks, = or corporate area networks. The range can also be extended via multi-hop = networking.

 

- High bandwidth, low latency

Wi-SUN's= relatively high bandwidth, i.e. up to 300 kbps [FANTPS], enables remote = update and upgrade of devices so that they can handle new applications, = extending their working life. Some IoT applications may require = on-demand control, e.g. on-demand metering in AMI, device control in = distribution automation. Wi-SUN supports these requirements by providing = high bandwidth, low latency (0.02s) and bi-directional = communication.

 

- Low power consumption

FAN devices draw less than 2 uA when resting and only 8 mA = when listening [COM]. Such devices can maintain a long lifetime even if = they are frequently listening. For instance, suppose the device = transmits data for 10 ms once every 10 s; theoretically, a battery of = 1000 mAh can last more than 10 years.

 

- Mesh topology

Wi-SUN FAN mesh networks offer self-forming and self-healing = capabilities. When a new device is powered up, it can automatically = discover communication peers. If the link is interrupted by obstacles, a = device can switch to alternative redundant paths. The reliability of = Wi-SUN has been proven for years in harsh and remote environments.

 

- Scalability

10s of millions Wi-SUN FAN devices have been deployed all = over the world, including several deployments with more than 1 million = devices [COM]. This demonstrates the scalability of Wi-SUN FAN in urban, = suburban and rural environments.



 

The following references could be added in the LPWAN overview = draft:

[COM] = Wi-SUN Alliance, =E2=80=9CComparing IoT Networks at a = Glance=E2=80=9D, May = 2017.

[FANTPS]= Wi-SUN Alliance, "Technical Profile Specification Field Area Network", = May 2016.

 

Figure.8 needs a column for Wi-SUN:

<image001.png>

 

Another paragraph could be added regarding the Wi-SUN = security solution, something along the following lines.  

Wi-SUN has made it a design goal to rely on industry standard = security solutions instead of special-purpose or proprietary = methods.  In this way, users and equipment vendors can have a high = degree of confidence that their system will truly be secure.  = Moreover it will be easier to provide secure interfaces to other system = modules and components, which are more likely to support standard = security protocols without special purpose coding.

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

Regards,
Charlie P.

<Figure 8 terminology.EFX>
_______________________________________________
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=_534A9EAD-98C6-407B-AC27-40747784FEC3-- From nobody Thu Jul 20 07:45: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 50C9A131CAE for ; Thu, 20 Jul 2017 07:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 hDxmJoyYs9ZR for ; Thu, 20 Jul 2017 07:45:19 -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 79062131CB0 for ; Thu, 20 Jul 2017 07:45:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91CCCBE2F; Thu, 20 Jul 2017 15:45:17 +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 1jOP3U9MIety; Thu, 20 Jul 2017 15:45:14 +0100 (IST) Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 132CBBE4C; Thu, 20 Jul 2017 15:45:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500561914; bh=Ou449FGFH0UlVF9WNRCthghfGQBvIW4X8vZLLZCQPp8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hIXNGs7wEDQrQWI5IvjY2iD2ks6Xjr9vs01Lk4jj15fZ7jIdaYjpEaF1jlvWrf/Sx r2tEmsVzo5JzQ7uSUR+Qc0fwLt6M/+dGVIAO6+1XblviAZxfIEI5INMO+vfE2RXLFM OgdCcxfcbOaPT9Z7NQUs1EIc4Sp1OZmUe9KGAHWs= To: "Liubing (Remy)" , "Patrick Wetterwald (pwetterw)" , Charlie Perkins , lp-wan Cc: Bob Heile , =?UTF-8?Q?Jonathan_Mu=c3=b1oz?= References: <6f22c5a9-60f6-3995-f8e5-79f0443ff748@earthlink.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <32b76082-a4b4-08b7-4f37-63c8b41c2246@cs.tcd.ie> Date: Thu, 20 Jul 2017 15:45:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="obOpKsc33S4UBtpj51AVv7q4LHL7XrK1h" Archived-At: Subject: Re: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN characteristics 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, 20 Jul 2017 14:45:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --obOpKsc33S4UBtpj51AVv7q4LHL7XrK1h Content-Type: multipart/mixed; boundary="eRImeQjgPHqkvtw5i0wfHKo659L0est4n"; protected-headers="v1" From: Stephen Farrell To: "Liubing (Remy)" , "Patrick Wetterwald (pwetterw)" , Charlie Perkins , lp-wan Cc: Bob Heile , =?UTF-8?Q?Jonathan_Mu=c3=b1oz?= Message-ID: <32b76082-a4b4-08b7-4f37-63c8b41c2246@cs.tcd.ie> Subject: Re: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN characteristics References: <6f22c5a9-60f6-3995-f8e5-79f0443ff748@earthlink.net> In-Reply-To: --eRImeQjgPHqkvtw5i0wfHKo659L0est4n Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi all, Charlie Perkins has kindly offered to send me some text suggestions for these various comments wrt Wi-SUN. My assumption is that those will cover the various comments received on the list in the last few days. Once I have those I'll post a -05 and we can go from there. AFAIK, those are all editorial changes so hopefully won't affect the WGLC for this draft. (But will of course need checking.) As we know, this is a busy week for folks so I'm not sure if Charlie will get that done today for the usual understandable reasons. Cheers, S. On 20/07/17 03:08, Liubing (Remy) wrote: > Hello folks, > I agree with Charlie and Patrick Wetterwald that Wi-SUN FAN uses some d= ifferent terminologies and should be illustrated as a column in Figure.8 = of the LPWAN overview draft. >=20 > As mentioned by Patrick Kinney, the packet size of Wi-SUN can also be i= ncluded. >=20 > Best regards, > Remy > From: Pat.kinney@kinneyconsultingllc.com [mailto:pat.kinney@kinneyconsu= ltingllc.com] > Sent: Thursday, July 20, 2017 3:10 AM > To: Charlie Perkins > Cc: lp-wan; Bob Heile; Zhangmingui (Martin); Jonathan Mu=C3=B1oz; Liubi= ng (Remy) > Subject: Re: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN chara= cteristics >=20 > You raised some very good points about Wi-SUN, Charlie. > Perhaps another point could be the ability to change the PHY characteri= stics such as modulations, packet size, or FEC; or change out the whole P= HY for a different band. >=20 > Patrick Kinney > Kinney Consulting > +1.847.960.3715 > pat.kinney@kinneyconsultingllc.com >=20 > On Jul 18, 2017, at 23:07, Charlie Perkins > wrote: >=20 > Hello folks, >=20 > I'd like to suggest some additional text to be included in the Wi-SUN o= verview section of the document. I think it is important to emphasize th= e following characteristics. These comments can be viewed as more or les= s the distillation of information described at longer length in our indiv= idual Internet Draft contribution submitted earlier about Wi-SUN. We hav= e received many comments about that draft, and it needs to be significant= ly revised and resubmitted as soon as possible. But the [lpwan] Overview= document is in Last Call, and we don't have time to revise our individua= l draft before the end of Last Call. >=20 > Given a little more time after this busy week, I would also like to inc= lude a fuller description about the Wi-SUN mesh protocol choices. If tha= t is acceptable, I will provide text next week. >=20 > Regards, > Charlie P. > -----------------------------------------------------------------------= ------------------------------------ >=20 > -Coverage >=20 > The range of Wi-SUN FAN is typically 2~3 km in line of sight, matching = the needs of neighborhood area networks, campus area networks, or corpora= te area networks. The range can also be extended via multi-hop networking= =2E >=20 >=20 >=20 > - High bandwidth, low latency >=20 > Wi-SUN's relatively high bandwidth, i.e. up to 300 kbps [FANTPS], enabl= es remote update and upgrade of devices so that they can handle new appli= cations, extending their working life. Some IoT applications may require = on-demand control, e.g. on-demand metering in AMI, device control in dist= ribution automation. Wi-SUN supports these requirements by providing high= bandwidth, low latency (0.02s) and bi-directional communication. >=20 >=20 >=20 > - Low power consumption >=20 > FAN devices draw less than 2 uA when resting and only 8 mA when listeni= ng [COM]. Such devices can maintain a long lifetime even if they are freq= uently listening. For instance, suppose the device transmits data for 10 = ms once every 10 s; theoretically, a battery of 1000 mAh can last more th= an 10 years. >=20 >=20 >=20 > - Mesh topology >=20 > Wi-SUN FAN mesh networks offer self-forming and self-healing capabiliti= es. When a new device is powered up, it can automatically discover commun= ication peers. If the link is interrupted by obstacles, a device can swit= ch to alternative redundant paths. The reliability of Wi-SUN has been pro= ven for years in harsh and remote environments. >=20 >=20 >=20 > - Scalability >=20 > 10s of millions Wi-SUN FAN devices have been deployed all over the worl= d, including several deployments with more than 1 million devices [COM]. = This demonstrates the scalability of Wi-SUN FAN in urban, suburban and ru= ral environments. >=20 >=20 >=20 >=20 >=20 > The following references could be added in the LPWAN overview draft: >=20 > [COM] Wi-SUN Alliance, =E2=80=9CComparing IoT Networks at a Glance=E2=80= =9D, May 2017. >=20 > [FANTPS] Wi-SUN Alliance, "Technical Profile Specification Field Area N= etwork", May 2016. >=20 >=20 >=20 > Figure.8 needs a column for Wi-SUN: >=20 > >=20 >=20 >=20 > Another paragraph could be added regarding the Wi-SUN security solution= , something along the following lines. >=20 >=20 > Wi-SUN has made it a design goal to rely on industry standard security = solutions instead of special-purpose or proprietary methods. In this way= , users and equipment vendors can have a high degree of confidence that t= heir system will truly be secure. Moreover it will be easier to provide = secure interfaces to other system modules and components, which are more = likely to support standard security protocols without special purpose cod= ing. >=20 >=20 > -----------------------------------------------------------------------= --------------------------------------------------- >=20 > Regards, > Charlie P. >=20 >
> _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >=20 >=20 >=20 > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan >=20 --eRImeQjgPHqkvtw5i0wfHKo659L0est4n-- --obOpKsc33S4UBtpj51AVv7q4LHL7XrK1h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZcMH3AAoJEC88hzaAX42iXLgH+gISk3bYi/nLLfU6ZgFNP20j ar+bjuk2eJvWgppmUMTcLOolE9LfI93ywToaS87Bj9dIU0amgA9JLQ9X0pwbnFjb uS193ZsTQV6DcZzK6cHgvfx/hb/VKGEQU2yGJk/4cikCNAMEVa72CCE0O+pCRKy6 DhhOo4edV8hk4GYySXoxaTyw0wBS9uXyJpmh/XBBGaWgYjcXDi7AcLadx7M2OUP8 Q/QDId4zS3o+KE0hAkM8MlH63rpOJujcHFss+auz9aE00X2AR6UwXNJLF/Qgxx8H H5zdcdXsHnfcuSP1ul4YBUa163v0y+BBNdXwUvUSovVqyoyRlJ5EgGkptEtqVFs= =YD5j -----END PGP SIGNATURE----- --obOpKsc33S4UBtpj51AVv7q4LHL7XrK1h-- From nobody Thu Jul 20 07:48: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 0285C131CD9 for ; Thu, 20 Jul 2017 07:48:52 -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 TBBzPxukx_SV for ; Thu, 20 Jul 2017 07:48:49 -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 9445C131CDA for ; Thu, 20 Jul 2017 07:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6812; q=dns/txt; s=iport; t=1500562129; x=1501771729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1BS1aiYu8OxCjj5bC28hpCj6Vs1A7+2krTpUVgvY4iU=; b=UhGDWG0e/AJS1s7JbCleAqJsHAc9BQmGmiPXHfdoTvneY3EhD3QJ4HY+ GcVndGLphdZLkAVortJasXD7xd4huRFeVUtDKgteYNlcKaNSi4Ie/BevJ Oa5RGnPWvFFR4D9ops/ofYElwUqkKOOEGIxQWL+k1+oJJqGiNUnC57zOJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAABjwnBZ/4ENJK1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZIEUjguRaJYFghEhC4UbAoN0PxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBAQFsCwULAgEIEQQBAQEnBycLFAkIAgQOBRkCiXwDDQgQtCWLJAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgyiDTYFhK4J5gleBXAcWGiEXD4J8gjEFiV2VYQK?= =?us-ascii?q?KSolOggyQKIlIh1qEOwEfOIEKdRVJEgGHA3aJegEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,384,1496102400"; d="scan'208";a="458630274" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2017 14:48:25 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6KEmPwb015242 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2017 14:48:25 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Jul 2017 09:48:24 -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, 20 Jul 2017 09:48:24 -0500 From: "Pascal Thubert (pthubert)" To: Stephen Farrell CC: "Liubing (Remy)" , "Patrick Wetterwald (pwetterw)" , Charlie Perkins , lp-wan , Bob Heile , =?Windows-1252?Q?Jonathan_Mu=F1oz?= Thread-Topic: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN characteristics Thread-Index: AQHTAWbWeQZQ/9iDz0aN7UIwC8l7JqJcy63u Date: Thu, 20 Jul 2017 14:48:24 +0000 Message-ID: References: <6f22c5a9-60f6-3995-f8e5-79f0443ff748@earthlink.net> , <32b76082-a4b4-08b7-4f37-63c8b41c2246@cs.tcd.ie> In-Reply-To: <32b76082-a4b4-08b7-4f37-63c8b41c2246@cs.tcd.ie> 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: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN characteristics 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, 20 Jul 2017 14:48:52 -0000 I'm used to get the impossible from Charlie so let's see : ) we have most o= f the text on the ML already... if Charlie makes it, it would be ideal to b= e able to announce during the meeting tomorrow that the doc is published an= d ready for shipping ! Regards, Pascal > Le 20 juil. 2017 =E0 16:45, Stephen Farrell a= =E9crit : >=20 >=20 > Hi all, >=20 > Charlie Perkins has kindly offered to send me some text suggestions > for these various comments wrt Wi-SUN. My assumption is that those > will cover the various comments received on the list in the last few > days. Once I have those I'll post a -05 and we can go from there. > AFAIK, those are all editorial changes so hopefully won't affect the > WGLC for this draft. (But will of course need checking.) >=20 > As we know, this is a busy week for folks so I'm not sure if > Charlie will get that done today for the usual understandable > reasons. >=20 > Cheers, > S. >=20 >> On 20/07/17 03:08, Liubing (Remy) wrote: >> Hello folks, >> I agree with Charlie and Patrick Wetterwald that Wi-SUN FAN uses some di= fferent terminologies and should be illustrated as a column in Figure.8 of = the LPWAN overview draft. >>=20 >> As mentioned by Patrick Kinney, the packet size of Wi-SUN can also be in= cluded. >>=20 >> Best regards, >> Remy >> From: Pat.kinney@kinneyconsultingllc.com [mailto:pat.kinney@kinneyconsul= tingllc.com] >> Sent: Thursday, July 20, 2017 3:10 AM >> To: Charlie Perkins >> Cc: lp-wan; Bob Heile; Zhangmingui (Martin); Jonathan Mu=F1oz; Liubing (= Remy) >> Subject: Re: [lp-wan] Comments to the [lpwan] Overview re: Wi-SUN charac= teristics >>=20 >> You raised some very good points about Wi-SUN, Charlie. >> Perhaps another point could be the ability to change the PHY characteris= tics such as modulations, packet size, or FEC; or change out the whole PHY = for a different band. >>=20 >> Patrick Kinney >> Kinney Consulting >> +1.847.960.3715 >> pat.kinney@kinneyconsultingllc.com >>=20 >> On Jul 18, 2017, at 23:07, Charlie Perkins > wrote: >>=20 >> Hello folks, >>=20 >> I'd like to suggest some additional text to be included in the Wi-SUN ov= erview section of the document. I think it is important to emphasize the f= ollowing characteristics. These comments can be viewed as more or less the= distillation of information described at longer length in our individual I= nternet Draft contribution submitted earlier about Wi-SUN. We have receive= d many comments about that draft, and it needs to be significantly revised = and resubmitted as soon as possible. But the [lpwan] Overview document is = in Last Call, and we don't have time to revise our individual draft before = the end of Last Call. >>=20 >> Given a little more time after this busy week, I would also like to incl= ude a fuller description about the Wi-SUN mesh protocol choices. If that i= s acceptable, I will provide text next week. >>=20 >> Regards, >> Charlie P. >> ------------------------------------------------------------------------= ----------------------------------- >>=20 >> -Coverage >>=20 >> The range of Wi-SUN FAN is typically 2~3 km in line of sight, matching t= he needs of neighborhood area networks, campus area networks, or corporate = area networks. The range can also be extended via multi-hop networking. >>=20 >>=20 >>=20 >> - High bandwidth, low latency >>=20 >> Wi-SUN's relatively high bandwidth, i.e. up to 300 kbps [FANTPS], enable= s remote update and upgrade of devices so that they can handle new applicat= ions, extending their working life. Some IoT applications may require on-de= mand control, e.g. on-demand metering in AMI, device control in distributio= n automation. Wi-SUN supports these requirements by providing high bandwidt= h, low latency (0.02s) and bi-directional communication. >>=20 >>=20 >>=20 >> - Low power consumption >>=20 >> FAN devices draw less than 2 uA when resting and only 8 mA when listenin= g [COM]. Such devices can maintain a long lifetime even if they are frequen= tly listening. For instance, suppose the device transmits data for 10 ms on= ce every 10 s; theoretically, a battery of 1000 mAh can last more than 10 y= ears. >>=20 >>=20 >>=20 >> - Mesh topology >>=20 >> Wi-SUN FAN mesh networks offer self-forming and self-healing capabilitie= s. When a new device is powered up, it can automatically discover communica= tion peers. If the link is interrupted by obstacles, a device can switch to= alternative redundant paths. The reliability of Wi-SUN has been proven for= years in harsh and remote environments. >>=20 >>=20 >>=20 >> - Scalability >>=20 >> 10s of millions Wi-SUN FAN devices have been deployed all over the world= , including several deployments with more than 1 million devices [COM]. Thi= s demonstrates the scalability of Wi-SUN FAN in urban, suburban and rural e= nvironments. >>=20 >>=20 >>=20 >>=20 >>=20 >> The following references could be added in the LPWAN overview draft: >>=20 >> [COM] Wi-SUN Alliance, =93Comparing IoT Networks at a Glance=94, May 201= 7. >>=20 >> [FANTPS] Wi-SUN Alliance, "Technical Profile Specification Field Area Ne= twork", May 2016. >>=20 >>=20 >>=20 >> Figure.8 needs a column for Wi-SUN: >>=20 >> >>=20 >>=20 >>=20 >> Another paragraph could be added regarding the Wi-SUN security solution,= something along the following lines. >>=20 >>=20 >> Wi-SUN has made it a design goal to rely on industry standard security s= olutions instead of special-purpose or proprietary methods. In this way, u= sers and equipment vendors can have a high degree of confidence that their = system will truly be secure. Moreover it will be easier to provide secure = interfaces to other system modules and components, which are more likely to= support standard security protocols without special purpose coding. >>=20 >>=20 >> ------------------------------------------------------------------------= -------------------------------------------------- >>=20 >> Regards, >> Charlie P. >>=20 >>
>> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >>=20 >>=20 >>=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 From nobody Fri Jul 21 00:46: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 772BB129A92; Fri, 21 Jul 2017 00:46:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lp-wan@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150062320244.11213.13558054475220785033@ietfa.amsl.com> Date: Fri, 21 Jul 2017 00:46:42 -0700 Archived-At: Subject: [lp-wan] I-D Action: draft-ietf-lpwan-overview-06.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, 21 Jul 2017 07:46: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 WG of the IETF. Title : LPWAN Overview Author : Stephen Farrell Filename : draft-ietf-lpwan-overview-06.txt Pages : 41 Date : 2017-07-21 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-overview-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 25 00:56: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 43A8712EA95; Tue, 25 Jul 2017 00:56:29 -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 eF7v0cmoJDgt; Tue, 25 Jul 2017 00:56:27 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BCB127978; Tue, 25 Jul 2017 00:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3095; q=dns/txt; s=iport; t=1500969387; x=1502178987; h=from:to:cc:subject:date:message-id:mime-version; bh=59oOlF+lJK70sLN9MzYBqjR18sNr2hQ7+cVQjj1gGyA=; b=M5Jb6+ZjfaJADt0pNoIL9KxqJKPA8zLpQMyDHdtDAdSEhXsLrjPMUpU8 3NvcjdSv+RfaHaviMhcVc9gfzJrDVtkdNwgRUje4qFDrP2BXt7ujYxZLD uoaRTfhj1mac67p5e5LqrFeB8LPM5VVLZoEzNh4ICALcEGemn5Jmbgeb4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DdAAC9+HZZ/4gNJK1dARkBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJva2SBG44FokKFLA6CBCyFG4NxPxgBAgEBAQEBAQFrHQuFTEwSAQx?= =?us-ascii?q?0JgEEDg2JQ2QQsnOLSQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiDTYlChioFn?= =?us-ascii?q?1YCh0yMR4IVhVCKXZVoAR84gQp3FYdiiUuBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,410,1496102400"; d="scan'208,217";a="460198977" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2017 07:56:26 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6P7uQH8024775 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2017 07:56:26 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Jul 2017 02:56:26 -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, 25 Jul 2017 02:56:26 -0500 From: "Pascal Thubert (pthubert)" To: "lp-wan@ietf.org" CC: "lpwan-chairs@ietf.org" Thread-Topic: Minutes, LPWAN WG, IETF 99 Thread-Index: AdMFG0qZmez/yJatQRyt9DkfevS1eg== Date: Tue, 25 Jul 2017 07:56:23 +0000 Deferred-Delivery: Tue, 25 Jul 2017 07:56:01 +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.61.76.57] Content-Type: multipart/alternative; boundary="_000_bd3e0f8fe89748cca2ea774842eecd02XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [lp-wan] Minutes, LPWAN WG, IETF 99 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, 25 Jul 2017 07:56:29 -0000 --_000_bd3e0f8fe89748cca2ea774842eecd02XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear LPWANers: We published the minutes of the LPWAN WG meeting at https://datatracker.iet= f.org/meeting/99/session/lpwan/. Those minutes are not final, please let the chairs know if changes should b= e made. Cheers Alexander and Pascal --_000_bd3e0f8fe89748cca2ea774842eecd02XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear LPWANers:

 

We published the minutes of the LPWAN WG meeting at&= nbsp;htt= ps://datatracker.ietf.org/meeting/99/session/lpwan/.

 

Those minutes are not final, please let the chairs k= now if changes should be made.

 

Cheers

 

Alexander and Pascal

 

--_000_bd3e0f8fe89748cca2ea774842eecd02XCHRCD001ciscocom_-- From nobody Fri Jul 28 03:03: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 8019313217D for ; Fri, 28 Jul 2017 03:03:46 -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 yC8Yxt0FSnxv for ; Fri, 28 Jul 2017 03:03:44 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B78612EA95 for ; Fri, 28 Jul 2017 03:03:43 -0700 (PDT) Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1142D1720A3 for ; Fri, 28 Jul 2017 12:03:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id U9HHiTLPbY0h for ; Fri, 28 Jul 2017 12:03:40 +0200 (CEST) X-Originating-IP: 213.174.99.130 Received: from [10.221.4.234] (smb-adpcdg1-02.hotspot.hub-one.net [213.174.99.130]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 6ADF01720CF for ; Fri, 28 Jul 2017 12:03:40 +0200 (CEST) From: Alexander Pelov Content-Type: multipart/alternative; boundary="Apple-Mail=_EF76005D-F98A-400F-9966-268D08D79C0A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <2330CAEF-B595-491A-9BA7-C7891E0BB14B@ackl.io> Date: Fri, 28 Jul 2017 12:03:38 +0200 To: lp-wan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [lp-wan] Next interim meetings - time schedule 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, 28 Jul 2017 10:03:46 -0000 --Apple-Mail=_EF76005D-F98A-400F-9966-268D08D79C0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, Following the IETF99 meeting, we have some final tasks to go through = with our current items, as well as prepare the new things to be included = in our future work. We=E2=80=99d like to restart our Interim Meetings, every second week, = starting from August, 21st. (approx 3 weeks from now). In order to avoid LoRa Alliance and Wi-SUN collisions, we=E2=80=99d like = to move the meeting slot to Mondays, 17h-18h CEST ( 8AM-9AM PDT ; = 11AM-12PM EDT )*. Do you have any strong indications against this time slot? Pascal and Alexander * Timezones can be seen here: = https://www.worldtimebuddy.com/?qm=3D1&lid=3D2988507,1816670,5391959,51285= 81&h=3D2988507&date=3D2017-8-21&sln=3D17-18 = --Apple-Mail=_EF76005D-F98A-400F-9966-268D08D79C0A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

Following the IETF99 = meeting, we have some final tasks to go through with our current items, = as well as prepare the new things to be included in our future work.

We=E2=80=99d like to restart our Interim = Meetings, every second week, starting from August, 21st. (approx 3 weeks = from now).

In order to avoid LoRa Alliance = and Wi-SUN collisions, we=E2=80=99d like to move the meeting slot to = Mondays, 17h-18h CEST ( 8AM-9AM PDT ; 11AM-12PM EDT )*.

Do you have any strong indications against this time slot?

Pascal and Alexander


* Timezones can be seen here:
https://www.worldtimebuddy.com/?qm=3D1&lid=3D2988507,181667= 0,5391959,5128581&h=3D2988507&date=3D2017-8-21&sln=3D17-18=
= --Apple-Mail=_EF76005D-F98A-400F-9966-268D08D79C0A-- From nobody Fri Jul 28 14:47: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 152951321B1 for ; Fri, 28 Jul 2017 14:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky9gtxZOFIOJ for ; Fri, 28 Jul 2017 14:47:22 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c: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 6AEF7131CCA for ; Fri, 28 Jul 2017 14:47:22 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id t201so6280359wmt.0 for ; Fri, 28 Jul 2017 14:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=bHXf4ruAQNxw97gTAC72upm2g9d+xfmzRwkMMcnHTbA=; b=FuxvAfglWfKnySUxgC1nj+svFSwiE2xZAkRs0turEU01D1s8op8sA3nwHA/FDXjMKM MMhODaKWR1s1RcgCSy6kJ2Rcn44ZE6Kju1+ns+Psm/XmX55Z8GXUYN7IPGOPpcEom6+H Rw634aW1NPNjkTQrISf+9lPR83nfn9O/Pg9RxftMW8+ZZogQElKZ2PNAtcK1CEDGXxec GIms1ZQJY1NQhqBO+h7M1BJBVR1owFWEMhn3Ur4Xh5M3iFJbO85tmQngvodhbs3sbZ0O hEeSLkmh5UOF9qvBM+CObLWerj6a+g+sg3EvSK6+Ne95mUcSsClav+/LpLVBbAJI03uY bItQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc; bh=bHXf4ruAQNxw97gTAC72upm2g9d+xfmzRwkMMcnHTbA=; b=Rg2AhV5T0H2CSEFrpu34t6oyVgu+h3sWvNTAjQbW1/Me7HTdiWLaffQh+fsCMrR544 Hn9coR1b8J7K1wd/gcKEqHHHebj39mkuqIDYtn/fYeigKwRMfD73X8wWdY1E9zFu8gkq 2I4VOgroVed4USNS0hn+tS7FnODHN/qydfKtjlG7gLxRcCVIfRL2oKPAaJv/uNjsr7tk L1+uUpxShVSRk6NZxSvVj/+WQji93S45KPPkXacR1kLwPlgdFoVkqqrLiZlnp0ni2Y2S DzsfHKSKoWPKA+eTYbwdzlgI/PLOGV0Tc2Lzzy3tgOBUDwXFu/bImyeRxICq/KXjW+nz EUSA== X-Gm-Message-State: AIVw1118rumAt6NHKD+YApAGjIxozBFs/ByT9sRWLN0+G1fh2SORJR9w gzHyqSq/cAs1HDCNoIVqQxnKMDfoMA== X-Received: by 10.28.71.5 with SMTP id u5mr7100038wma.138.1501278440894; Fri, 28 Jul 2017 14:47:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.212 with HTTP; Fri, 28 Jul 2017 14:47:20 -0700 (PDT) Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Fri, 28 Jul 2017 16:47:20 -0500 Message-ID: To: Stephen Farrell Cc: lp-wan Content-Type: multipart/alternative; boundary="94eb2c0720fc2db81c055567a0d2" Archived-At: Subject: [lp-wan] Review of draft-ietf-lpwan-overview-06.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: Fri, 28 Jul 2017 21:47:25 -0000 --94eb2c0720fc2db81c055567a0d2 Content-Type: text/plain; charset="UTF-8" Hi all, Here are my comments after reading the overview document: page 4. LoRaWAN acronym? page 8. NwkID in Table 3, is it supposed to be NetID? p.9 DevEUI and AppEUI I think they refer to the device and the application MAC addresses in 64-bits p. 13 The 3GPP radio protocol architecture is illustration in Figure 4 s/illustration/illustrated control plane protocol stack and data plane protocol stack section numbering is missing p.14 EPC not defined Fig. 1, Fig. 7 refer to non-3GPP architectures which means LoRaWAN, SIGFOX and Wi-SUN are basically IEEE 802.15.4 type of technologies? Regarding battery life, referred to on Page 11 for NB-IoT and p.15 for SIGFOX, p.21 for Wi_SUN, if these technologies are used to connect devices like refrigerators which are almost always powered up, why long term battery life is an issue? On the other hand the use on the pets is a different issue. Regards, Behcet On Fri, Jul 21, 2017 at 2:46 AM, wrote: > > 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 WG > of the IETF. > > Title : LPWAN Overview > Author : Stephen Farrell > Filename : draft-ietf-lpwan-overview-06.txt > Pages : 41 > Date : 2017-07-21 > > 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-06 > https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-overview-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > --94eb2c0720fc2db81c055567a0d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Here are my comments after reading the ove= rview document:
page 4.
LoRaWAN acronym?
page 8.
NwkID in Table 3, is it supposed to be NetID?
=
p.9
DevEUI and AppEUI
I think they refer t= o the device and the application MAC addresses
in 64-bits
=
p. 13
The 3GPP radio protocol architecture is illustration in Figu= re 4
s/illustration/illustrated

control plane protoco= l stack and data plane protocol stack section numbering is missing
p.14
EPC not defined
Fig. 1, Fig. 7 refer to non-3GPP ar= chitectures which means LoRaWAN, SIGFOX and Wi-SUN are basically IEEE 802.1= 5.4 type of technologies?

Regarding battery life, referred to = on Page 11 for NB-IoT and p.15 for SIGFOX, p.21 for Wi_SUN,
if the= se technologies are used to connect devices like refrigerators which are al= most always powered up, why long term battery life is an issue?
On= the other hand the use on the pets is a different issue.

Rega= rds,

Behcet
On Fri, Jul 21, 2017 at 2:46 AM, <internet-drafts@ietf.org<= /a>> wrote:
=
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IPv6 over Low Power Wide-Area Networks WG = of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= LPWAN Overview
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Step= hen Farrell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-lpwan-overview-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 41
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-07-21

Abstract:
=C2=A0 =C2=A0Low Power Wide Area Networks (LPWAN) are wireless technologies= with
=C2=A0 =C2=A0characteristics such as large coverage areas, low bandwidth, p= ossibly
=C2=A0 =C2=A0very small packet and application layer data sizes and long ba= ttery
=C2=A0 =C2=A0life operation.=C2=A0 This memo is an informational overview o= f the set of
=C2=A0 =C2=A0LPWAN technologies being considered in the IETF and of the gap= s that
=C2=A0 =C2=A0exist between the needs of those technologies and the goal of = running
=C2=A0 =C2=A0IP in LPWANs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-lpwan-overview/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-= lpwan-overview-06
https://datatracker.ietf.org/= doc/html/draft-ietf-lpwan-overview-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-lpwan-overview-06


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

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

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

--94eb2c0720fc2db81c055567a0d2-- From nobody Fri Jul 28 15:17: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 608AD1321C7 for ; Fri, 28 Jul 2017 15:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWOe2KfanJaD for ; Fri, 28 Jul 2017 15:17:08 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 4A9E2132159 for ; Fri, 28 Jul 2017 15:17:06 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id m85so127320299wma.1 for ; Fri, 28 Jul 2017 15:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kYt580bci7cyyjvbGuTeoCLJnOokrwzQqdDMQGRLwj4=; b=Dqxra1VKprP0obHuKPAvEDZchOZDsgRKruklbULaDr3dfC0CIjLujW9ToCiqpaQM5d 5u/yED7Z7XXhSrIF0F9sftQw/71vB0UT0bx3Zjlst5KGSuoGTwFt5ydxgP1Ao7p1vE2k rj5aR2Vrd9NsWTW5Ususk7l1PPp7Z6cOsE0DmTtCwtKzTJXJ/tcujQctzt6/12pJRjk0 UtPVcn2jg2ftHF0E6CvK5fOH/IOqHeJpTicogsylVRFd9gSRg2RYV2jgX+7RHtvpX9uS Xfus8LHSHLl6RGF6Q4YOUrejnXaK3TPm3E3RNJT75aRpKLPYpq5D7LZ7SFEQjY1Oqxk1 3ZBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=kYt580bci7cyyjvbGuTeoCLJnOokrwzQqdDMQGRLwj4=; b=fbRrWWAIotd5y8tUT1Vdor7XiR/mtMHjPJXw+goSV1HP6bWzFAc5eR7RKwEv9Nugpj ul8ePFlJWLrRBxva2UfITQZdRg3k+YzVF++HMxCynsGqkJVfi0O6afUnl4XIOWIm7JCU FCBQut+HmJ02ZMeJTqgPxIDtejrDMUpD8FHr8wW4qlIMkNLotj6KyJ/YbffBVSX0HZT6 DH3kemnig3hsAWq5w2toyo+NszwBczKaHbPMgIIeJkoFZQfXmFZu4lptkDZ9GV/v/Q8m 2jkE19X8ia1dJ841ZGBFj1MZmHwH9bAhMqcqtMXeHUsaZHmcg/NoO0pG+E7fkgixR83O 73Og== X-Gm-Message-State: AIVw110UiM+VNUJObdL5cVCTwuSZYQNk3JVuHemPOwumQ3HoD/tvHkcF S2mVpbosNDlOrHHAbCXnKT5NsrNF+Q== X-Received: by 10.28.71.5 with SMTP id u5mr7139622wma.138.1501280224721; Fri, 28 Jul 2017 15:17:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.212 with HTTP; Fri, 28 Jul 2017 15:17:04 -0700 (PDT) Reply-To: sarikaya@ieee.org In-Reply-To: References: From: Behcet Sarikaya Date: Fri, 28 Jul 2017 17:17:04 -0500 Message-ID: To: Stephen Farrell Cc: lp-wan Content-Type: multipart/alternative; boundary="94eb2c0720fc80c1560555680a8f" Archived-At: Subject: Re: [lp-wan] Review of draft-ietf-lpwan-overview-06.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: Fri, 28 Jul 2017 22:17:11 -0000 --94eb2c0720fc80c1560555680a8f Content-Type: text/plain; charset="UTF-8" More comments: p.13 & p.24 P-GW is packet data network gateway it is not application server, the classification in Fig. 8 seems to be correct. Maybe more comments on Section 4 later on. On Fri, Jul 28, 2017 at 4:47 PM, Behcet Sarikaya wrote: > Hi all, > > Here are my comments after reading the overview document: > page 4. > LoRaWAN acronym? > page 8. > NwkID in Table 3, is it supposed to be NetID? > p.9 > DevEUI and AppEUI > I think they refer to the device and the application MAC addresses > in 64-bits > p. 13 > The 3GPP radio protocol architecture is illustration in Figure 4 > s/illustration/illustrated > > control plane protocol stack and data plane protocol stack section > numbering is missing > p.14 > EPC not defined > Fig. 1, Fig. 7 refer to non-3GPP architectures which means LoRaWAN, SIGFOX > and Wi-SUN are basically IEEE 802.15.4 type of technologies? > > Regarding battery life, referred to on Page 11 for NB-IoT and p.15 for > SIGFOX, p.21 for Wi_SUN, > if these technologies are used to connect devices like refrigerators which > are almost always powered up, why long term battery life is an issue? > On the other hand the use on the pets is a different issue. > > Regards, > > Behcet > On Fri, Jul 21, 2017 at 2:46 AM, wrote: > >> >> 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 >> WG of the IETF. >> >> Title : LPWAN Overview >> Author : Stephen Farrell >> Filename : draft-ietf-lpwan-overview-06.txt >> Pages : 41 >> Date : 2017-07-21 >> >> 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-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-overview-06 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >> > > --94eb2c0720fc80c1560555680a8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
More comments:
p.13 & p.2= 4
P-GW is packet data network gateway
it is not applicati= on server, the classification in Fig. 8 seems to be correct.

M= aybe more comments on Section 4 later on.



On Fri, J= ul 28, 2017 at 4:47 PM, Behcet Sarikaya <sarikaya2012@gmail.com&g= t; wrote:
Hi all,
<= br>
Here are my comments after reading the overview document:
page 4.
LoRaWAN acronym?
page 8.
NwkI= D in Table 3, is it supposed to be NetID?
p.9
D= evEUI and AppEUI
I think they refer to the device and the app= lication MAC addresses
in 64-bits
p. 13
The 3GPP = radio protocol architecture is illustration in Figure 4
s/illustra= tion/illustrated

control plane protocol stack and data plane p= rotocol stack section numbering is missing
p.14
EPC not d= efined
Fig. 1, Fig. 7 refer to non-3GPP architectures which means = LoRaWAN, SIGFOX and Wi-SUN are basically IEEE 802.15.4 type of technologies= ?

Regarding battery life, referred to on Page 11 for NB-IoT an= d p.15 for SIGFOX, p.21 for Wi_SUN,
if these technologies are used= to connect devices like refrigerators which are almost always powered up, = why long term battery life is an issue?
On the other hand the use = on the pets is a different issue.

Regards,

Behcet=
<= div>
On Fri, Jul 21, 2= 017 at 2:46 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IPv6 over Low Power Wide-Area Networks WG = of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= LPWAN Overview
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Step= hen Farrell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-lpwan-overview-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 41
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-07-21

Abstract:
=C2=A0 =C2=A0Low Power Wide Area Networks (LPWAN) are wireless technologies= with
=C2=A0 =C2=A0characteristics such as large coverage areas, low bandwidth, p= ossibly
=C2=A0 =C2=A0very small packet and application layer data sizes and long ba= ttery
=C2=A0 =C2=A0life operation.=C2=A0 This memo is an informational overview o= f the set of
=C2=A0 =C2=A0LPWAN technologies being considered in the IETF and of the gap= s that
=C2=A0 =C2=A0exist between the needs of those technologies and the goal of = running
=C2=A0 =C2=A0IP in LPWANs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-lpwan-overview/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-= lpwan-overview-06
https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-lpwan-overview-06


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

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

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


--94eb2c0720fc80c1560555680a8f-- From nobody Mon Jul 31 14:40: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 0B4E61327DA for ; Mon, 31 Jul 2017 14:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K_2HvL_gwsH for ; Mon, 31 Jul 2017 14:40:23 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 355701327D2 for ; Mon, 31 Jul 2017 14:40:23 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id t201so1844846wmt.0 for ; Mon, 31 Jul 2017 14:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=x8SvKHwWRfka86Lhtx0RjW2L3juUFgDdZfdNvU2MX6c=; b=IjRoDqPQk9NyhfoEYV8z4FfN1XM36xNaAkvg0DjA4Igswp9mMHoAyCVeO1J3hmNDHS t8QTVdzAb1mAEMZyz1qF1NFWhbHSwkCYhiT3bZam9XrUnu9yQXuyP9xAFN9i0qfkO7PO K8FJq04OxmfVyWhJJAK4EMYEzOucqnRTWSuH0V3p+CndeE3Qc4yM/lPqUFpb9rkKNQkf DppYgZZiJh9oIYwySQc1gN37TiZL5KFv3dUrF18CryZM4Qk2FTItNRXeBB/CbgHpp/b4 yXSS3nT4SucV1QjD5p2M7ojAUh8rJGy7QSJ79OCVCwgaw0YqY8TxbaDhoWy2R1ZjKg7u pWmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc; bh=x8SvKHwWRfka86Lhtx0RjW2L3juUFgDdZfdNvU2MX6c=; b=ZOMUD6TKfGR25s5B8ylKHc7osZ+lXHLlUnm22FLI7ZF4reoL8aUdaQbGDuJ3b//nRw OCx0RZAZ4dhA8WfnD9RbheE+s/9vn0pLe1QxdlZjnrWl6HKKOAwugmiA2LlQEKWzUnCe 7BNRumVG/Te+dIbpoY+Lj+iSMCq6lImMlwtNLnCyaODRLssSFvuoQn6cHeS6oPN/j3eF 6O0kfM6ouqooOYgnbp2cKm9WN0osQuyWoFi/yLbmyQuSV1ARDi7exnzWd2EGpxjU7rFd xJCz8I2rHTPgkHAIIDQ8ctiHVndAkzBne95KUfNa7yEyHqycNK1gW/G5eBDnZczV7qmh 7MQA== X-Gm-Message-State: AIVw112ymyxJ/Ceoug5FHeEcXD5H8kJVNrZJ6PX8TzfN/QEuJF1sASLv XTEOQ+uWHIXJFS9ju2w3cIt3EJH7aA== X-Received: by 10.28.25.71 with SMTP id 68mr13017169wmz.76.1501537221658; Mon, 31 Jul 2017 14:40:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.212 with HTTP; Mon, 31 Jul 2017 14:40:21 -0700 (PDT) Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Mon, 31 Jul 2017 16:40:21 -0500 Message-ID: To: Stephen Farrell Cc: lp-wan Content-Type: multipart/alternative; boundary="001a114d3c84b6cda50555a3e0f3" Archived-At: Subject: Re: [lp-wan] Review of draft-ietf-lpwan-overview-06.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: Mon, 31 Jul 2017 21:40:26 -0000 --001a114d3c84b6cda50555a3e0f3 Content-Type: text/plain; charset="UTF-8" Comments on Section 4: p.28 Valid Lifetime in the 6CO it should be 6LoWPAN Context Option p.30 s/LPWANs nodes/LPWAN nodes p.31 staple OCSP responses Online Certificate Status Protocol (OCSP) p.30 section 4.8 second paragraph: add the use of a gateway with LTE uplink as a mobility solution. On Fri, Jul 28, 2017 at 5:17 PM, Behcet Sarikaya wrote: > More comments: > p.13 & p.24 > P-GW is packet data network gateway > it is not application server, the classification in Fig. 8 seems to be > correct. > > Maybe more comments on Section 4 later on. > > > > > On Fri, Jul 28, 2017 at 4:47 PM, Behcet Sarikaya > wrote: > >> Hi all, >> >> Here are my comments after reading the overview document: >> page 4. >> LoRaWAN acronym? >> page 8. >> NwkID in Table 3, is it supposed to be NetID? >> p.9 >> DevEUI and AppEUI >> I think they refer to the device and the application MAC addresses >> in 64-bits >> p. 13 >> The 3GPP radio protocol architecture is illustration in Figure 4 >> s/illustration/illustrated >> >> control plane protocol stack and data plane protocol stack section >> numbering is missing >> p.14 >> EPC not defined >> Fig. 1, Fig. 7 refer to non-3GPP architectures which means LoRaWAN, >> SIGFOX and Wi-SUN are basically IEEE 802.15.4 type of technologies? >> >> Regarding battery life, referred to on Page 11 for NB-IoT and p.15 for >> SIGFOX, p.21 for Wi_SUN, >> if these technologies are used to connect devices like refrigerators >> which are almost always powered up, why long term battery life is an issue? >> On the other hand the use on the pets is a different issue. >> >> Regards, >> >> Behcet >> On Fri, Jul 21, 2017 at 2:46 AM, wrote: >> >>> >>> 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 >>> WG of the IETF. >>> >>> Title : LPWAN Overview >>> Author : Stephen Farrell >>> Filename : draft-ietf-lpwan-overview-06.txt >>> Pages : 41 >>> Date : 2017-07-21 >>> >>> 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-06 >>> https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-06 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-overview-06 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> lp-wan mailing list >>> lp-wan@ietf.org >>> https://www.ietf.org/mailman/listinfo/lp-wan >>> >> >> > --001a114d3c84b6cda50555a3e0f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments on Section 4:
p.28
Va= lid Lifetime in the 6CO it should be 
6LoWPAN Context Option
p.30
s/LPWANs nodes/LPWAN= nodes
p.31
staple OCSP responses
Online Certificate Status
   Protocol (OCSP)
p.30 section 4.8 s= econd paragraph:
add the use of a gatew= ay with LTE uplink as a mobility solution.



On Fri, Jul 28, 2017 at 5:17 PM, Behcet Sarikaya <sarikaya2012@gmail= .com> wrote:
More comments:
p.13 &= ; p.24
P-GW is packet data network gateway
it is not appl= ication server, the classification in Fig. 8 seems to be correct.

Maybe more comments on Section 4 later on.
=



On Fri, Jul 28, 2017 at 4:47 PM, Behcet Sarikaya <= span dir=3D"ltr"><sarikaya2012@gmail.com> wrote:
Hi all,

Here are my c= omments after reading the overview document:
page 4.
LoRaWAN acronym?
page 8.
NwkID in Table 3, is it su= pposed to be NetID?
p.9
DevEUI and AppEUI
I think they refer to the device and the application MAC addresses=
in 64-bits
p. 13
The 3GPP radio protocol archite= cture is illustration in Figure 4
s/illustration/illustrated
control plane protocol stack and data plane protocol stack section = numbering is missing
p.14
EPC not defined
Fig. 1= , Fig. 7 refer to non-3GPP architectures which means LoRaWAN, SIGFOX and Wi= -SUN are basically IEEE 802.15.4 type of technologies?

Regardi= ng battery life, referred to on Page 11 for NB-IoT and p.15 for SIGFOX, p.2= 1 for Wi_SUN,
if these technologies are used to connect devices li= ke refrigerators which are almost always powered up, why long term battery = life is an issue?
On the other hand the use on the pets is a diffe= rent issue.

Regards,

Behcet
On Fri, Jul 21, 2017 at 2:46 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IPv6 over Low Power Wide-Area Networks WG = of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= LPWAN Overview
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Step= hen Farrell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-lpwan-overview-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 41
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-07-21

Abstract:
=C2=A0 =C2=A0Low Power Wide Area Networks (LPWAN) are wireless technologies= with
=C2=A0 =C2=A0characteristics such as large coverage areas, low bandwidth, p= ossibly
=C2=A0 =C2=A0very small packet and application layer data sizes and long ba= ttery
=C2=A0 =C2=A0life operation.=C2=A0 This memo is an informational overview o= f the set of
=C2=A0 =C2=A0LPWAN technologies being considered in the IETF and of the gap= s that
=C2=A0 =C2=A0exist between the needs of those technologies and the goal of = running
=C2=A0 =C2=A0IP in LPWANs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-lpwan-overview/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-= lpwan-overview-06
https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-overview-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-lpwan-overview-06


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

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

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



--001a114d3c84b6cda50555a3e0f3--