Minutes interim-2020-lpwan-07: Tue 16:00
minutes-interim-2020-lpwan-07-202004211600-00

# LPWAN WG
Special Interim => IETF 107

WG Chairs:
---------------
* Alexander Pelov <a@ackl.io>
* Pascal Thubert <pthubert@cisco.com>

AD:
-----
    * Eric Vyncke <evyncke@cisco.com>

Virtual Blue Sheet
------------------------
1. * Alexander Pelov
3. * Arunprabhu Kandasamy
4. * Carsten Bormann
5. * Ana Minaburo
6. * Laurent Toutain
7. * Dominique Barthel
8. * Ivaylo Petrov, Acklio
9. * Pascal Thubert
10. * Ricardo Andreasen
11. * Olivier Gimenez
12. * Diego Dujovne
13. * Amelia Andersdotter
14. * Carles Gomez
15. * Christian Amsüss
16. * Julien Catalano
17. * Tim Costello
18. * Patrick Wetterwald
19. * Vincent Audebert
20. * Alvaro Retana
21. * Jack Kozik
22. * Carles Gomez
23. * Chi-Jiun Su
24. * Juan-Carlos Zuniga
25. * Yannick Gaudin
26. * Geoff Mulligan
27. * Sandra Cespedes
28. * Sergio Aguilar
29. * Eric Vyncke

Date/Time
--------------
Date: 7-8am US Pacific, 4pm CEST:
https://www.worldtimebuddy..com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2020-04-21&sln=14-16
Please send your presentation slides to the chairs by this Friday, April 17th,
23h55 (your local time).

The agenda for the call is on the Datatracker:
https://datatracker.ietf.org/doc/agenda-interim-2020-lpwan-07-lpwan-01/

This is a virtual meeting that will present all the items we couldn't address
on our planned IETF107 meeting, so note that it is longer than usual - 2h.

Please use the presentation template which can be found at the Datatracker as
well:
https://datatracker.ietf.org/doc/slides-interim-2020-lpwan-07-sessa-presentation-template/

Agenda
------
The final agenda will be announced one week before the meeting.
The very tentative agenda for this meeting is as follows:

[16:05] Administrivia                       [10min]
    o    Note-Well, Scribes, Agenda Bashing
    o    WG Status
    o    Next interims
AP: Starts, Welcome Eric
AP: Note Well is done, minutes are taken (Arun, Ivaylo, Olivier G), session is
recorded Jabber scribe is AP. Pascal: Agenda bashing, no bashing of the agenda.
Pascal: Milestones description (only one milestone for all the technology
documents, but maybe some of the drafts will be handled out of the group
earlier).

[16:15] New charter                        [ 5min]
Alex: Presenting the new charter. All charter items have corresponding
documents and teams working behind it. Multicast postponed to next charter
citing missing document for reference at the IESG. Pascal: Congratulates all
the group for RFC8724. Thanking Suresh and welcoming Eric. Pascal: 5 WG
documents, only NBIoT not presented today. Ana to provide an update now.

[16:20] Status of drafts                   [10min]
Ana: Going forward with draft NB-IoT, divided into different use cases. Looking
forward to having it in WGLC by the end of the year. There should be a new
version by end of June Pascal: Command and control registry won't be discussed
today

Alex: Resuming the interims as they were really useful and proposing to have
the same timeslot [Wednesday 4-5pm CEST].

[16:30] Data Model                         [10min]

LT: Available on github. Now the model focuses only on YANG and does not
include tricks related to CORECONF. The goal is to have 1 file in the end, but
currently it is split into two files in order to facilitate the development.
When we agree on all the values, we will merge in a single one.

Carsten: How does the payload marker relates to option number as those are
delta encoded and the payload marker is a fixed value Laurent: We have stable
numbers Carsten: If you use the stable numbers then you don't see the payload
marker at all. Laurent: indeed, maybe it is not necessary. Carsten: We can
always allocate this number (0xFF) to an option. Laurent: We have to take care
of this and put them in different spaces Carsten: Maybe you can do efficient
encoding from 0 to 3000 or so and have something less efficient for everything
else. Laurent: If we do that I do not know how we create things without naming
them, so it can lead to huge number of definition. There might be a trick to
avoid it ?

Laurent: We have something rather stable. It can be improved, but maybe we can
go to YANG doctor review. Also we can improve the descriptions, to avoid
ambiguities.

Dominique: The draft says there can be a RuleId of length=0 (no RuleID). How
can you use it? How can it be transmitted over the air? Laurent: if you have a
0-length rule, there can't be any other rule. They were called in the beginning
legacy device rules. Laurent: No fragmentation padding bits represented in the
yang model for now. can be addedd

[16:40] CoAP static Context                [15min]
Ana presenting. Almost done (still 3 objections that still need to be
addressed). Eric V, in the chat: Btw, about the
draft-ietf-lpwan-coap-static-context-hc, it is not 'objections' but 'discusses'
 but basically needing to be addressed by the WG/authors ;-) Ana: Context
