# Meeting Information {#meeting-information} ## WG info {#wg-info} * [Charter][1] * [Documents][2] * [ML][3] ## Data / Time {#data--time} * Date: Friday November 11th, 2022 * Time: [12:00PM local, 04:00AM US Pacific Time, 13:00 CET, 8:00PM Shanghai][4] ## Meeting Information {#meeting-information-1} * Chairs o Pascal Thubert [pthubert@cisco.com](mailto:pthubert@cisco.com) o Alexander Pelov [a@ackl.io](mailto:a@ackl.io) * Responsible AD o Eric Vyncke * Minutes takers o Sergio o Ivan * Room: [Kensington 1][5] * Agenda: [on datatracker][6] * Meeting documents: [on datatracker][7] * Meeting material: [on datatracker][8] * Meeting link: [Meetecho Link][9] * Live Minutes: [CODIMD Link][10] ## WG Meeting Agenda {#wg-meeting-agenda} 
### [12:00] Administrivia                            [15min]
* Presenter: Alexander Pelov
* Note-Well, Scribes, Agenda Bashing
* WG / drafts Status / NB-IOT
* Intro to the need for rechartering


### [12:15] Rechartering [15min]
* Presenter: Chairs
* Topics: Review proposed work items

### [12:30] SCHC Convergence Profile (new work) [10min]
* Associated draft: draft-aguilar-lpwan-schc-convergence
* Presenter: Sergio Aguilar
* Topics: Present new work.

### [12:40] Need for IDs - Impact on Architecture [45min]
* Associated draft: draft-ietf-lpwan-architecture
* Presenter: Chairs, Laurent Toutain
* Topics: Open Mike on need for IDs and their management

