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

[Stephen Farrell <[e-mail]>]

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

On 26/02/17 22:34, Stephen Farrell wrote:
> 
> 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) <
>> [e-mail]> wrote:
>>
>>> Yes for adoption.
>>>
>>>
>>>
>>> Patrick
>>>
>>>
>>>
>>> *From: *lp-wan <[e-mail]> on behalf of Alexander Pelov <
>>> [e-mail]>
>>> *Date: *Wednesday, 16 November 2016 at 23:55
>>> *To: *lp-wan <[e-mail]>
>>> *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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>>
>>>
>>
> 
> 
> 
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan
>