Subject: [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview

From: Alexander Pelov <[email-masked]>
Date: Thu, 17 Nov 2016 07:55:14 +0900

Dear all,

(This is the call for adoption for the *LPWAN overview* document.)

During the Monday meeting of the WG, we’ve discussed three main drafts, which address the two items we have in our charter. We’ve had three call for adoption in the room, with clear support for the adoption of the documents. You can find the minutes at the following address: https://datatracker.ietf.org/doc/minutes-97-lpwan/ <https://datatracker.ietf.org/doc/minutes-97-lpwan/>

We are now moving the call for adoption to the mailing list and will be closing the call in two weeks (on December 2nd, 2016).

This is the call for adoption for "LPWAN Overview" draft (draft-farrell-lpwan-overview):
https://datatracker.ietf.org/doc//draft-farrell-lpwan-overview/ <https://datatracker.ietf.org/doc//draft-farrell-lpwan-overview/>

Please read the draft and reply to the list with your comments, remarks, suggestions and votes on the adoption of this document.

Best,
Pascal and Alexander

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 16 Nov 2016 20:31:18 -0300

I agree.
Regards,

           Diego

El nov 16, 2016 7:55 PM, "Alexander Pelov" <[email-masked]> escribió:

> During the Monday meeting of the WG, we’ve discussed three main drafts,
> which address the two items we have in our charter. We’ve had three call
> for adoption in the room, with clear support for the adoption of the
> documents. You can find the minutes at the following address:
> https://datatracker.ietf.org/doc/minutes-97-lpwan/
>
> We are now moving the call for adoption to the mailing list and will be
> closing the call in two weeks (on *December 2nd, 2016*).
>
> https://datatracker.ietf.org/doc//draft-farrell-lpwan-overview/
>
> Please read the draft and reply to the list with your comments, remarks,
> suggestions and votes on the adoption of this document.
>
> Best,
> Pascal and Alexander
>
>
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Thu, 17 Nov 2016 11:15:51 +0900

+1
--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: [email-masked]
#webpage: https://sites.google.com/site/hurryon

> On Nov 17, 2016, at 08:31, Prof. Diego Dujovne <[email-masked]> wrote:
> 
> I agree.
> Regards,
> 
>            Diego
> 
> 
> El nov 16, 2016 7:55 PM, "Alexander Pelov" <[email-masked] <mailto:[email-masked]>> escribió:
> Dear all,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lp-wan <https://www.ietf.org/mailman/listinfo/lp-wan>
>

---

From: Laurent Toutain <[email-masked]>
Date: Thu, 17 Nov 2016 12:56:41 +0900

+1

-- 
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit
:
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
http://class.touta.in
| [email-masked]         | [email-masked]    |
+--------------------------+----------------------------------------+

---

From: <[email-masked]>
Date: Thu, 17 Nov 2016 06:39:58 +0000

I'm in favour of adopting this draft as a WG draft.
Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Thursday 17 November 2016 12:56
À : Alexander Pelov <[email-masked]<mailto:[email-masked]>>
Cc : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : Re: [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview

+1

On Thu, Nov 17, 2016 at 7:55 AM, Alexander Pelov <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

During the Monday meeting of the WG, we’ve discussed three main drafts, which address the two items we have in our charter. We’ve had three call for adoption in the room, with clear support for the adoption of the documents. You can find the minutes at the following address: https://datatracker.ietf.org/doc/minutes-97-lpwan/

Best,
Pascal and Alexander

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan

--
Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit :
| Mob: +33 6 800 75 900    |                                        |
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |  http://class.touta.in
| [email-masked]<mailto:[email-masked]>         | [email-masked]<mailto:[email-masked]>    |
+--------------------------+----------------------------------------+

_________________________________________________________________________________________________________________________

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

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

---

From: Lorenzo Vangelista <[email-masked]>
Date: Thu, 17 Nov 2016 12:18:42 +0100

I agree

Lorenzo Vangelista

> On 16 Nov 2016, at 23:55, Alexander Pelov <[email-masked]> wrote:
> 
> Dear all,
>

---

From: "weigengyu" <[email-masked]>
Date: Mon, 21 Nov 2016 09:50:49 +0800

+1.

And a question needs clarifing: 
All nodes of LP-WAN are the resources to be accessed when working,
or they generat response(s) only after having receied a request. 
That is to say,  the LP-WAN node will not initiat a request, is it?   

Regards,

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

From: Alexander Pelov 
Sent: Thursday, November 17, 2016 6:55 AM
To: lp-wan 
Subject: [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview

Dear all,

Best,
Pascal and Alexander 

--------------------------------------------------------------------------------
_______________________________________________
lp-wan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Laurent Toutain <[email-masked]>
Date: Mon, 21 Nov 2016 14:53:19 +0100

Hi Gengyu,

The model has to be generic enough to support both.

Laurent

On Mon, Nov 21, 2016 at 2:50 AM, weigengyu <[email-masked]> wrote:

> *From:* Alexander Pelov <[email-masked]>
> *Sent:* Thursday, November 17, 2016 6:55 AM
> *To:* lp-wan <[email-masked]>
> *Subject:* [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview
>
> Dear all,
>
> ------------------------------

---

From: Paul Duffy <[email-masked]>
Date: Tue, 22 Nov 2016 16:59:45 -0500

+1 for adoption.

On 11/16/2016 5:55 PM, Alexander Pelov wrote:
> During the Monday meeting of the WG, we’ve discussed three main 
> drafts, which address the two items we have in our charter. We’ve had 
> three call for adoption in the room, with clear support for the 
> adoption of the documents. You can find the minutes at the following 
> address: https://datatracker.ietf.org/doc/minutes-97-lpwan/
>
> We are now moving the call for adoption to the mailing list and will 
> be closing the call in two weeks (on *December 2nd, 2016*).
>
> Please read the draft and reply to the list with your comments, 
> remarks, suggestions and votes on the adoption of this document.
>
> Best,
> Pascal and Alexander
>
>
>

---

From: "Patrick Wetterwald (pwetterw)" <[email-masked]>
Date: Wed, 23 Nov 2016 15:15:03 +0000

Yes for adoption.

Patrick

From: lp-wan <[email-masked]> on behalf of Alexander Pelov <[email-masked]>
Date: Wednesday, 16 November 2016 at 23:55
To: lp-wan <[email-masked]>
Subject: [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview

Dear all,

This is the call for adoption for "LPWAN Overview" draft (draft-farrell-lpwan-overview):
https://datatracker.ietf.org/doc//draft-farrell-lpwan-overview/<https://datatracker.ietf.org/doc/draft-farrell-lpwan-overview/>

Best,
Pascal and Alexander

---

From: Ivan Di Giusto <[email-masked]>
Date: Thu, 24 Nov 2016 13:30:37 +1100

Hi All,

This is a well written summary of different LPWA technologies.

There are a few points that need to be corrected in the LoraWAN section
before the document is adopted.

   1. Page 6 para 1 - Discussion about the smallest frame size is not
   relevant to a lot of regions and may prejudice readers to a limitation that
   does not exist in many cases.  It would be better to discuss the number of
   bytes required for particular types of messages.
   CHANGE FROM
   Note that in the case ...
   TO
   Every LoRaWAN DATA packet consists of a Message Type (1 octet), Frame
   Header (7 octets), Frame Options (optional, from 0 to 15 octets), Frame
   Port (1 octet) and a Message Integrity Check (4 octets), along with a
   variable-length data payload.    Therefore, to send any number of data
   packets, LoRaWAN requires a fixed overhead of 13 octets that are used as
   packet header/integrity check.  Data payload can be up to 242 octets long.
   Local regulations and the choice of data rates may further limit the
   maximum number of data octets.

   Other types of LoRaWAN packets (Join-Request, Join-Response) are of
   fixed length (23 octets and 17 octets, respectively) and are usually used
   once in the lifetime of the device, during initial connection to the
   network.

   The Frame Port field (1 octet) is required when data payload is being
   transported.  Valid values for this octet in the case of data payload are 1
   to 223.

   There is a concept of MAC commands, which are exchanged between the
   Network Server and the device.  Some are initiated by the device, while
   others are initiated by the Network Server.  Their purpose is primarily to
   manage the network parameters (channel frequencies, receive windows, duty
   cycle rules, etc).  Others are used for ADR (Active Data Rate) management
   which allows the Network Server to instruct the device to use a
   higher/lower data rate/transmission power.

   MAC commands can be transferred in two different ways.  Firstly, they
   can be placed inside Frame Options, which can carry up to 15 octets.  In
   this configuration, MAC commands are not encrypted, but are authenticated,
   prevent spoofing attempts.  Secondly, MAC commands can be carried as data
   packet with Frame Port setting of 0.  In this configuration, MAC commands
   are encrypted using the network session key (NwkSKey).

   2. Page 6
   DELETE para 2 as it is incorrect (JOIN procedure does not use ports)
   DELETE para 3-5 as this information is explained in the above text

   3. Page 7 para 4 starting with
   End-devices are assumed to work ...
   SHOULD have the sentence
   This is achievable in many cases ...
   CHANGED TO
   This is called Activation By Personalization (ABP) and programmed into
   the device.  The network server is provided the relevant keys by
   out-of-band means.

   4. Page 8 para 1 that starts with
   As an alternative, end-devices can use the ...
   SHOULD change to
   As an alternative to ABP activation, end-devices can use
   Over-The-Air-Activation (OTAA) join procedure in order to setup some of
   these values and dynamically gain access to the network. To use the OTAA
   join procedure, an end-device must still know the AppEUI, and in addition,
   a different (long-term) symmetric key that is bound to the AppEUI - this is
   the application key (AppKey), and is distinct from the application session
   key (AppSKey).  The AppKey is required to be specific to the device, that
   is, each end-device should have a different AppKey value.  And finally the
   end-device also needs a long-term identifier for itself, syntactically also
   an EUI-64, and known as the device EUI or DevEUI.

Feel free to provide feedback on the recommended changes.

Regards,
Ivan Di Giusto

On 24 November 2016 at 02:15, Patrick Wetterwald (pwetterw) <
[email-masked]> wrote:

> Yes for adoption.
>
>
>
> Patrick
>
>
>
> *From: *lp-wan <[email-masked]> on behalf of Alexander Pelov <
> [email-masked]>
> *Date: *Wednesday, 16 November 2016 at 23:55
> *To: *lp-wan <[email-masked]>
> *Subject: *[lp-wan] Working Group Adoption of draft-farrell-lpwan-overview
>
>
>
> Dear all,
>
>
> <https://datatracker.ietf.org/doc/draft-farrell-lpwan-overview/>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Nov 2016 09:45:18 +0000

Hello Ivan :

Procedurally speaking, It does not appear to me that that these corrections must be applied prior to adoption.
Changing the doc and launching another adoption call would only delay us. Rather, I’d see that a draft-ietf-…- 01 is swiftly produced with those changes in it

Do I miss anything?

Pascal

From: lp-wan [mailto:[email-masked]] On Behalf Of Ivan Di Giusto
Sent: jeudi 24 novembre 2016 03:31
To: lp-wan <[email-masked]>; [email-masked]
Subject: Re: [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview

Hi All,

There are a few points that need to be corrected in the LoraWAN section before the document is adopted.
1.      Page 6 para 1 - Discussion about the smallest frame size is not relevant to a lot of regions and may prejudice readers to a limitation that does not exist in many cases.  It would be better to discuss the number of bytes required for particular types of messages.
CHANGE FROM
Note that in the case ...
TO
Every LoRaWAN DATA packet consists of a Message Type (1 octet), Frame Header (7 octets), Frame Options (optional, from 0 to 15 octets), Frame Port (1 octet) and a Message Integrity Check (4 octets), along with a variable-length data payload.    Therefore, to send any number of data packets, LoRaWAN requires a fixed overhead of 13 octets that are used as packet header/integrity check.  Data payload can be up to 242 octets long.  Local regulations and the choice of data rates may further limit the maximum number of data octets.

Other types of LoRaWAN packets (Join-Request, Join-Response) are of fixed length (23 octets and 17 octets, respectively) and are usually used once in the lifetime of the device, during initial connection to the network.

The Frame Port field (1 octet) is required when data payload is being transported.  Valid values for this octet in the case of data payload are 1 to 223.

There is a concept of MAC commands, which are exchanged between the Network Server and the device.  Some are initiated by the device, while others are initiated by the Network Server.  Their purpose is primarily to manage the network parameters (channel frequencies, receive windows, duty cycle rules, etc).  Others are used for ADR (Active Data Rate) management which allows the Network Server to instruct the device to use a higher/lower data rate/transmission power.

MAC commands can be transferred in two different ways.  Firstly, they can be placed inside Frame Options, which can carry up to 15 octets.  In this configuration, MAC commands are not encrypted, but are authenticated, prevent spoofing attempts.  Secondly, MAC commands can be carried as data packet with Frame Port setting of 0.  In this configuration, MAC commands are encrypted using the network session key (NwkSKey).
2.      Page 6
DELETE para 2 as it is incorrect (JOIN procedure does not use ports)
DELETE para 3-5 as this information is explained in the above text
3.      Page 7 para 4 starting with
End-devices are assumed to work ...
SHOULD have the sentence
This is achievable in many cases ...
CHANGED TO
This is called Activation By Personalization (ABP) and programmed into the device.  The network server is provided the relevant keys by out-of-band means.
4.      Page 8 para 1 that starts with
As an alternative, end-devices can use the ...
SHOULD change to
As an alternative to ABP activation, end-devices can use Over-The-Air-Activation (OTAA) join procedure in order to setup some of these values and dynamically gain access to the network. To use the OTAA join procedure, an end-device must still know the AppEUI, and in addition, a different (long-term) symmetric key that is bound to the AppEUI - this is the application key (AppKey), and is distinct from the application session key (AppSKey).  The AppKey is required to be specific to the device, that is, each end-device should have a different AppKey value.  And finally the end-device also needs a long-term identifier for itself, syntactically also an EUI-64, and known as the device EUI or DevEUI.
Feel free to provide feedback on the recommended changes.

Regards,
Ivan Di Giusto

On 24 November 2016 at 02:15, Patrick Wetterwald (pwetterw) <[email-masked]<mailto:[email-masked]>> wrote:
Yes for adoption.

Patrick

From: lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Alexander Pelov <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 16 November 2016 at 23:55
To: lp-wan <[email-masked]<mailto:[email-masked]>>
Subject: [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview

Dear all,

Best,
Pascal and Alexander

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Nov 2016 12:06:00 +0000

Hiya,

> before the document is adopted.

As Pascal says, fixes can be applied before or after a
filename change. That said...

>    does not exist in many cases. 

I'm not sure what you mean by "regions"? In any case, I do
think the smallest frame size is a limitation that we need
to describe, and not just for LoRaWAN, but for each of the
technologies covered. Figuring out what to say about that
for the other technologies is on my to-do list anyway.

I'll have a look at the suggested changes below and get
back later,
Cheers,
S.

> It would be better to discuss the number of

---

From: Ivan Di Giusto <[email-masked]>
Date: Fri, 25 Nov 2016 15:41:44 +1100

Hi Stephen,

On 24 November 2016 at 23:06, Stephen Farrell <[email-masked]>
wrote:

> I took another look at the table on Page 6 and I am now not sure what it
means.  Is the table saying that the minimum packet size is 59 octets in
EU868?

This number (59 octets) is actually the MAXIMUM frame size IF the device is
transmitting at the slowest data rate.  It is not the minimum packet size,
which is 12 octets (regardless of the data rate used) if no data is being
sent.

One LoRaWAN concept which is a bit different from other LPWA technologies
is the ability to transmit at different data rates.  Because of this, at
really low data rates and depending on the region, maximum frame sizes are
smaller than at faster data rates.

LoRaWAN Regional Parameters document specifies frequencies/data rates/power
levels (among other things) that are to be used in a particular
region/frequency band.  Currently defined band plans are EU868, US915,
CN779, EU443, AU915, CN470, AS923, and KR920.  There will be differences in
allowed packet sizes due to variations in RF regulations from country to
country.  Some countries have duty cycle limitations, others (like the US)
limit transmission time-on-air in the ISM spectrum to 400 ms (for a class
license device).

I realize now where a lot of confusion is coming from.  Unlike data
protocols (IP/TCP/UDP), which are the same regardless of the country in
which they are used, wireless protocols also depend on local regulation.  I
think that WiFi and Bluetooth standards may have made it look like wireless
regulations are the same in all countries.  The regulations between
countries ARE very similar for the 2.4 GHz and 5 GHz bands, which are used
by WiFi and Bluetooth devices.  Local wireless regulations start to diverge
quite a lot when it comes to frequencies used by LPWA technologies like
LoRaWAN and SigFox.

The differences in local wireless regulations create complexity in
understanding aspects of the LoRaWAN standard and how it applies to a
particular region.  I use a word 'region' as many adjacent countries adopt
a similar wireless regulation regime.  For example, majority of European
countries regulate the 868 MHz spectrum the same way, thus it makes sense
to talk about the EU868 region.  Also, Canada and Mexico have the same (or
very similar) rules for the 902-928 MHz spectrum.

Please let me know if I am misunderstanding anything (which is always a
possibility :) ).

---

From: Ivan Di Giusto <[email-masked]>
Date: Fri, 25 Nov 2016 13:01:50 +1100

Hi Pascal,

Now that I realize that changes to the document can be made quickly after
the adoption, I agree that this document should be adopted as-is.

My suggestions for changes can be taken into account after the adoption.

Regards,
Ivan

On 24 November 2016 at 20:45, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Hello Ivan :
>
>
>
> Procedurally speaking, It does not appear to me that that these
> corrections must be applied prior to adoption.
>
> Changing the doc and launching another adoption call would only delay us.
> Rather, I’d see that a draft-ietf-…- 01 is swiftly produced with those
> changes in it
>
>
>
> Do I miss anything?
>
>
>
> Pascal
>
>
>
> *From:* lp-wan [mailto:[email-masked]] *On Behalf Of *Ivan Di
> Giusto
> *Sent:* jeudi 24 novembre 2016 03:31
> *To:* lp-wan <[email-masked]>; [email-masked]
> *Subject:* Re: [lp-wan] Working Group Adoption of
> draft-farrell-lpwan-overview
>
>
>
> Hi All,
>
>
>
> Other types of LoRaWAN packets (Join-Request, Join-Response) are of fixed
> length (23 octets and 17 octets, respectively) and are usually used once in
> the lifetime of the device, during initial connection to the network.
>
> MAC commands can be transferred in two different ways.  Firstly, they can
> be placed inside Frame Options, which can carry up to 15 octets.  In this
> configuration, MAC commands are not encrypted, but are authenticated,
> This is called Activation By Personalization (ABP) and programmed into the
> device.  The network server is provided the relevant keys by out-of-band
> means.
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 25 Nov 2016 09:00:34 +0100

Hi Ivan,

> which is 12 octets (regardless of the data rate used) if no data is being

Agreed, the document should explain that 59 octets is the *minimum L2 MTU*
of LoRaWAN.

(And yes, we need to make sure that the IPv6 MTU requirement of 1280 bytes
is always fulfilled, i.e. also when the L2 MTU is 59 bytes.)

Cheers,

Carles

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 25 Nov 2016 09:42:25 +0100

Hi, 

I believe it’s a very helpful document and I’m in favour of the WG adoption. 

cheers

Jiazi

---

From: "weigengyu" <[email-masked]>
Date: Sun, 27 Nov 2016 00:48:19 +0800

Hi, 

+1 for adotion. 

And there are some questions. 

In Introduction, 
“The goal of the LPWAN WG is to adapt IETF defined protocols, addressing schemes and naming to this particular constrained environment. ”
It is assumed that “addressing schemes “ means IPv6 and “naming” is domain name as specified in “4.9. DNS and LPWAN”, isn’t it? 

By the statement, each LPWAN node is assigned with an IPv6 address and a domain name.  
But, according to typical networks communications are always beween one LPWAN node and an application server. 
That is to say that communications are not beween LPWAN nodes directly.  
In such a situation, DNS name resolution seems not be needed for the LPWAN node.
Right or not?

While relating to “4.9. DNS and LPWAN”,  
one problem is whether a LPWAN node requires to start a name resolution. 
And another problem is whether the LPWAN node requires to process Domain Name in WEB protocol options or contents? 

Regards, 

Gengyu WEI

From: Jiazi Yi 
Sent: Friday, November 25, 2016 4:42 PM
To: Alexander Pelov 
Cc: lp-wan 
Subject: Re: [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview

Hi, 

cheers

Jiazi

  Dear all,

  Best,
  Pascal and Alexander

---

From: Benoit Ponsard <[email-masked]>
Date: Mon, 28 Nov 2016 09:12:16 +0000

+1

my comment will be included in Juan Carlos's forthcoming email.

BR

BPS

De : lp-wan <[email-masked]> au nom de Alexander Pelov <[email-masked]>
Date : mercredi 16 novembre 2016 à 23:55
À : lp-wan <[email-masked]>
Objet : [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview

Dear all,

Best,
Pascal and Alexander

---

From: AUDEBERT Vincent <[email-masked]>
Date: Mon, 28 Nov 2016 09:58:26 +0000

+1

Regards

Vincent

Vincent AUDEBERT
Chef de projet
EDF – R&D Lab Saclay
MIRE
7 Bd Gaspard Monge
91120 PALAISEAU

[email-masked]
Tél. : + 33 1 78 19 45 64
Tél. mobile : + 33 6 14 13 23 22

Un geste simple pour l'environnement, n'imprimez ce message que si vous en avez l'utilité.

De : lp-wan <[email-masked]<mailto:[email-masked]>> au nom de Alexander Pelov <[email-masked]<mailto:[email-masked]>>
Date : mercredi 16 novembre 2016 à 23:55
À : lp-wan <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] Working Group Adoption of draft-farrell-lpwan-overview

Dear all,

Best,
Pascal and Alexander

Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 28 Nov 2016 17:10:24 +0100

+1 for adoption of this document, which will be very useful.
Cheers
Emmanuel