Minutes interim-2017-lpwan-03: Wed 16:00
minutes-interim-2017-lpwan-03-201705241600-00
| Meeting Minutes | IPv6 over Low Power Wide-Area Networks (lpwan) WG | |
|---|---|---|
| Date and time | 2017-05-24 14:00 | |
| Title | Minutes interim-2017-lpwan-03: Wed 16:00 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2017-05-24 |
minutes-interim-2017-lpwan-03-201705241600-00
Connection details ------------------ * Date: 7-8am US Pacific, 4pm CEST: http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-05-24&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 [ 7min] o Note-Well, Scribes, Agenda Bashing o Approval minutes from last meeting o Review last interim todos o Terminology * [7:12] LPWAN Overview (Steve) [ 5min] o Status on Steve’s issues on ML o Publication? * [7:17] SCHC IP/UDP Compression (Laurent, Ana) [10min] * [7:27] SCHC CoAP (Laurent) [15min] * [7:42] SCHC Fragmentation (Carles) [15min] * [7:57] AOB [ 3min] Action Items ------------ Minute takers ------------- * Ana minaburo * Arunprabhu Kandasamy * Pascal Thubert Attendees --------- * Alex Pelov * Ana minaburo * Arunprabhu Kandasamy * Carles Gomez * Diego Dujovne * Juan-Carlos Zuniga * Laurent Toutain * Matt Gilmore * Rashid Sangi * Stephen Farrell 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 [ 7min] o Note-Well, Scribes, Agenda Bashing * Ana asks for a few minues in the end to talk about future items o Approval minutes from last meeting * Corrections or modification to the meeting minutes are aprouved o Review last interim todos * JCZ reviewd the first half, frag outstanding. * Diego already started as well * Steven sent an update * Missing Michel and Carsten review for CoAP draft o Terminology * [7:12] LPWAN Overview (Steve) [ 5min] Steve: only issue seems to be AAA server. People are OK with LBES. AP: Back end server would mean lot of things to different people. Authentication Server is also in the LBES? PT: if we prefix it with LPWAN we can do what we want Do we only do authentication or authorization also? AP: Both are needed. BLES is what does it do? PT: still authenticationi and authorizatioin, considering roaming. SF: so just call it LP-AAA Server? JCZ: LP-AAA Server.. misleading as low power AAA server? Suggestion is LPWAN-AAA server AP: Any could works which represents what we are doing SF: to replace the terminology with LPWAN-AAA AP: Can we do last call next week? SF: yes, most of the things are ready AP: Steve to send when new version available. o Status on Steve’s issues on ML * Stephen: only left issue is AAA server name. If people are OK can call it backend server o Publications? * AP: Last call next week. * [7:17] SCHC IP/UDP Compression (Laurent, Ana) [10min] * Presenter : Ana * Important stuffs not clear , w.r.t. Diego's comments. * why we need order for the compression rules?. Can put it in any order, header format order. * Agree with the header format order ? * LT: Order is important * AP: IP/UDP headers fixed, CoaP has repeatable options. * Ana: Seems logical to have it in header format order. * Laurent: order is important for serialization * SCHC is protocol and fragmentation is mechanism, do we need to rewrite the introduction? PT: If there is an interaction between two devices, then you have a protocol. If there is any form of discussion, then it is a protocol. If you just compress stuff, then it is a mecanism. A CODEC is not a protocol. LT: Agrees. Compression is a mechanism, fragmentation is a protocol. * ANA: So we rewrite the terms in the draft. * LT: in ipv6 and udp , only one instance of field. but coap multiple instances so we need to make difference in the identifying the fiield. the position would help in this case. in future, when we add more options to ip header we might need it. Position is the relative position w.r.t the field * JCZ: It seems logical, but we'll need more explanation in the text - it's for extensions, not for UDP/UP. * JCZ: Do we mention that this is the generic approach, or do we jump directly to IP/UDP? * ANA: we jump into ipv6/udp * JCZ: Add small paragraph in the intro. * ANA: Target value can be described as any type. also consider a cbor. LT: field ID indicates the type of the target value(Can be int, string..). * we dont have to mandate the cbor type. * PT: If Diego had a question during the review, then other people may also get confused. * LT: just read what is written in the draft. may be wordings "consider" can be changed? to "for instance" * ANA: last point of review: equal is a matching operator., matching between rule target value and the incoming packet value. * Diego: I understand the idea. The field value in the rule is not the TV? (clarify the meaning of the sentence) * LT: correct version would be "Field value in the packet match the target value in the rule" * LT: also do it for ignore, and other MO. * JCZ: If newer version going to available soon, if so I would like to work on it. * ANA: Make the correrction of the Diego's comment and send to JCZ. * AP: next week we can have JCZ review. * PT: Better to have a new version published * JCZ: Agree. I would rather work on the published version. * PT: Ana, please publish the changes from Diego's comments. BTW, we also need to check what can be done for the fragmentation. * [7:27] SCHC CoAP (Laurent) [15min] * LT: Used the last slides that were presented from IETF98 * Refresh the ideas of CoAP draft * LT: Not the goal of schc to reduce the size of the IDs. Proxy reduces the value nd the SCHC mechanism can apply * LT: in coap , we have the list of values; URI PATH that can be repeated several times. to reduce ambiguity we introduce position. position is mandatory for all the fields. * Deal with variable length, we do not know the lenght of the value.Value can change and the size also, we need to send the new size of we reduce the type * The asymmetric in CoAP is important the request and the reponse are different. We have move this asymetric to the general rules of SCHC compression draft that can be used for Hop Limit. As UPL and DWL * JCZ: similar to Diego's comments. * Ana: Thisis an input to the SCHC compression part of previous draft to divided in framework and IP/UDP compression * PT: Who is going to prepare the rules. What is dependent on device? Most of the rules could be done by the manufacturer/vendor of the rules. * PT: certain things depend on the deployment. How to put in the way the direction, * LT: If I said a variable-length representation, then it's going to be limited to CoAP. (?) * PT: Rules are comming from the vendor and not for the device, but may come with the deployment, how to describe a rule with a variable part, a part that can be added later * LT: to be as generic as possible. What said by pascal is related to provisioning of the device. currently just focussing on the mechanism. * LT ?? about comi?? *PT: ways to encode integer with unkown number of bits. *LT: coap way of representing length is very efficient. *AP: How to have flexibility, in the rule-ID on how we represent header information. * LT: we need it if we have ipatch. we may need it for oscoap as well.. yet to explore. * AP: Continue discussion on the ML * LT: Revieuw the draft is important but the one important thing is that all the options are described on the draft, if you want we can use block and we can fragment it. *AP: CB said there are complementary mechanisms, so no contradictions. * LT: working on Comi, would update soon if it is working or not. *LT: discussion of timer on the coap draft. similar needs to be done in the lpwa networks as it would impact the way we do the compression. *AP: Take up the further discussion on the Mailing List. * [7:42] SCHC Fragmentation (Carles) [15min] PT: Question on the ML about the fragmentation, need for a stable draft. Split the draft in two parts. PT: make another draft with the possible improvements. AP: Stable part with the window mode, and can be shipped today(almost). Would like to retain it here and move the other part to newer draft.? PT: is this decision to retain the Window mode OK, Carles ? Diego? Diego: OK! seems practical to keep the window mode. LT: more generic is the window mode and could work everywhere. also retain the unidirectional too, the one with the last msg as MIC. LT: Keep also the unidirectional mode and the MIC AP: Keep Window moe and Unidirectinal and then we can work on the other modes PT: Unidirectional there is not ambiguity so we can keep them and then we can work on the other modes PT: What do you think, JCZ? JCZ: Afraid to move so fast, and have an misunderstanding, it makes sense but perhaps we need to things more in details. PT: Remove mechanisms where you loose packets you do not know where you are, (packet mode) and only leave what does not have ambiguity We need time to solve the problem of renumbering when retrying. AP: agrees with PT. Reminder about Deadlines with Schc ip/udp. Window mode doesn't seem to have a problem. would consider splitting the draft keeping the window mode. Other non-ambiguous things can also be added. Unclear stuffs can be worked on a separate documents. LT: Do we do an interop in Prague AP: Put this also in the ML, * [7:57] AOB [ 3min] Chat room log -------------- http://etherpad.tools.ietf.org:9000/p/lpwan?useMonospaceFont=true from Pascal Thubert (Cisco) to everyone: http://etherpad.tools.ietf.org:9000/p/lpwan?useMonospaceFont=true from arunprabhu kandasamy (Guest) to everyone: I would like to know if we can have an interop for schc at Prague from Juan Carlos Zuniga (Guest) to everyone: http://etherpad.tools.ietf.org:9000/p/lpwan from Diego Dujovne (Guest) to everyone: thanks! from Stephen Farrell (Guest) to everyone: "LP-AAA server" from Matt Gillmore (Guest) to everyone: I like LPWAN-AAA from Juan Carlos Zuniga (Guest) to everyone: L-AAA fg from Carles Gomez (Guest) to everyone: I disagree about the ambiguity point... Look at my slide from Carles Gomez (Guest) to everyone: So, overall, I think Packet mode (without the recent suggestions) is stable as well from Carles Gomez (Guest) to everyone: The main point here is the trade-off with message cost in window mode from Carles Gomez (Guest) to everyone: I'd say let each implementer decide from laurent (Guest) to everyone: The thing is that what will be defined in the main standard does not block an evolution from Carles Gomez (Guest) to everyone: Large enough N means zero ambiguity :)