LPWAN Interim 5 / 2022

Data / Time

• Date: March 8th, 2022
• Time: 7-8am US Pacific PST, 4pm CET

Meeting Information

• Agenda: on datatracker

• Meeting material: on datatracker

• Meeting link: Meetecho Link

• Live Minutes: CODIMD Link

Last Meeting To Do's

• Carles: review the NB IOT draft by Vienna

• Chairs: Assess whether NB IOT is ready for WGLC in Vienna

• Chairs: call for adoption of the Yang Data Model draft

Interim Agenda

[16:05] Administrivia [15min]

• Note-Well, Scribes, Agenda Bashing
• WG Status
• IETF agenda and presence

[16:20] Data Model WGLC [05min]

• open discussion

[16:25] "Dev and App for SCHC HC over 802.15.4" [20min]

• open discussion

[16:45] Shepherd Review on Compound Ack [10min]

• open discussion

[16:55] AOB [ QS ]

Minutes

[16:05] Administrivia [15min]

• Note-Well, Scribes, Agenda Bashing
• WG Status
• IETF agenda and presence

Pascal: Introduction, Note-well, etc.
Action items review
Carles to review NB-IoT draft. To be discussed at IETF113.
WGLC on Yang Data Model is running. Please review it. No need to review for full completeness, but at least for items that may affect specific documents / behaviors.

SCHC-over-NBIOT to be presented in Vienna.
Ana: overview on the SCHC-over-NBIOT document. Reviewers are needed to go for last call. (Carles is doing a review, any other volunteer is welcome)

IETF113, chairs remote.
Eric: there is a training, Pascal, Alexander, Laurent - you may want to look at it.
Dominique has followed the training (for ROLL). The main recommendation for the person sitting in the room is to make sure walk-ins connect to the session using the "light client" Meetecho link, so that they are registered in the blue sheets but do not send audio into Meetecho. The room is equipped with cameras and microphones, which take care of audio and video for in-person participants.

[16:20] Data Model WGLC [05min]

• open discussion

• asking for reviews

[16:25] "Dev and App for SCHC HC over 802.15.4" [20min]

• open discussion
• Carles reminds the problem of assigning roles dynamically for dev and app
• Read a preference to keep the roles as defined, less impact on specs including Yang
• Might have problems with intermediate nodes if hops apart. Would they uncompress at each hop?
• Dominique asks why not define new CDAs for source and destiantion
• Carles: that was original idea but group seems to disagree. We might want to use rules birectionally.
• Dominique: could overload Up/Down to mean Initiator/Recipient, so that rules can be shared as well.
• • Laurent: In openSCHC we have the rule and then devid that is associated to the rule. TRules are the same in dev and app. In app the device ID is not owner, in device it is. The
• Alex: on mesh, second hop does not know DevEUI of the sender
• Pascal: two ways to look at it: route over, IP layer compressed or not. ...
• Pascal: see RFC8931, fragment forwarding. Labeled path.
• Alex: on one-hop, we can say Dev is sender, App is the receiver.
• Laurent: if application compressed, not UDP/IP, then no problem.
• Laurent: CoAP is asymmetric, no problem.
• Alex: You can share all RuleIDs in a mesh network, and all IP addresses. Then, use this information on every hop in order to forward the packets.
• Carles:
• Pascal: thinking about it, don't like the idea of doing multihop with SCHC-compressed packets. For mesh, stick to 6LoWPAN for IP and SCHC for ULP.
• Laurent:
• Carles:
• Pascal: in mesh, in order to compress IP, you need to distribute all IP addresses as part of the context. Does not fly.
• Pascal: Dev and Appp need to be described in architecture draft. And, for peer-to-peer, we can explain how they are re-used.

[16:45] Shepherd Review on Compound Ack [10min]

• Pascal pastes his review into the chat window
• this draft extends 8724, therefore it needs the "updates" tag and some text to explain how it extends.
• Eric: Mirja's draft should not be considered <????>
• Pascal: the whole topic about "update" is very confusing.
• Dominique: so the compound ack feature will become part of SCHC. But it is optional or mandatory?
• Old text seems to have been missing behavior description, that was implicit but hsould have been explicit.
• New text could do both: clarify that text was missing, and add new behavior on top of it.
• JCZ will prepare new revision and publish on first day of IETF113 meeting.
• open discussion

[17:00] meeting ajdourned