Connection details ------------------ * Date: September 12, 2007 * Time: 8-9AM DDate: 8-9AM DST, 17:00 CEST: https://www.worldtimebuddy.com/?qm=1&lid=2988507,1816670,5391959,5128581&h=2988507&date=2017-8-29&sln=17-18 * Webex Link: https://cisco.webex.com/ciscosales/j.php?MTID=mda0658c049908cec459a2a0be9e0039b * Meeting number: 208 224 943 * Meeting password: d5bBrqTZ (35227789 from phones) * Join from a video conferencing system or application * Dial 208224943@cisco.webex.com * Join by phone * +1-866-432-9903 Call-in toll-free number (US/Canada) * +1-408-525-6800 Call-in toll number (US/Canada) * Access code: 208 224 943 Agenda ------ * [17:00] Administrivia [10min] o Note-Well, Scribes, Agenda Bashing o Status of drafts (WGLC / forthcoming WGLC) * [17:10] LPWAN Overview - WGLC status and updates [ 5min] * [17:15] Milestone updates and new items (Pascal, Alexander) [ 5min] * [17:20] SCHC - Adding a length field for rules (Arun) [10min] * [17:30] SCHC - LPWAN Fragmentation (Carles) [10min] * [17:40] SCHC - Fragmentation optimization + FSM (Laurent) [20min] * [18:00] AOB [ 0min] Action Items ------------ * Chairs to book the meeting for IETF 100, 80 people, 2:30Hours * Alper to send an email to the list with proposed editorials * Chairs to Ask Stephen to publish the doc with Alper's comment * Arun to resend his mail asking for the length indication in the rule * chairs to ask the group to review the FSM in today's material posted on the IETF Minute takers ------------- * Ana minaburo * Arunprabhu Kandasamy * Pascal Thubert Attendees --------- * Abdul Saboor Malik * Alexander Pelov * Alper Yegin * Ana minaburo * Arunprabhu Kandasamy * Diego Dujovne * Dominique Barthel * Carles Gomez * Juan-Carlos Zuniga * Julien Catalano * Pascal Thubert * Laurent Toutain Past Attendees (previous meetings, 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 * Alexander Pelov * Alper Yegin * Ana minaburo * Arunprabhu Kandasamy * Bob Heile * Pascal thubert * Laurent Toutain * Julien Catalano * Juan-Carlos Zuniga * Dominique Barthel * Russ Housley * Lorenzo Vangelista Minutes ------- * [17:00] Administrivia [10min] o Note-Well, Scribes, Agenda Bashing o Status of drafts (WGLC / forthcoming WGLC) * Alex presents the introduction, Note well etc... * Agenda bashing (packed), updated the title of Carles' presentation * No addition to the agenda * Actions already done from reviews: * Carles: Dominique and Diego have given the comments. Dominique's comment in ver-06 and Diego's comments in ver-04 incorporated * Alex: Feedback from IESG, update of milestones, try to keep the following dates for both drafts. If there are some inputs send them to the mailing list * New dates updated for deadlines * rechartering: ICMP compression, security topics. This the moment to see which are the topics you are interested to do * in the next 2 weeks, start drafting your thoughts, who want to work in each item * IETF100 organization: How much time for this meeting? More than 2 hours? *Laurent: need a good discussion for state machine and implementation * Pascal: Ok, seems to be good to have 2h30. The meeting will not be crowded. Meetings in Asia always less attended. * Alex: Last time it was on friday and we were more or less 80 people so, 100 is ok * Pascal: what meeting conflicts to avoid? CoRE, netconf, T2TRG, anima, intarea, *Laurent: Needs to interact with CoRE for coap compression, so its important! *Juan Carlos: ask T2TRG is 2nd importance, * AP: 2.5 hrs is enough, no need for side meeting * Pascal: we have already done a bar BOF so we need to work more aggresively on the topics for the bof if you want to target Singapore * LP-WAN can do the work because we are using Yang * [17:10] LPWAN Overview - WGLC status and updates [ 5min] * Stephen push the last revision, for the LC of this document * Stephen has to published a last version with the revisions * Alper: He has some comments and few additional information for Lorawan * Pascal: Push your comments to the ML to see if they can be push in this LC * Alper: This not mayor for the contribution, there some more details * Pascal: The next step is the Internet Area director will review the document Suresh can ask the IESG to review the document, the clean form is to send this to the ML and see if it is an editorial correction it can be done and see in the ML, * Alper: I send to you chairs the comment and you decide * PAscal: the best is to send to the ML * Alex: do you have time to work in this modifications? * Alper: I can do it this week. => Alper send a mail to the ML to propose an editorial changes => Chairs talk to Stephen * [17:15] Milestone updates and new items (Pascal, Alexander) [ 5min] * Ana: Input request for Dominique. Some modification from fragmention by Carles. Re-Order all the text in the draft for the last version. framework together Schc with fragmentation in ver-06 * [17:20] SCHC - Adding a length field for rules (Arun) [10min] * Arun: add a field length to the context, so that the compressor/decompressor can use it to decide on the length * It is easier for the interop - to have uniformity accross implementations (otherwise, people were rewriting the code) * Pascal: If it is only a column in the rule it is not so heavy * Laurent: It could be a good idea to facilitate the compression even for variable length filed for CoAP * PAscal: 0 is tricky, why not put anything else. * Laurent: we can put variable * PAscal: 1 column how you get the length if not constant then you put the value * Laurnt: very near from Yang constant, * PAscal: the idea is to do not do it complex * Alex: I agree on I dont like the zero value as special value, and how to encoding in the implementation , I do not like adding any column to add some bytes. Use a minus 1, instead of zero, it is not a good solution, but we need an integer * PAscal: -1 is no * Alex: in yang there is a way to represent this as a function of length * Revive the discussion on length *Arun: resend the mail to the ML with this text * [17:30] SCHC - LPWAN Fragmentation (Carles) [10min] * Carles: 3 discussion on the ML * Carles: Window mode- ACK always: retries in the last window. When to check the MIC and send ACK, there is a proposal in version 06. After a frag is recevived the MIC is checked and when reassembly the ACK is sent. IF the ACK is lost or a retransmitted fragments is not correct and the timmer expires, then the fragment is sent again, and the receiver sens the ACK with the bitmap in order to check which is lost. *Pascal: We go a time out , but we ca avoid it, using how many message can be received to take it as lost? *Carles: This kind of inof cn be put in the header but thisincrease the size of the header *PAscal: I would try to avoid the time out, but include it *Laurent: Change the sze of the fragment but we do not know which is lost *Pascal: what's happen now is on side know the missing part * Laurent: Sender does not listen all the time for the ACK * Pascal: inCF2 to indicate the last, in the 1st window is the MIC but for the 2nd we do not know => We need to think about how to say to CFN2 how to detect the last one. * Pascal: If you know which is the last one, even when the MIC does not work it is enough, as iti is a retry it knows that 2 is the last one. Then we need a time out * Alex: we need a state machine to see if this is clear * PAscal: avoid time out, the problem is the delay * Laurent: it will not be too long because when you expect something so when it does not arrive, The sender has just a short window to receive the message. * Carles: duty cycle, will make the time out short ot longer * Alex: so we need to think it more, because as Carles said duty cycle can make this variable * Alex: if there is no ACK, there most be an uplink to resend so this avoids the complexity, but you need it in update messages. * Carles: I can add more text to explain more clearly this problem => Look to slides and review the FSM from Laurent * Carles: The 2nd item. In ACK always has 2 parameters. with different meanings, Arun ask if we can splify to a single parameter, but we can have one for mas_frag retries, and the other max-ack-request that is the only one used. In version 6 only MAX_ACK_REQ is left, one question on the ML about this input only receive an answer for Arun *Alex: As long as we simplify without modifying the fragmentation we can continue doing this, it is good *Carles: 3rd item: about in ACK on error, R send an ACK an expects retry how about battery on devices, the options can be done in the parameters but it can be done on an specific document of SCHC over foo. *Alex: It is important to put this items in the the security section, that an attack can be done over here. *Alex: Suggest a default value, but I've not a strong idea or leave it as an implementation problem *Juan Carlos: Probably define it for ACK on error, and then leave the specific value for the SCHC over foo documents. About security issue, it can be considered as a general topic to be included in the security considerations section, not for only for this mode or parameter but in general as a potential attack to depleate * Alex: we have to finish today, but review the slides from Laurent on the state machine in order to discuss next time. * Pascal: It is a mix between a state machine and a flow chart, * Alex: Move this to the ML and convert this to a real state machine next time as an important topic. * [17:40] SCHC - Fragmentation optimization + FSM (Laurent) [20min] * [18:00] AOB [ 0min] * Alex: Thanks you very much * PAscal: there are some TODOs, please review the minutes