# LPWAN WG
Special Interim => IETF 107

WG Chairs:
---------------
* Alexander Pelov <[e-mail]>
* Pascal Thubert <[e-mail]>

AD:
-----
* Eric Vyncke <[e-mail]>

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.
Working on Sigfox and PySCHC implementation in order to validate the parameters for the draft. Work slowed due to March meeting/hackathon cancellation.
Pascal: The document is not fully ready, but do you have an idea when you will be ready for WGLC?
JCZ: mid of summer should be fine.
Pascal: Send to IESG in September - past WGLC.
JCZ: Yes
Pascal: Eric - 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 clearly in scope, some not: E.g. SCHC No-ACK M'cast, SCHC unicast NACK to Multicast.
Trickle algorithm proposed by Pascal has some open questions since lpwan is mostly in star-topology.
Pascal: For 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 it, but it seems that it requries some sort of Mesh topology, whereas here we consider Star for LPWAN.
Pascal: There is no need for ACK in Trickle. It is a non-reliable multicast. It uses 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 variation 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.
JCZ: It seems that the receivers provide information to the senders about what was received, so maybe we 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: From reading the Trickle RFC it seems that Rx informs the Tx if the payload has been received. There is also the question about what happens when there is only 1 antenna covering a certain device - in that case there is no diversty, so we cannot always rely on that.
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. Encouraging authors to document Problem Statement, potential solutions, and continue discussion.
[17:55] AOB [ QS ]