Connection details ------------------ * Date: October 3rd 2018 * Time: 8-9AM DST, 17:00 CEST: https://www.worldtimebuddy.com/?qm=1&lid=2988507,1816670,5391959,5128581&h=2988507&date=2018-10-03&sln=17-18 * Webex Link: https://cisco.webex.com/ciscosales/j.php?MTID=m7933acfc5befd0ac211e03ee678e5a1d * Meeting number: 203 710 782 * Meeting password: JM3Y2Kqf * To join by phone or other means, please go to the Webex Link for details. Agenda ------ * [17:05] Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Status of drafts * [17:10] SCHC Updates since last Interim - Dominique [15min] * [17:25] Open discussion on Fragmentation [25min] * [17:40] SCHC Minimal (Alexander). [10min] * [18:00] AOB [ 0min] Minute takers ------------- * Ana Minaburo * Dominique Barthel Orange * Carles Gomez * Arunprabhu Kandasamy * Ivaylo Petrov Attendees --------- * Ana Minaburo * Laurent Toutain * Pascal Thubert * Alexander Pelov * Carles Gomez * Dominique Barthel * Juan Carlos Zuniga * Edgard Ramos * Ivaylo Petrov * Arunprabhu Kandasamy Past Attendees --------- Action Items from last time ---------------------------- * Chairs: find reviewers for drafts Minutes ------ * [17:05] Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Status of drafts o No objection: minutes of last interim are adopted. o No request for the agenda o Pascal: LoRa Alliance is developing its own fragmentation algorithm. Doubts expressed that ours works for them o LoRa meeting on Oct 10th. We need to let them know Ack-on-Error works. o The LoRa fragmentation is at app layer, for Firmware update. Our frag is wider-use and works well. To publish before 10th. [Laurent] email from Nicolas Sornin convinced with ACK-on-Error would help to solve changing MTU. o DB: request that frag works with variable L2 PDU size? o Laurent: believe we can make SCHC F/R work with variable L2 PDU size. * [17:10] SCHC Updates since last Interim - Dominique [15min] * Changes available at the github * merge request from Arun. clean up on state-machine of ack-always. * SCHC F/R MIC option - created ticket #32 * temporary conculsion- no need to change the text in the draft. please read, comment. 2 supports received from JCZ, Pascal. * State machines normative or not? consensus to be in appendix, non-normative. only the text is normative. * 2 questions from Arun. one question throws light on assuming l2word that is smaller than upper layer word length,(1 byte). new assumption (l2word < the upperlayer_word size) would be written to the draft. * still single padding is efficient. * design session last week with authors, chairs. * reached agreement on mechanism on ack-on-error; Laurent's version was abstract, JCZ is more detailed. Both drawingx express another view of the same thing. * W field is multiple bit length and doesn't roll over. opens up new degrees of freedom, can send ack later to previous windows. * 3 supports expressed on the mailing list. * request to define the notion of profile from Pascal. Ana expressed a different opinion. * [Alex]: SCHC context--> profile? is it same ? different? * [DB]: yes(different), we might have several releases of context for different technologies, for devices with different capabilities. It is more than renaming a single context. * Pascal: profile is more abstract, containing the feature set. devices have different rules that may have same profile. * Laurent: not really interested in this discussion just before the cutoff date of the draft. * Pascal: This might be needed for the technology specific drafts, so maybe here it's a good place to put it. * Edgar: First time hear about profile for SCHC. Related to context provisioning. * Alex: is there more in a profile than a list of Rules? * Pascal: yes, definitely. E.g., for Ack-on-Error frag, when are ACKs sent and expected by the receiver. * Pascal: Profile desribes variations in the protocol, that don't reflect in the Rules themselves. Technology is part of the profile identification, but is not the complete thing as variations (when do you send the acks for example) could be changed independently. * Alex: shall be put this(profile info) on the side of the context? * Laurent: prefer to do this discussion about profile outside the document and priority to submit before 10th. * Charlie's answers to be processed. ACkalways, ACKonError to be written, JCZ already provided state machine drawings of ackOnError. * Dominique: no change in ACKalways. NoACk mode reviewed by the authors. ACkalways still empty but no changes expected but fitting with the new document structure and better describing protocol as sender behaviour / receiver behaviour (as suggested JCZ). * Edgar: ackalways still retains 1bit W (binary)?. Pascal: yes , since we ack on every window. * Dominique: W field only defined in Section 8, more precisely at the section 8.2.3 (the definition of the tools in our SCHC F/R toolbox). * Dominique: ACK-Always is defined in 8.4.2, and will say it uses the W field with a width of 1 bit. * Deadlines shortened a bit, 22nd --> 10th. * Alex: do we have any big things to discuss on ACkonError; Carlos: nope, Dominique: writing base mechanism, significant work remaining. Lora alliance might expect schc over lorawan document. * Edgar: Will have meeting with Nbiot people, will come back if there is any feedback from them. * JCZ: see no big deal with the new protocol, he is happy with the work done * [17:25] Open discussion on Fragmentation [25min] * [17:40] SCHC Minimal (Alexander). [10min] * Alex: Chair hat off - how do we do the bootstrap How do we ensure interoperability? Maybe different techonologies. How do they learn their capabilities? Maybe they just need to know each other in advance, or they much know sufficiently about each other in advance, so that they can bootstrap. Or a default configuration * No default config, means the context need to be config in different means * We can have: In band or out band configuration * JCZ: No default you say is always out of band - why? *AP: No default and SCHC Minimal are they the same? *JCZ: No default is not SCHC minimal * AP: No default means there is are no default rules that you can use to provide in-band the context. * JCZ: There are 3 options: default ones, out-of-band and ?? * AP: SCHC Minimal can be implemented in every technology that can be seen as the default (world-wide default) * AP: A second level: with a very simple defautl with the technologies defining more complex rules * AP: with the default we can enable bootstrap, with interoperability among technologies * AP: Each of them has advantages and disadvantages - disadvantage could be that we might be mandating things that are not really useful in the end. Maybe some techonlogies will not need a fragremtation technic and we have mandated it, so it will be a waste of bits/bytes. * ER: This SCHC minimal is related to the profile, because we implement what we need * ER: could define a Minimal profile. Device manufactures can decide to implement it or not. So you dont force every device to implement -minimal. *AP: How we know what the device supports? DO a global rule showing what do you have, can help to interop *ER: How the device can config another profile it wants to use?, how to distribute the profiles? *PT: Profiles need to be standardize, to be known. To signal that by the name of profile or something *AP: So we can also do it with the Rule, Rule 1 is going to give this profile *DB: assigning Rule IDs for "default" Rules eats into the freedom of present and future technologies to number Rules as they like. *AP: We can define a number of bits but to define the same for the same profile *PT: more concerned about provisioning the back-end than the device. * [18:10] AOB [ 0min]