### [13:25] AOB [QS]
## WG Meeting Minutes {#wg-meeting-minutes} ### \[12:00\] Administrivia
\[15min\]
{#1200-administrivia----div-styletext-align-right15mindiv} * Presenter: Alexander Pelov * Note-Well, Scribes, Agenda Bashing * WG / drafts Status / NB-IOT * Intro to the need for rechartering Ivan and Sergio are taking the minutes Agenda presentation New item in the agenda: Dominique about the Hackathon. AP : The schc over sigfox and compound ACK we are almost there. For Compound ACK, We're waiting for lastest version SA: Compound ACK, It is ready, and I think it is already on the data tracker Ana: Waiting the end of the last call, She can press the button Chairs: push the button. Chairs: YANG data model is in the editor queue, thanks for the authors Chairs: NB IoT, it is really advanced, the liaiseon is Pascal: I've never seen a document going smoothy to the ISG Eric: during the 3GPP-IETF coordination on Tuesday, it was well received, for the work to be done at 3GPP, companies have to send a SID/WID to 3GPP Eric: wait to the end of November to see how to do the informative parts and the normative part as 3GPP meets next week and a 3GPP review will be done. AP: Is there any interest to continue on OAM? DB: I'm interested to continue this work! PT: Regarding the architecture, and how SCHC works over any type of connectivity. Session is accepted in the model. This session is implicit for LPWAN. In on a more diverse type of networks, there is a need for revisiting the definition of session since it is not implicit. Bob: I did a comment about this draft the security secction is incomplete, indication when security is below transport. It should be added to the architecture. PT: When it is over LPWAN was considered, over foo it is not. ### \[12:15\] Rechartering
\[15min\]
{#1215-rechartering--div-styletext-align-right15mindiv} * Presenter: Chairs * Topics: Review proposed work items PT: Documents are moving forward, and it is time to recharter, do not hesitate to come to the mic and say what subjects are you interested on. Discover a lot of new foos. SCHC (compression) over 15.4 in 6lo. PPP in interea, probably better here. Any interest in SCHC over foo JCZ: Depending the scope beyong LPWAN. Does the rechartering wants to change the group name. Eric: it is logical, but in the past another group wanted to do the same but it was not possible beacause of the datatracker. I will check again. PT: New message for handling message lost. Send more bits than needed in case are lost. Bob: not instead but in addition. Pascal: Rename to HARQ PT: SCHC Header, In interea ether type Bob: IP protocol number, Ether type, and UDP port number are in intarea and will progress PT: we may need SCHC as an extention header. LT: To have a protocol number, it is good because it can work on IPv4 and IPv6 Bob: Adding SCHC in an extension header, raise a lot of negative comments in intearea, they're very much for protocol number. Eric: we can discuss here but it is an inearea draft PT: Let's discuss in the mailing list Bob: we need uses cases to support it (UPD port and ether type) PT: this is not an intera work, we need to figure out whay would be carried, thats why we need the rechartering Bob: we don't need session id because it's implicit PT: SCHC Instance between devices. PT: Session Setup: since we're moving from LPWAN to other topologies, we need to figure out how to download the same set of rules and instantiate for example the IP address. AP: We have goten those question many times in the past, the answer was that we'll solve in the future, I think we have now the knowlege to answer. CORECONF over SCHC. LT: Security is very important, here we have different bullets to be really explicit in the architecture PT: we need to update the security section of the architecture. Bob: With regard to the negotiation of the rules, there is a draft in IKE on how to negociate rules. IMHO We should do in in a P2P way, not client and server. AP: Both peers can have the server and client PT: Any comment on more items, we need to have the feedback before starting to write the rechartering. LT: For the YANG model, it is not only about optimization but also extention ### \[12:37\] SCHC Convergence Profile (new work)
\[10min\]
{#1237-schc-convergence-profile-new-work--div-styletext-align-right10mindiv} * Associated draft: draft-aguilar-lpwan-schc-convergence * Presenter: Sergio Aguilar * Topics: Present new work. SA: update of the draft, it started as an individual submission. LT: thanks for the initiative, I like the fact of having more open implementations, but for a very very constrainded end devices, we migth wont to have the devices not having to handle directly the rules. So, for example we can have an implemntation with very little code. PT: The two foo that you have might not survive in the long term, that might be the strong part of your proposeal, are you planning to have something more generic for other Foos SA: There have to be an adaptation for different traffic profiles, for instance there is a part on the draft addressing downlink Bob: other techs with more traffic, that might be a good example and that's exactly what I'm working on. Bob: as examples of foos, 802.16, 802.11.ah with high traffic. Compression helps reducing collisions. AP: At the beginning of the group we have the idea of having a minimal rule (of convergence profile if you will) for different technologies. I'm not sure how's is going to be working, if I underenstant well, both are different to what you propose, so it'll be complicated to add this new profile. LT: do you plan to consider mobility in this scenario SA: since we can send on different nets yes, LT: is more related to the IDs SA: We're proposing a single ID for all thechnologies, that can help us with the convergence and with a device moving from one technology to another for instance. AP: We need to look at your draft regarding the session stablishment for this convergence profile. ### \[12:50\] Hackaton
\[45min\]
{#1250-hackaton--div-styletext-align-right45mindiv} * Presenter: Dominique Barthel * Topics: Feedback of the DB: Ivan an Laurent work on cleaning the OpenSCHC repo, micropython implementation, sergio working on the interconection to the new sigfox network server to openSCHC, Ivan and Laurent also work with Martine Landers to set up a connector with LibSCHC for ICMP traffic. AP: Amazing work in this 5 years of Hackathon. ### \[12:59\] Need for IDs - Impact on Architecture
\[45min\]
{#1259-need-for-ids---impact-on-architecture--div-styletext-align-right45mindiv} * Associated draft: draft-ietf-lpwan-architecture * Presenter: Chairs, Laurent Toutain * Topics: Open Mike on need for IDs and their management LT: I'll also sumarize what was said on the side meeting yesterday LT: We have to merge all the inputs we get from the reviwers of the YANG DM in the architecture draft. LT: We would also like to extend this work to OAM and Compound ACK. CORECONF a compact way of the YANG model. LT: How to protect elements of the rules to avoid devices to change fields if it does not have the rigths. LT: currently you have protection to access specifics field. Each field will have a specfic id in yang, or number in CORECONF. Same column, same id, same number. A colunm is write only or read and write. LT: In SCHC we will like to have something more precise, we can imagine an attack where a device is compormised and change the address to another device. LT: Improve or augment the security we have in YANG DM. Device can only manipulate its own information, not of other devices in the core. Device only send messages for its own representation. AP: That was a very interesting discovery, we want to have the same level of securty as if the device had the full IPv6, we can imagine also a case where a device can push malicious rules to the system. Thats something we do not want to allow. PT: We start disussing it on the side meeting, my view is that you need to identify first the session and then match the rules, NOT the other way, if not there is no way to filter traffic. The problem is when the packet arrives from the internet, not in the compressed form. LT: we dont want to add any new feature but to be used as in the internet, we also need to define the way this reconfiguration of devices is done, maybe CORECONF for constrainded end devices?, maybe another level of encryption?. LT: Now, for the mesh topology: nodes that talk to othe hosts useing SCHC. You can have several cores, you can say A is a device and B core, there is a problem with C, because it can be core or dev. According to Ivan draft, you cannot have the same rule for both direcctions. It is static, depends on the information of the rules, if dinamic, a new protocol will be required to identify dev or app. we need to look to solutions in the arquitecture document. PT: SCHC instance (is a session between dev and app), number of cases where the session identification is implicit, no session negotiation, nor identification. LoRaWAN you can have the device id. Bluetooth, the server can be app. When we start a PPP connection, the device start the communication. There cases like mesh, it can be implicit or not. Need of a secure negotiation protocol AP: Thank you everyone, see you at the next IETF and the interm meeting. PT: Meeting adjourned ### \[13:25\] AOB
\[QS\]
{#1325-aob--div-styletext-align-rightqsdiv} [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://www.worldtimebuddy.com/?qm=1&lid=2643743,1796236,12,5391959&h=2643743&date=2022-11-11&sln=12-13.5&hf=1 [5]: https://datatracker.ietf.org/meeting/115/floor-plan?room=kensington-1 [6]: https://datatracker.ietf.org/doc/agenda-115-lpwan/ [7]: https://datatracker.ietf.org/meeting/115/agenda/lpwan-drafts.pdf [8]: https://datatracker.ietf.org/meeting/115/agenda [9]: https://meetings.conf.meetecho.com/ietf115/?group=lpwan&short=&item=1 [10]: https://notes.ietf.org/notes-ietf-115-lpwan