Minutes interim-2019-lpwan-03: Wed 17:00
minutes-interim-2019-lpwan-03-201901301700-00

Connection details
------------------

*    Date: January 30, 2019
*    Time: 8-9Ana Pacific, 17:00 CET:
https://www.worldtimebuddy.com/?qm=1&lid=100,5392171,212,6&h=100&date=2019-01-30&sln=16-17
*    Webex Link:
https://cisco.webex.com/cisco/j.php?MTID=m884e9421ae0947fc7775dd30a39ce4a4
     *    Meeting number (access code): 209 036 844
     *    Meeting password: kCZVP3vu (52987388 from phones)

Todo
----

Minute takers
-------------

* Carles Gomez
* Ana Minaburo
* Pascal Thubert

Attendees
---------

* Alexander Pelov
* Ana Minaburo
* Arunprabhu Kandasamy
* Carles Gomez
* Diego Dujovne
* Dominique Barthel
* Ivaylo Petrov
* Juan Carlos Zuniga
* Laurent Toutain
* Pascal Thubert
* Vincent Audebert

Attendees (last time)
---------

* Edgard Ramos
* Julien Catalano

Action Items
----------------------------

* Pascal to cancel next call

Agenda
------

*    [17:05] Administrivia                                           [10min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts
    o    IETF 104

*    [17:15] draft-barthel-lpwan-oam-schc (Dominique)                [10min]
*    [17:25] WG next steps  (chairs)                                 [35min]
*    [18:00] AOB                                                     [ 0min]

Minutes
------

*    [17:05] Administrivia                                           [10min]
    o    Note-Well, Scribes, Agenda Bashing
AP: one main item today: oam draft
AP: objections to the minutes from the last interim? [No objections]
AP: there was one To-Do: send v2 of the charter to the ML. So far, no major
comments. Will talk to Suresh PT: Suresh will push the document (charter) to
progress, next week
    o    Status of drafts
    o    IETF 104
AP: received from Ivaylo, he will be co-chair of the cose WG, thus cose now
needs to be included in the request for WGs to avoid IP: we requested 2 hours
for cose AP: I'll do the change to the request right after the call

*    [17:15] draft-barthel-lpwan-oam-schc (Dominique)                     
[10min]

DB: presents history of the draft. Formerly, two drafts, now joined forces to
work on a single draft. The draft hasn't progressed much recently due to
focusing primarily on the SCHC draft DB: purpose - express general interest in
OAM for IoT DB: Anything that is expected from an IP enabled IoT device (Ping,
traceroute, icmpv6 error msgs)- to be discussed in the draft DB: discussed use
cases (e.g. receive a ping from the network) DB: core responds with error msg
when it doesn't find a match or rule for incoming packet for compression. DB:
status - the draft introduces OAM (opens the scope) DB: change: previous
version has new code for echo-request that could propagate to the end device
and it is removed in the current version ofthe draft. DB: not much new work, we
are rather resuming work. Next steps will comprise discussing use cases DB:
scope shall not to include the coreconf, cbor-mapping DB: ... and also
implement compression rules and implement it PT: I think the interesting
question for the group is defining a set of KPIs or measurements that are
important in LPWAN so that ping would enable us to measure the KPIs PT:
sometimes, downlink packets wait in the queue in the gateway it would be nice
have the ping packets experience the latency to know the status of the queue in
the core. PT: how many other KPIs ? Spreading factor is one of them. anyother?
PT: Header for OAM in ping packet on which it can be piggybacked.It doesn't
have to compress and the gateway shall be responding to it. (There is already
work in the IETF to enable OAM by using headers.) LT: we want to initiate the
discussion, as we are doing now, to see if there is consensus PT: draft doesn't
seem to bring much value as of now. could be good if it makes changes in the
compression. LT: we also want to present this in intarea, what we want to do
with OAM PT: would be great to see what we can do with normal tools (e.g.
ping), then see what else is needed Diego: Is there is requirement in RFC4443
for the msgs to reach directly the device? LT: No, SCHC will act as a proxy AP
(chair hat-off): At somepoint, there will be a situtation where the ping packet
has to be sent to the device. A possible way to go is use different ICMP codes
(to identify whether it is the gateway or the device that is replying) DD:
rephrasing question: is there a problem in emulating the response? The idea
behind 4443 is that ping messages arrive to the device PT: we may need a
different code for a proxy response, as opposed to a normal response from the
device LT: I think intarea can answer about that PT: We need to clarify JCZ:
need to clarify whether the device is an endpoint and the proxy is the "last
mile" or whether the proxy will relay the packet to other intermediate devices,
etc. PT: Need a separate thread to discuss the KPI? like throughput, latency,
etc. LT: the goal of this document is more to initiate debate.

*    [17:25] WG next steps  (chairs)                                 [35min]
PT: the next steps are rechartering and adopting the technology drafts. Ivo do
you think the LoRa draft can progress? [Ivo not present at the moment] PT: we
need a profile document AP: we had a draft providing a YANG model. That could
be a good starting point. We worked on it with DB at one hackathon PT: is it
possible to publish this document? Haven't seen it... AP: need to dig it up PT:
do we have a candidate for that work? LT: with Ana we also had a YANG model. It
was more focused on the rules, but we can add a new section PT: we publish this
document, then go to the technology guys pointing to this document

*    [18:00] AOB                                                     [ 0min]
PT: AOB ?
PT: do we need the next interim?
LT: depends on IESG feedback
PT: we can do that through the ML
PT: TO-DO for PT - cancel next call on the ML