# Meeting Information {#meeting-information} ## LPWAN WG info {#lpwan-wg-info} * [Charter][1] * [Documents][2] * [ML][3] ## SCHC WG info {#schc-wg-info} * [Charter][4] * [Documents][5] * [ML][6] ## Data / Time {#data--time} * Date: Thursday March 28th, 2023 * Time: [1:00PM local, Wedneday 09:00PM US Pacific Time, 06:00AM CET, 12:00PM Shanghai][7] ## Meeting Information {#meeting-information-1} * Chairs o Pascal Thubert [pthubert@cisco.com](mailto:pthubert@cisco.com) (remote chair) o Alexander Pelov [a@ackl.io](mailto:a@ackl.io) (remote chair) o Laurent Toutain (remote delegate) o Carles Gomez Montenegro (invited sitting delegate) * Responsible AD o Éric Vyncke * Room: [G314-G315][8] * Agenda: [on datatracker][9] * Meeting documents: [on datatracker][10] * Meeting material: [on datatracker][11] * Meeting link: [Meetecho Link][12] * Live Minutes: [CODIMD Link][13] WG Meeting Agenda ----------------- \### \[1:00PM\] Administrivia \[15min\] * Presenter: Alexander Pelov * Note-Well, Scribes, Agenda Bashing * WG / drafts Status * Intro to the new SCHC WG / transition plans \### \[1:15PM\] SCHC Streaming Mode (new work) \[15min\] * Associated draft: draft-aguilar-lpwan-schc-streaming-00 * Presenter name: Sergio Aguilar Romero * Objective of the discussion: Present the new SCHC Streaming ode and get feedback from the WG \### \[1:30PM\] Session Initiation and Rule exchange (new work) \[10min\] * Associated draft: None yet * Presenter name: Sergio Aguilar Romero * Objective of the discussion: Present a proposal of new SCHC Messages for Session Initiation and Rule exchange between nodes and get feedback from the WG \### \[1:40\] Updating RFC 8824 (new work) \[20min\] * Associated draft: draft-tiloca-lpwan-8824-update-00 * Presenter name: Marco Tiloca * Objective of the discussion: Present the new work; discuss proposed errata; ask for feedback \### \[2:00\] SID Allocation \[20min\] * Associated draft: draft-toutain-lpwan-sid-allocation * Presenter name: Laurent Toutain * Objective of the discussion: initiate the discussion on how the group will manage its futur range of SID values \### \[2:20\] SCHC Access Control \[10min\] * Associated draft: draft-toutain-lpwan-access-control * Presenter name: Laurent Toutain * Objective of the discussion: see if it can become a working group item \### \[xxxx\] AOB \[QS\] WG Meeting Minutes ------------------ \### \[1:00PM\] Administrivia \[15min\] * Presenter: Alexander Pelov * Note-Well, Scribes, Agenda Bashing * WG / drafts Status * Intro to the new SCHC WG / transition plans Meeting starts Pascal: Agenda bashing nb-iot is in RFC Editor state Sigfox documents - in the queue - very close to RFC Architecture documnet will be transferred to the new SCHC Working Group SCHC over PPP was developped at Intearea, now into SCHC WG The LPWAN documents that are in the RFC editor queue will remain LPWAN - the others should move to SCHC If you have a good reason to retain a document LPWAN we can discuss it Laurent: in the OAM draft, there is some text about constrained devices/networks. How is this handled - should we add text about that or keep it in LPWAN? Pascal: do we want to keep the LPWAN WG active? Éric (resp. AD): OAM is already part of the new SCHC WG charter. Éric: the SCHC ZG charter includes maintaining the LPWAN WG docuements, so no new adoption call needed for documents that were already adopted by LPWAN WG Éric: right, you may want to qualify "constrained" or "non-constrained" in the text if you have both situations Pascal: if your use case is LPWAN, just write that in the text Pascal: presenting the SCHC Charter Pascal: we already have some deadlines we are late about - adoption of SCHC-PPP Alex: technology gaining traction around the world. * IEC (electric meter data exchange). * SCHC certification at the LoRa Alliance. Pascal: authors of individual documents, please republish as draft-name-schc- \### \[1:21\] SCHC Streaming Mode (new work) \[15min\] * Associated draft: draft-aguilar-lpwan-schc-streaming-00 * Presenter name: Sergio Aguilar Romero * Objective of the discussion: Present the new SCHC Streaming mode and get feedback from the WG Sergio introduces a new draft on streaming Reliable data stream using fragmentation. Sensor measurments, location coordinates, continues stream of compessed and unfragmented SCHC packets. Some technologies have large MTUs and do not require fragmentation, but reliability. Explains the way Windows and DTags are cycling / wrapping. Proposing a Successful SCHC ACK to close the DTag cycle. Pascal: how is a (Window#, DTag#) pair, 1 bit each, different from a Window# of 2 bits and no DTag#? Sergio: similar behavior. DTag# allows for a larger stream option. Alex: does DTag delimit the packets? Ivan: in this case, one stream packet per window (????) Alex: using the compound Ack to ACK multiple windows Sergio: if compound Ack not used, will need one Ack per window example later in the slides. Compound Ack at the end of Window cycl is optional. Juan Carlos: ACK is decoupled from the end of the window. Asynchronous, let you go with the stream. Sergio: the lifetime of the ACKs is determined by the DTag cycle Could no do this without the comppound Ack Pascal: if 2 bits for Window#,how is it different? Sergio: fewer downlink opportunities Pascal: couldn't you have said you can Ack asynchronously. Not necessarily with compound Ack Sergio: allows to go back and recover... Alex: let's have a focussed discussion on this. JCZ: also need to pay attention to bitmap size Laurent: DTag is a way to not replicate rules Laurent: here, DTag is used as extension of RuleID, radical change from the way DTag was used so far Alex: other question, what happens if you lose two windows? Sergio (resuming presentation): stream closed with All-1 Alex: I like the initial proposal. Would propose one DTag per fragmented packet. Sergio: if one fragment per packet, a lot of ACKs \### \[1:41PM\] Session Initiation and Rule exchange (new ork) \[10min\] * Associated draft: None yet * Presenter name: Sergio Aguilar Romero * Objective of the discussion: Present a proposal of new SCHC Messages for Session Initiation and Rule exchange between nodes and get feedback from the WG Sergio: New message to start SCHC instance, including exchanging the rules. Could be useful for OAM. Rules CBOR encoded, according to YANG and Coreconf. Rules can be updated. Laurent: does it mean sending the rules everytime a SCHC instance is initiated? Pascal: in schc-over-PPP, a URI is passed to where to retrieve the rules Pascal: PPP has a session, no need to recreate it. Will see how to harmonize this. Alex: what is the life cycle of SCHC instance? E.g., one instance boots, establishes session, then reboots. How does the other end know? Alex: question to Pascal, where should this be described? Pascal: this should be described in the architecture document. \### \[1:49\] Updating RFC 8824 (new work) \[20min\] * Associated draft: draft-tiloca-lpwan-8824-update-00 * Presenter name: Marco Tiloca * Objective of the discussion: Present the new work; discuss proposed errata; ask for feedback Marco: read the CoAP RFC with fresh eyes. Marco: spell out how to handle payload marker, CoAP options newer than RFC8824 Ana: recommend to keep SCHC terminology, target\_value "not set" instead of "empty" Marco: presenting some of the options. Step by step descriptions for some cases (e.g; proxies) Pascal: dont necessarily need to compress on one leg, e.g, if proxying to HTTP Marco: that's right. Marco: coment from Carles: 15.4 can be run without security, could benefit from SCHC. But 8724 REQUIREs security at L2. Relax that? Éric: if you relax it, then the security AD will probably ballot a "DISCUSS" as on the first versions of RFC 8824 Marco: Laurent has started a new YANG model (https://gitlab.com/crimson84/draft-tiloca-lpwan-8824-update/-/blob/main/ietf-schc-coap@2023-03-07.yang), but it is good to have a mechanism to handle future CoAP options. We'd like future specifications defining/updating CoAP options to also define/update how SCHC handles those options. Éric: As an AD. Is it an update or a -bis? Update is "OLD TEXT, NEW TEXT", -bis is standalone new text. It depends on the amount of patches. Marco: it started as an idea as an update. Éric: it may depend of the evolution of CoAP. Is CoAP fixed, or is it going to evolve in the years? Marco: it's not probable to evolve too much. John Mattson: very good work. Would recommend a bis, so that all information in one place. Christian (on chat): That looks like very good clarification to me, these things were unclear to me when reading SCHC but I couldn't frame them this sharply. Quentin: can do compression of CoAP options without expliciting them all. Implementation in microschc. Treat each field as generic, including delta, etc. Quentin: IOW, there is a way to compress CoAP without having to redefine everything every time a new option is added. Marco: please follow-up on the mailing list Quentin: will do. Was discussed with the group in the past. Ana: "not set" vs. "not-send", was editorial error at some point. "not set" is correct. Marco: This was about the value of TV. So, TV should be "not set" instead of "empty". Correct? Ana: Yes. Pascal: we'll have a dedicated session during an interim to discuss each errata, we need to move on for this meeting. Ana: Observe is not an extension, it's an option. Marco: it's a protocol extension, enforced by an option. The alternative, new phrasing at the end of the slide would be better, and would put the focus on the real user of the RST message, i.e., the CoAP client. Pascal: we'll make sure to invite Marco to the next interim. \### \[2:13\] SCHC Access Control \[10min\] * Associated draft: draft-toutain-lpwan-access-control * Presenter name: Laurent Toutain * Objective of the discussion: see if it can become a working group item Laurent: all element in the rules are RW. In YANG there is possibility to add Access Control to some elements - but it's related to controlling a "column". We want to provide control over a "row". Also, to control the access to a single element, or to add a new rule. Pascal: did not mention priority of the rules. Can insert a rule, but what if tow rules can compress the same packet? Laurent: priority not specified, except rule that gives better compression should be selected. Pascal: inserting means you can overwrite an existing rule, this is an open door for any attack. Should be able to protect an existing rule from being superseeded by another, new, one. Pascal: a priority would provide this protection. Laurent: inserting a new rule is for better matching, thanks to acumulated knowledge about the traffic. Pascal: it's an attack vector Laurent: don't think it's an attack vector Laurent: vision of SCHC compression rules as hierarchy (some wide-addressing rules, some more specific rules), not a tiling of the space Quentin: could forge a compression rule that matches everything and sends nothing. Very good compression ratio but useless, except for an attack! Alex: sec framework could be that flow is not changed, still goes to same destination. The compression/decompression is a "transparent" operation. Pascal: this is a security document, since we are talking about access control. We have to consider all the security aspects of what we are doing. Laurent: Laurent: note regarding the architecture. We need to identify the session, then the set of rules, then the instruction should be applied. Quantin: modifying timers could be a large attack vector. It seems to be very dangerous. Laurent: if you have very few devices you can send more.. Pascal: ... before we adopt I'd rather have a clear position on security Laurent: one scnenario .. set the flow label Pascal: chartered for changing specific fields. But inserting new rules, very dangerous. Think we'll adopt because need to control field updates anyway, but we need a clear stance vs what can be done. Alex: agree, need to describe scenarios of update \### \[2:xx\] SID Allocation \[20min\] * Associated draft: draft-toutain-lpwan-sid-allocation * Presenter name: Laurent Toutain * Objective of the discussion: initiate the discussion on how the group will manage its futur range of SID values SID allocation will be discussed at next interim, no time left. \### \[2:31\] meeting adjourned [1]: https://datatracker.ietf.org/wg/lpwan/about/ [2]: https://datatracker.ietf.org/wg/lpwan/ [3]: https://www.ietf.org/mailman/listinfo/lpwan [4]: https://datatracker.ietf.org/wg/schc/about/ [5]: https://datatracker.ietf.org/wg/schc/ [6]: https://www.ietf.org/mailman/listinfo/schc [7]: https://www.worldtimebuddy.com/?qm=1&lid=5392171,1848354,2988507&h=1848354&date=2023-3-30&sln=13-14.5&hf=1 [8]: https://datatracker.ietf.org/meeting/116/floor-plan?room=g314-g315 [9]: https://datatracker.ietf.org/meeting/116/agenda [10]: https://datatracker.ietf.org/meeting/116/agenda/lpwan-drafts.pdf [11]: https://datatracker.ietf.org/meeting/116/agenda/lpwan-drafts.tgz [12]: https://meetings.conf.meetecho.com/ietf116/?group=rasprg&short=rasprg&item=1 [13]: https://notes.ietf.org/notes-ietf-116-lpwan