initialization as a NOTE for the scenario where the compression is done ONLY
for the application layer, CoAP in this case. everyone in the group agrees?
Laurent: It is more generic than CoAP and should be tackled by working group
instead. Alex agrees Pascal: The idea of the data model is to prepare SCHC GWs
to talk with a new device. Alex: This brings the importance of the previous
presentation. Dominique: Integrity check is only on the fragmentation, not on
the schc header compression. Has to be reworded. Ana: Length of residue if
compared with expected length Laurent: Comparing zip attack to the compression
in SCHC - not possible as there is no possibility to extend a value with a
random amount of data. In zip in a way you say you should have here 100
character X, whereas in SCHC the var length in headers is related to the length
of the payload that is being transported, not the one that is omitted.
Christian Amsüss: Have anything been done to ensure that OSCORE layer can
detected any issue with the compression ? Christian Amsüss: If there is
discrepency between between the compression contexts that might not be
detected? Christian: filed into a GitHub Issue. Laurent: Using CoAP compression
is efficient for header protocols of EDHOC with 1 rule resulting in 2 bytes of
compressed residue and having standard CoAP server 'aiocoap'

[16:55] Tech: LoRAWAN                      [15min]
Olivier presenting.
Most changes since IETF106 appeared in -05. -06 and -07 were mostly editorial
fixes. Ready for WGLC? Pascal: will issue WGLC with 3 weeks review time.
Pascal: It is going to be a kind of a reference for the schc-over-foo
documents, so it is important that this first document is done right, so please
reivew it carefully.

[17:10] Tech: SigFox                       [ 5min]
Juan Carlos presenting.
Sigfox and PySCHC implementation in order to validate the parameters.
Pascal: The document is not fully ready, but do you have an idea when you will
be ready for WGLC. JCZ: mid of the summer Pascal: Send to IESG in September -
past WGLC. JCZ: Yes Pascal: Then we will have 2 new milestones - one for
LoRaWAN document for in 2 months to handle to the IESG and another one in
September for Sigfox.

[17:15] Tech: PPP                          [ 5min]
Pascal presenting.
PPP is a simple enabler that opens up a lot link technologies.
Intention to republish as an intearea doc.

Ana: Are you planing to add an NCP negotiation for context validation ? to make
it more dynamic. Pascal: No, we are working in a world where capability is
there in the gateway. Better to keep it in lpwan if we had to define a profile
for PPP compression rather than in INT-AREA WG. Alex: Can we do the work in
LPWAN and have a liason or some way to ping people in order to register the PPP
point? Eric: INT-AREA seems the place to go. Pascal: We might be missing a
section on profiling SCHC for high-speed networks. Like the Sigfox document for
profiling on one constraint network, but for hight-speed network. Eric: We do
it by extending the charter or we do it by AD sponsoring, which I do not mind.
Eric: It can be a proposed standard even if it is AD sponsored, but we can
discuss this with the chairs and come back to the WG after that.

[17:10] Interop Test / Remote Hackathon    [10min]
Dominique presenting.
Olivier: Connector is for openSCHC header
Laurent: You forgot to put Acklio in the list. We were also trying to put the
openSCHC server to be available for people to test their implementations.

[17:30] OAM                                [10min]
Dominique Presenting.
Will bring some open questions to be discussed in the working group.

[17:40] Multicast                          [15min]
JCZ presenting. Some options clearl
Trickle  algorithm has some open questions since lpwan is mostly in
star-topology. Pascal: Trickle: the idea is we still have multiple gateways
that can receive any given packet from a device. The idea is consider the area
with a distribution of antennas. Considering several set of antennas reaching a
set of devices you can ask a first set of antenna to reach a set of devices.
With exponential backoff you can use another set of gateways This can only work
if the devices are listening the whole time or they wake up on a schedule, so
that the downlinks can be sent accordingly. JCZ: It was not clear the last time
we discuss this, but it seems that ??? Pascal: no ACK in Trickle. Not reliable.
Exponetial back-off on the repetitions. Here, would have a potentially
different DS (Dominating Set) of GWs to send each repetition of the message.
Alex: Will we need some document that defines a variabtion of trickle adapted
for LPWAN networks. Pascal: Initially I thought it will be the normal Trickle,
but in LPWAN we can have the central server that determines the dominating set
and it is more powerful this way. JZC: It seems that the receivers provide
information to the senders what was received, so maybe I will need some more
discussions around this. Pascal: You don't rely on specific ack from the
receiver. Normally the receivers repeat if there is not enough density already,
which can provide information. In LPWAN we are going to remove the repeating...
we will be using NoAck mode, but then the JCZ: It seems that you inform the
antenna if the payload has been received. There could be only 1 Pascal: Should
we always send the downlinks by the same gateways - the answer is no. If there
is one device that is covered by only 1 antenna, we should include that one in
all the dominating sets. We will predefine the dominating sets in advance. If
there are still devices that have not received everything, they can come and
say - hey, I did not receive this fragment. If you use different antenna for
the different retransmissions, that increases the chances all devices to
receive the packet and it will be beneficial for the antenna's duty cycle.
Alex: There is a lot of support for this document from the voting in the Webex.
[17:55] AOB                                [ QS ]