Connection details ------------------ * Date: December 12th, 2018 * Time: 8-9Ana Pacific, 17:00 CET: https://www.worldtimebuddy.com/?qm=1&lid=100,5392171,212,6&h=100&date=2018-12-12&sln=16-17 * Webex recording: https://cisco.webex.com/cisco/lsr.php?RCID=dd170ca3dc944d3cad0f2467b9b12efb * Recording password: eFv3B2wx Agenda ------ * [17:05] Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Status of drafts * [17:10] SCHC WGLC completion (Dominique) [40min] * [17:50] SCHC next steps (chairs) [10min] * [18:00] AOB [ 0min] Todo ---- * Pascal to scedule new meetings starting 16 of Jan. * Pascal to update the milestone for SCHC COAP: November next year * Juan Carlos to check the references Minute takers ------------- * Carles Gomez * Ana Minaburo * Pascal Thubert Attendees --------- * Alexander Pelov * Ana Minaburo * Carles Gomez * Dominique Barthel * Edgard Ramos * Ivaylo Petrov * Juan Carlos Zuniga * Laurent Toutain * Pascal Thubert * Vincent Audebert Action Items from last time ---------------------------- * WGLC comments addressed * SCHC CoAP to be published by 11/2019, milestones changed * Material of the LoRaWAN webcast published with last interim IETF LPWAN proceedings Minutes ------ * [17:05] Administrivia [ 5min] * Pascal: all SCHC authors expressed are not aware of any IPRs on the SCHC draft * Alex: any changes to apply to the minutes of the last interim? --- No changes required --- * Alex: we'll need to agree on when we restart the interims (e.g. in January) * Pascal: same slot? (Nobody mentions issues with that) * Pascal: Next subject is data model * Laurent: Also need to discuss over CoAP * Pascal: restart interims in January 16th 2019, every other week, same time as now. * We'll have 2-3 calls before the next IETF * ToDo: Pascal Schedule new meetings from 16th of January * Pascal: milestones for the SCHC CoAP draft? * Laurent: November 2019 * Pascal: OK * ToDo: Pascal Update Milestones (NDE done) * Note-Well, Scribes, Agenda Bashing * Status of drafts * [17:10] SCHC WGLC completion (Dominique) [40min] * Dominique: evolution of the text can be checked on github * Dominique gives a recap on the next steps * Dominique presents changes (on github) since -17. There are 12 commits since -17. Thanks to Charlie Perkins (extensive review), Shoichi and Arun (questions). Thanks to coauthors and chairs for input. * Dominique: resolution on the "optional MIC" issue. Ticket #32 will be closed again. * Dominique: Target Value Type needs to be specified in other documents * Not everybody is agree but is there any objection? * No objections * Dominique: side benefit, thanks to the questions by Charlie, is an extensive rewrite of 7.1 and 7.3; thanks to Laurent for additional explanations * Dominique: Charlie suggested that Appendix D should be normative. Authors apparently don't want to go that way. * Pascal: we would take risks if we follow the approach proposed by Charlie. * Dominique: personally, I'm inclined to keep it as it is. * Pascal: any objection to keep it in the Appendix D? [There are no objections] * Dominique: capitalized "Context", use it consistently throughout the doc. Any objections? * Ana: in ROHC and other docs, the term "context" is also used. * ToDo: Ana develop a good response for the context terminology used. (NDE, mail to ML on 12/13) * Pascal: 6LoWPAN RFC 6282 also calls it "context". * Dominique: When a reference is Normative or Informative? * CG: Sent to the ML an IESG statement on in which case the reference is normative or informative * Juan Carlos: Normative is what is required for you to do your technology * Pascal: The problem is when you put a Normative in the informational reference * ToDo: Juan Carlos verifies the References of the draft that they are in the good Normative or Informative place * Dominique: The place padding is defined need to be put at the begining. * Laurent: Position is not important in the draft, it is good as it is * Dominique: if nobody (among coauthors) is interested on that topic, we just leave it as it is * Dominique: Release the resources, * Pascal: we don't need to give implementation details * Dominique: I'll just remove it (text about "releasing resources") * Dominique: Specify when you must/may exist. Algorythm an internal resources implementation * Edgard: I think it is technology related, because retransmission depends on the transmission and on the technology. This is something to be defined in the technology document * Dominique: It is a nested IF-Else to give the end, without mandating that this has to happen * Edgard: When it is expected that the reception is completed needs to be defined. And also what does complete reception means? You can later define what does it means by the implementation... * Dominique: that's good input, I'll think about how to apply it to the document * Dominique: next is WINDOW_SIZE, MAX_WIND_FCN, MAX_FCN... * Dominique: The work is hard because we need to change all the draft, but it looks like a good idea for the new reader for using 'WINDOW_SIZE' * Laurent: I like WINDOW_SIZE * Pascal: looks like a good idea for a new reader * Dominique: objections? [No objections] We have a decision! * Dominique: Charlie comments that "compression residue" is not very clear... * Ana: for me, compression residue means the whole result. We have examples in the end of the draft, which indicate "bits sent" * Dominique: I will create the drawing on slide 13 for the document and will provide some better explanation * B: Last tile size to be aligned... * Dominique: suggest at least a tile should be an L2 word, perhaps all tiles should be at least 2 L2 words to allow borrowing from the penultimate tile. I am inclined for 2 L2 words per tile. * Laurent: if the tile is too small the transmission is not optimal * Dominique: The smallest MTU is 11 or 10 bytes * Laurent: We can find a solution as for Sigfox downlink * Juan Carlos: 2 L2 words should still be a decent minimum. Do you want to mandate it? * Dominique: yes. I want to mandate a 2 L2word tile * Edgard: I understood tiles will always be larger than the smallest transport format (i.e. L2 transmission block). I'm wondering if any technology has this issue (and if it has to be specified). Perhaps it is enough to just document the problem or give a recommendation. * Dominique: Some volunteers to quickly read draft-18 before submission * Pascal: Saturday is expensive. Suresh need to see it, friday not to late in order that Suresh should see it. * Carles is a volunteer but need some time on Friday morning. * Pascal: Publish as soon as you finish the last changes, and put Suresh and me in copy to be aware about the publication. * [18:15] AOB [ 0min]