Connection details ------------------ * Date: 7-8am US Pacific, 4pm CEST: http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-06-07&sln=14-15 * Webex Link: https://cisco.webex.com/ciscosales/j.php?MTID=me7f536292c568c696a054a7ff7ef0746 * Meeting number (access code): 203 453 401 * Meeting password: chicalors o 24422567 from phones Agenda ------ * [7:05]Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Approval minutes from last meeting o Review last interim todos o Terminology * [7:10] LPWAN Overview (Steve) [ 5min] * [7:15] SCHC Fragmentation (Carles) [15min] * [7:30] SCHC IP/UDP Compression (Laurent, Ana) [15min] * [7:45] SCHC CoAP (Laurent) [ 5min] * [7:50] New items (Ana) [10min] * [8:00] AOB [ 0min] Minute takers ------------- * Ana minaburo * Arunprabhu Kandasamy * Pascal Thubert * Alexander Pelov * Dominique Barthel Attendees --------- Pascal Thubert Samian Kaur Alexander Pelov Ana Minaburo Arunprabhu Kandasamy Alexander Pelov Carles Gomez Diego Dujovne Bob Heile Tomas Lagos Tomas Bolckmans (no audio!) Erika (no audio!) Dominique Barthel Laurent Toutain Juan Carlos Zuniga Past Attendees (previous meeting, for cc) --------- * Stephen Farrell * Ana minaburo * Laurent Toutain * Alex Pelov * Julien Catalano * Sumankumar Panchal * Tomas Bolckmans * Carsten Bormann * Hannes Tschofenig * Carles Gomez * Diego Dujovne * Juan-Carlos Zuniga * Paul Duffy * A Paventhan * Friedhelm Rodermund * Arunprabhu Kandasamy * Pascal Thubert * Samian Kaur * Uday Davuluru Minutes ------ * [7:05]Administrivia [10min] o Note-Well, Scribes, Agenda Bashing The Etherpad doesn’t work. We’re using Google Doc as sent the link to https://docs.google.com/document/d/1_FZCtq0qRgkbcaqYc6E6xrnozMCoCAyXW_172RVPQHw/edit Milestone, we are behind schedule, we need to go forward to be on time. Let’s try to work hard for CoAP compression o Approval minutes from last meeting o Review last interim todos -Reviews, and feedback for CoAP (CB and MV) we need more input, - Simplification of the fragmentation part of SCHC draft o Terminology * [7:15] LPWAN Overview (Steve) [ 5min] SF thinks things are fixed, could we go for a LC? The LC will be sent into the ML * [7:20] SCHC Fragmentation (Carles) [15min] Updates since last version of the document After some discussions and results, the idea is that packet mode has been extracted from the SCHC document We keep 3 modes: No ACK, Window Mode Ack always and Window Mode on error More than one type of Window size: e.g. big window (for big packets) & small window (for small packets) AP: some are commented on ML. no negative feedback. Can DD make review for the fragmentation part? - Tools as New section:different components that enable fragmentation functionality. - Need rule id to identify fragment, ACK, aborting the transmission. - Dont’ see any outstanding big issues at the moment. - PT: Consuming of Rule-IDs, is this a concern? - Rule-ID for ACK and one for Abort, so the number of Rule-IDs is big, may they be together? - CG: Abort may have Rule-Id for specific datagram, may be used for large datagram Fine grain functionality Vs consumption of more rule ids? PT: How many Rule-IDs we have? A realistic number could be good. CG: Something with an specific technology and leave this document with an open number AP: simple devices, abort may abort everything Could be problem when 2 packets fragmented parallel, aborting one sender can finish one flow and abort the other ongoing transmission. LPWAN, expect sender to finish one and go for another. AP: keep it simple. AM: Future works to decide the size of the rule ID. AP: One rule ID for abort all, if future demands, add the rule id that specifies which datagram is aborted. PT: Published the draft as it is, AM: only one comment left. If agree, we can publish the next version. PT: Start the Last call in two weeks for this doc (schc compression/fragmentation)? * [7:35] SCHC IP/UDP Compression (Laurent, Ana) [15min] AM: comments from JCZ: one point to discuss: IID for ipv6 address. Confusion about the naming ? Better to keep the ipv6 terminology even if this ID is created by MAC, Ipv4, whatever.. JCZ: on section 5, talking about action. Section about ipv6. Action may be generic dependent on the technologies. Rfc7217, also talks about IID. AM: doesn’t matter if the IID is derived from MAC or elsewhere. Just to represent the IID of the ipv6 address. JCZ: Right now in the document there is only one way to do it, which is confusing device ID and Interface Id. Agree with LT AP: Continue the exchange over the Mailing List. Ana to look again and propose addition to the document. AM: do we join both security, from fragmentation and compression? AP: keep it as one part. To be general security concerns. JCZ: subsections would be good? AM: Subsections about security problem? JCZ: depends on the security problem and its specifics. PT: As you introduce a new code on the road of the packets, you may add bugs.. For example variable length fields could provoke buffer over-flows, so we could add a sentence on “normal coding practice”, such as - make sure you have enough buffer space, make sure to check boundaries, etc. This is new code - do add checks AM: SCHC draft points overview draft as informational ? PT: Normally you never do a “normative down-reference”. A Standard Track document should not reference an Experimental or Informational document. If you put reference to the meanings and the terms, and the architectures - and reference them from the Informational Document - then it’s not clean. Doable, but not clean. PT: Ideally: Add a new section / in the introduction - position the architecture, and make sure to define all the terms. (and add non-normative reference to LPWAN Overview doc) JCZ: is it not allowed to reference an informational document? PT: ?? JCZ: Not sure there is a problem.. Could you send the RFC that describes the down-referencing ? JCZ: If it is not an action, but a term (and not use SHALL / MUST), then it should be OK ? PT: If it is not too much text, prefer to include it in the document. AP: send email to AD. suresh JCZ: agree if it makes the document self contained. * [7:50] SCHC CoAP (Laurent) [ 5min] AM: need reviewers specially for the security section. Sent email to core emailing list to address the security section. In case if other people to review, step forward. Havent’ pushed carsten or michel for review. LT: testing out comi, works well! But the draft doesn’t look good grammatically. AP: can be fixed easily. LT: need implementers for the comments. * [7:58] New items (Ana) [10min] AM: Next steps - ICMP draft received attention. LT: LPWAN-over-FOO JCZ: SCHC-over-FOO. AP: SCHC-over-SIGFOX ? SCHC-over-LoRaWAN ? JCZ: It makes sense as a complement to the SCHC document to have a SCHC-over-FOO. PT: How do you provision the rules? What are the flows? JCZ: there are several ways of doing it. Not against the way to do it. The data model is the same anyways AP: having yang data model doesn’t limit to using comi, opens up for other tools. * [8:00] AOB [ 0min]