Connection details ------------------ • Date: 7-8am US Pacific, 4pm CET: https://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2020-01-08&sln=15-16 Meeting link: https://cisco.webex.com/cisco/j.php?MTID=me91d56b37454056b8c5ef3b102b9da50 Meeting number: 201 266 501 Password: txCGJTrS (89245877 from phones) Agenda ------ [16:05] Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Status of drafts [16:10] Last updates of SCHC IP/UDP (Dominique) [15min] [16:25] SCHC YANG Data Model (Laurent) [25min] [16:50] AOB [10min] Minutes takers ------------------- Ana Minaburo Arunprabhu Kandasamy Attendees ------------- - Pascal Thubert - Alexander Pelov - Ana Minaburo - Laurent Toutain - Ivaylo Petrov - Dominique Barthel - Olivier Gimenez - Diego Dujovne - Vincent Audebert - Arunprabhu Kandasamy - Juan Carlos Zuniga Missing Past Attendees ------------- - Carles Gomez - Julien Catalano Meetig minutes ------ [16:05] Administrivia [ 5min] o Note-Well, Scribes, Agenda Bashing o Status of drafts * Send the power point to chairs instead of PDF, Webex does not like pdf. * Olivier will be added at the end, it will be added next time because LoraAlliance meeting is today same time * But the Lora Alliance is at the same time so we need to change the hour the 2nd wednesday, for next meeting we need to watch up this time * Pascal give the Note Well * Alex: CoAP is now in AD Evaluation, with Farell mail * Ana: We have answer to Farell about his inputs * Pascal: I think the draft is in the queue * Alex: We have a new draft for PPP, do you think it will grow or it will be kept like that? * Pascal: I think it is done, the one think is to negotiate a compression mechanism, and perhaps it give us SCHC over PPoE. SCHC over ethernet, PPP, wifi can be addressed with this one single draft. * Alex: Does it fit in the milestones? * Pascal: Perhaps it could be because it is important to give this soution for serial links, we can present in IntArea, what do you think Juan Carlos? * JuanCarlos: INTArea open to new work , people will be more familiar about lpwan * Pascal: I can present it next time, actually we need to indicate where the data model and the context is in the compression, probably through an URL. * Alex: Yes, I think it is important to be presented next time * Pascal: I send the meeting request for next IETF, if you have any conflict please send to me an input * Pascal: Next meeting deadlines, please take a look, for the early registration and cutoff on early march. We will post a slot request, please send an e-mail on march 11th to make the agenda [16:19] Last updates of SCHC IP/UDP (Dominique) [15min] * Carsten provided extensive review of everything again. Responded to all points. * Updated example in Appendix A. * version 24 has editiorial improvements. * Carsten commented we cannot decide if the profile allows multiple rule matching or not. * All0 and ACK Req must be distinguisable, clarified lifeitime of dtag in receiver. * -24 approved by Suresh. * we don't have Misref? referencing a document that is still in draft. * Pascal to make the transformation and send to Dominique , that will be a new version. * questions from authors for schc-over-foo drafts and implementers. [16:33] SCHC YANG Data Model (Laurent) [20min] * Look at github directory to check the last version, we are working on. The synchronisation will be finished after the meeting * Pascal: Send a mail when it is done to the ML * Laurent: I'm not a yang doctor, so I'll try to give a solution with the things we understood. * In the draft there is a definition of SCHC fields and MO and CDAs in yang, * Level of granurality has been intriduced for some fields as traffic class or code in coap. * When the fields are define the question is until which details we go * CoAP is in the same space as udp, ipv6. Carsten: reserve all the options space as identifiers. * Carsten propose to reserve the whole space but it could be a waste of numbers, * openschc implementation uses 0xff as end option. Conflict arises if the core uses this value for another option. * In the model version is added, does it is a good idea? does version will be use to identify the version we are using? discussion is needed * Fragmentation has not been completely done, we need to define all the fragmentation entries and we need input from the implementations * Yang is define to give an ASCii value but for LPWAN is better to get a numerical value, but yang is not done for this * For target valule the next step is to give the highest and the lowest values * Pascal: We need to talk with Benoit or people that talks yang if they have an input * Laurent: There are things that have not been well done, * Pascal: yes, like IPv6 @ * Laurent: We have open questions about profiles, but we need to discuss and see how to do it * Limitation with several arguments, the question is who cares? do we need to find a solution? * Laurent: I will send a mail and ask some inputs to see the needs and to go forward * Pascal: We need to talk with a yang doctor, * Alex: In Core this question was raised, so just use the ASCii representation and then they change their mind, but I cannot remember to what * Alex: suggest to use a string representing a Base64 encoding * Laurent: possible but not as efficient as binary * Pascal: Base64 increases computation load. * Laurent: Numerical1 and Numerical2 to build large integer (typically IPv6 address). * Alex: let's also investigate Bitarray [16:25] LoraWan IID (Olivier) [10min] Alex: The time is gone, we can talk about IID next time Olivier: or by mail Pascal: Let's do it now Olivier: We are using the half of the hash [16:50] AOB [5 min] Discussion happens, currently-proposed IID computation looks good, need Alliance validation that it does not leak too much information. Julien Catalano proposed another mechanism that involves installing some context, therefore needing a bit more control overhead. Olivier ot post on the ML in this and follow up with Alliance