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

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Feb 2017 22:34:48 +0000

Hi Ivan,

I'm working towards a -01 of the WG draft as I said a while
back, so wanted to respond to your comments on the list as
part of that.

I've an editor's copy of what'll end up as -01 at [1], plan
is to publish that as -01 in the next few days.

On 24/11/16 02:30, Ivan Di Giusto wrote:
> 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. 

I still disagree (as I said before) - I do think that this document
ought try identify the worst-case MTU with which IP will have to
live for each of the relevant technologies.

> It would be better to discuss the number of
>    bytes required for particular types of messages.
>    CHANGE FROM
>    Note that in the case ...
>    TO

Sorry, I'm not clear how much text you're suggesting to replace
with that below. Your text btw seems correct to me, so I'd not
have any particular issue with it being included.

Would it be possible to get you to do those changes as PR for
the github repo? (If not, let's chat off list to determine
how such a PR would look.)

Cheers,
S.

[1]
https://github.com/sftcd/lpwan-ov/blob/master/draft-ietf-lpwan-overview.txt
[2] https://github.com/sftcd/lpwan-ov

>    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,
>>
>>
>> (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/
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
>>
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Feb 2017 22:34:55 +0000

Hiya,

Cheers,
S.

[1]

On 26/11/16 16:48, weigengyu wrote:
> 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?

Sort-of.

For my proto-01, I've added a "where necessary" to sentence. Not
sure if that helps that much though, but see below.

I agree that there's work needed on section 4.9 - feel free to
propose text and I'll think about it myself too.

> 
> By the statement, each LPWAN node is assigned with an IPv6 address
> and a domain name. 

No, I don't believe there's any intent that every LPWAN node have
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?

Not quite. I personally think that communication between LPWAN
nodes (indirectly via IP) is something to not preclude even if
it is not needed for many use-cases. I don't think there is a
goal to enable direct communication between LPWAN nodes via IP,
though of course some lower layer technology might I guess allow
that.

I also suspect that DNS name resolution would be more likely to
be required as part of e.g. a s/w update scheme and direct node
to node communications is a less likely motivator.

> 
> While relating to “4.9. DNS and LPWAN”, one problem is whether a
> LPWAN node requires to start a name resolution. 

My guess is that this WG will want to consider whether it is
possible for an LPWAN node to use the DNS to resolve addresses.
But I'd not be surprised if there were lots of varied opinions
on that topic.

> And another problem
> is whether the LPWAN node requires to process Domain Name in WEB
> protocol options or contents?

I'm not sure quite what you mean, but it sounds more like something
that the core WG would consider, rather than this one.

Cheers,
S.

> 
> 
> Regards,
> 
> Gengyu WEI Network Technology Center School of Computer Beijing
> University of Posts and Telecommunications
> 
> 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,
> 
> I believe it’s a very helpful document and I’m in favour of the WG
> adoption.
> 
> cheers
> 
> Jiazi
> 
> On 16 Nov 2016, at 23:55, Alexander Pelov <[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/
> 
> 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
> 
> _______________________________________________ lp-wan mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/lp-wan
> 
> 
> 
> 
> 
> --------------------------------------------------------------------------------
>
> 
> lp-wan mailing list [email-masked] 
> _______________________________________________ lp-wan mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Feb 2017 09:06:10 +0000

And Ivan did indeed submit a PR [1] (thanks!) that
I'll look at this morning. At first glance those do
seem like fine changes and essentially editorial so
that being the case I won't wait for a positive ack
from the WG chairs to accept if that's ok. I will
send mail here though if (or when:-) I do accept
the PR.

Cheers,
S.

[1] https://github.com/sftcd/lpwan-ov/pull/1