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

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Title Minutes interim-2020-lpwan-07: Tue 16:00
State Active
Other versions plain text
Last updated 2020-04-21

Meeting Minutes

Special Interim => IETF 107

WG Chairs:
* Alexander Pelov
* Pascal Thubert

    * Eric Vyncke

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: 7-8am US Pacific, 4pm CEST:
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:

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

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

[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

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

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 ]