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