# Minutes of the SCHC meeting at IETF 118 (Prague)   {#minutes-of-the-schc-meeting-at-ietf-118-prague}

### SCHC   {#schc}

*   [Charter][1]
*   [Documents][2]
*   [ML][3]

## Meeting Information   {#meeting-information}

Ser

The joint SCHC session will take place during Thursday Session IV on Nov
9th, 2023; that's from 17:00 to 18:30 local time (CET == UTC+1). The
meeting will take place in rooms Berlin 3/4.

### Date / Time   {#date--time}

*   Date: Thursday Nov 9th, 2023;
*   Time: [17:00 local time (CET), 8:00AM Pacific, 11:00AM Eastern,
    Midnight 0:00 China][4]

*   Chairs  
     o Alexander Pelov
    [alexander.pelov@imt-atlantique.fr](mailto:alexander.pelov@imt-atlantique.fr)
    (in-person chair)  
     o Pascal Thubert
    [pascal.thubert@gmail.com](mailto:pascal.thubert@gmail.com) (remote
    chair)  
     o Laurent Toutain (in-person delegate)

*   Responsible AD  
     o Eric Vyncke

*   Room: [Berlin 3/4][5]

*   Agenda: [on datatracker][6]

*   Meeting documents: [on datatracker][7]

*   Meeting material: [on datatracker][8]

*   Meeting link: [Meetecho Link][9]

*   On-Site tool: [Meetecho Link][10]

*   Live Minutes: [CODIMD Link][11]

## WG Meeting Agenda   {#wg-meeting-agenda}

### \[17:00\] Administrivia \[20min\]   {#1700-administrivia----------------------------20min}

*   Presenter: Alexander Pelov
*   Note-Well, Scribes, Agenda Bashing
*   WG / drafts Status
*   IP protocol Number and Ethertype (INTAREA)

sergio: on the stream draft, FEC can be included  
Pascal: Bob also works on that  
IP Protocol Number: move from IntArea to SCHC WG

### \[17:20\] AOM reborn \[5min\]   {#1720-aom-reborn-5min}

*   Associated draft: draft-barthel-schc-oam-schc
*   Presenter name: Laurent Toutain
*   Objective of the discussion: Update of the OAM draft, discussion
    around the "Action" introduced by the document. become a wg itemn

Laurent: YANG DM for SCHC ICMPv6 Payload may be viewed as a field  
Laurent: Function to generate payload with a given size  
Laurent: Add definition of an Action  
Laurent: How to generalize Action ?

### \[17:25\] Updating RFC 8824 \[15min\]   {#1725-updating-rfc-8824--15min}

*   Associated draft: draft-tiloca-schc-8824-update
*   Presenter name: Marco Tiloca
*   Objective of the discussion: Update of the draft, now written as a
    bis document intended to obsolete RFC 8824

Marco: Obslolete RFC8824 as accept in previous meeting. Take the
original content with clarification and new things.

Section 5 focuses on CoAP options, with new recent options   
New section 7 on compression of CoAP Payload marker

Section 10 introcduction of proxies

move some part to the architecture document.

Ready for WGA?

"Show hands" shows no objections for adoption.

### \[17:40\] SCHC Access Control \[10min\]   {#1740-schc-access-control-10min}

*   Associated draft: draft-toutain-schc-access-control
*   Presenter name: Ana Minaburo (remote)
*   Objective of the discussion: Update of the draft, introduced the
    permission of changing the FID and the TV

SCHC Field Descriptors: TV can be updated,   
Repeatable fields can be updated like uri-path

The draft lists the FID that can be updated.

Marco:Uri-port can be r/w

Ana: WGA

Pascal: discuss for a while, we are pretty close to adaption.

Maryam: what are the number of context in a rule.

Poll: adoption

### \[17:50\] SCHC Flow Compression \[10min\]   {#1750-schc-flow-compression-10min}

*   Associated draft: draft-minaburo-schc-flow-compression
*   Presenter name: Ana Minaburo (remote)
*   Objective of the discussion: Introduce the problem of flow
    compression with SCHC. How to manage to update the Rules during the
    flow transmission.

Ana: how to compress flows  
Ana: derive rules from a rule with more specific values.  
Ana:   
Edgar: can we do this with additional operations instead?  
Laurent: it is important to keep both context the same  
Alex: see example, for the next time.

### \[18:00\] Zero Energy Devices \[10min\]   {#1800-zero-energy-devices-10min}

*   Associated draft: draft-ramos-schc-zero-energy-devices
*   Presenter name: Edgar Ramos
*   Objective of the discussion: The need to use SCHC for large packets
    (not IP) delivery in an intermittent.

Edgar: Zero energy devices   
Types of ZE devices (3GPP) - A (no energy storage), B (small energy
storage, no ind. signal generation), C (energy storage, independent
signal generation)  
Focus on Topology 1 initially to make sure we know how to do it. Address
the other topologies when it is clear Top 1 can be addressed  
Typically, your IP address is changed after 30 minutes of inactivity in
cellular network  
Use SCHC as some kind of a "transport" protocol  
Alexander: support the work, very interesting use-case, may be applied
to satellite comms (IOT or others), such as in NTN  
Maryam  
Juan-Carlos: support 100% the effort, there is a similar effort in IEEE
802.11 group  
Sergio: working with satellite communication, present a rule exchange in
a previous meeting, work can be done.  
Sandra:

### \[18:10\] SCHC architectural proposal \[15min\]   {#1810-schc-architectural-proposal--15min}

*   Associated draft: draft-ietf-schc-architecture
*   Presenter name: Laurent Toutain
*   Objective of the discussion: Discuss a SCHC architectural proposal
    including management feature and SCHC Header

### \[xxxx\] AOB \[QS\]   {#xxxx-aob-qs}

# Minutes   {#minutes}

## \[17:00\] Administrivia \[20min\]   {#1700-administrivia----------------------------20min-1}

*   Presenter: Alexander Pelov
*   Note-Well, Scribes, Agenda Bashing
*   WG / drafts Status
*   IP protocol Number and Ethertype (INTAREA)

AP doing introductions.

AP: Documents advanced well before the summer. The architecture document
and the document on SCHC over PPP had expired and have been revived. We
plan to focus also on the access control draft and on updating RFC 8824.

SA: Update on two of the drafts, straming with FEC

PT: Keep Bob Moscovitch in the loop. He is the one who introduced the
idea of FEC as an alternate to ARQ in SCHC fragments.  
AP: Bob is also working on other documents and asked for some help with
the SCHC rules and the DTLS part. We should set up a meeting with him.

AP: Question about protocol number, should it be in intarea? Agreement
about moving it to SCHC.  
EV: Better if the authors submit a new version with a new draft name
with -schc, that facilitates approval and pushing the buttons.  
AP: We'll tell the authors. The future WGLC in SCHC will also have to
involve the INT area.

## \[17:20\] AOM reborn \[5min\]   {#1720-aom-reborn-5min-1}

*   Associated draft: draft-barthel-schc-oam-schc
*   Presenter name: Laurent Toutain
*   Objective of the discussion: Update of the OAM draft, discussion
    around the "Action" introduced by the document. become a wg itemn

LT: Last version is a stable version.

*   Changes intro as Bob suggest and other minor changes.
*   Two parts: 1. Comp. IPv6, 2. Constrained Networks
*   1.  Includes 4 optimizations:
        *   Device pings
        *   Devices are pinged : new function "Global action". It
            decides if the compression is donde or not
        ^
        
        *   Migh be a confusion with CDA, but it actually applies to the
            whole packet

LT (p5): overview of the work lifetime across the different document
names. This started in October 2017.

CG: You're thinking to add compression for IMPv6, that's interesting and
useful in other documents, e.g., in 6lo.

LT: we don't work directly on Network dicovery but it can be indeed used
for it.

AP: Didn't we discuss and announce already about having this as a WG
item? The Datatracker says that it was adopted.

PT: I don't remember if we sent call on the ML, but it's on the
datatacke.

## \[17:25\] Updating RFC 8824 \[15min\]   {#1725-updating-rfc-8824--15min-1}

*   Associated draft: draft-tiloca-schc-8824-update
*   Presenter name: Marco Tiloca
*   Objective of the discussion: Update of the draft, now written as a
    bis document intended to obsolete RFC 8824

MT: Updates of RFC 8824  
MT: v02, is intended to be a bis, since no objections on last IETF.  
MT: No changes on the title.  
MT: Minor fixes, clarifications and editorial revisions.  
MT: New content from v01: Hop-limit, Echo, Request-Tag, EDHOC. Includes
new options from the first version of 8824.  
MT: Section 6 CoAP Extensions, Section 7 Payload Marker, Section 8
Example from 8824  
MT: Section 9 CoAP Header compression with Proxies, Sec. 10 Example  
MT: Add contect to link it to the AC draft.  
MT: Adoption?

AP: Lot of work thanks!  
PT: I agree we shall make this call.  
LT: I agree, I have a concern about KUDOS (Key Update for OSCORE)?, Is
there a risk?  
MT: Procedurally, there is a chain of dependences. But timewise, but I
believe that KUDOS will be finished when this work is ready.

Show of hands "8824bis adoption":  
 - yes: 14  
 - no: 0  
 - no opinion: 5

PT: We will confirm on the mailing list.

## \[17:40\] SCHC Access Control \[10min\]   {#1740-schc-access-control-10min-1}

*   Associated draft: draft-toutain-schc-access-control
*   Presenter name: Ana Minaburo (remote)
*   Objective of the discussion: Update of the draft, introduced the
    permission of changing the FID and the TV

AM: Updates from v02:  
 - TErminology Sec.  
 - Descriptors (FD) that could be modified  
 - Actions of the FD

AM: We dicovered that in some cases depending on each protocol,
modifying the TV is not practical.

AM: FD: Repeateble fields in CoAP for instance.

AM: We created some tables where we give "Access Control" TV and TV
default values for each field that has been standardized. We start with
CoAP, but we still have some questions about the fields as we don't know
very well WoAP.  
MT: The entry for the CoAP option Uri-Port says "Read-Only" for "Access
Control TV". Is that intentional? Other fields about the URI-related
options are all Read/Write.  
AM: We only put the repeatable fields.  
AM: We put all the extension of CoAP.  
AM: Adoption?

PT: We have discussed this AC for a while, we're pretty close to
adoption?, I believe we doo need it,   
AP: I agree, do we need oter WG to be involved?  
AM: The second part will be for IP.  
LT: What is not clear now, what has to be in the AC document, and what
in the architecture.  
AP: My opnion is that AC will be here, and seurity and attacks in
another document, both different from the architecture, if not it will
delay us in the architecture.

PT: For me it is not contradictory.  
PT: Let's explain which components can do that and that both side of the
conversations have to be updated at the same time, to ensure
consistency. It's not for the architecture, which should just give the
big picture.

MH: I'm doing research in ..., we have different codes in the CoAP
header to say that there are som error for example, will this be
considered.

AM: In slide 6, the CoAP codes are taken from a registry, when you
describe your rule you can compress it regardless if it is read/wrire or
read only

AP: Adoption?

Show of hands "adoption of SCHC ACL"

*   yes: 10
*   no: 0
*   no opinion: 13

AP: Good support, we'll bring it to the mailing list.

## \[17:50\] SCHC Flow Compression \[10min\]   {#1750-schc-flow-compression-10min-1}

*   Associated draft: draft-minaburo-schc-flow-compression
*   Presenter name: Ana Minaburo (remote)
*   Objective of the discussion: Introduce the problem of flow
    compression with SCHC. How to manage to update the Rules during the
    flow transmission.

AM: We want to give guidelines for compressing headers of new flows, for
any flow-based protocol. There are interdependencies between packets
within the same flow that we can take advantage of for compressing. That
is turn might require a dynamic update of rules.

AM (p4): Described high-level rationale considered for the compression.
Access control is involved in the possible update of rules.

AP: How do you actually execute the action? Is it a function? How is it
on the wire?  
AM: It's a rule defined in the action, to be used for a flow.  
AP: So if you use a rule, this specifies something else to additionally
do like deriving a further new rule. You can have two identical rules in
terms of compression, but one of those can additionally trigger an
action. Correct?  
AM: Yes, it comes in the next slide 6.

AM (p6): Discussed example with a flow and derivable action  
LT: This management has to be atomic, both sides must have the same set
of rules. This can be done with CORECONF with no problem.

AP: What are the use cases?  
AM: Audio/video and TCP traffic.  
LT: Any possible flow, we just don't create a proper Flow ID and
connection, but we have modifiable rules that adjust themselves.

ER: On creating these rules, that's overhead, especially on a device
receiving these commands. Can you add new operations instead of creating
new rules? The latter looks like making the protocol heavier. What is
really needed? Probably new operations.  
AM: What do you mean by new operation?  
ER: I don't understand what characterizes a flow as different from a
packet. This might be an update to the SCHC specification but it might
make implementations easier.  
LT: You need the same set of rules on both communicating parties.
Through the management interface, we can ensure that.  
ER: Can't you provide a pattern to a device instead?  
LT: Like a sequence number whose TV is incremented as packets are
received?  
AM: That's possible for fields that can relate to a pattern at all. What
about the other ones?

### \[18:00\] Zero Energy Devices \[10min\]   {#1800-zero-energy-devices-10min-1}

*   Associated draft: draft-ramos-schc-zero-energy-devices
*   Presenter name: Edgar Ramos
*   Objective of the discussion: The need to use SCHC for large packets
    (not IP) delivery in an intermittent.

ER (p2): Scope of the draft (payload compression is not written down
yet).  
ER (p3): Three different kinds of devices are considered and targeted,
depending on their energy availability/storage and their signal TX/RX
capability.  
ER (p4): Survey of different topologies to consider. We will start with
the simple case, and then we'll incrementally build on the most complex
ones.  
ER (p5): Bottom line, these devices have to save energy, we have to
optimize transmission whenever possible. Also to keep in mind that
transmission might not be possible at an arbitrary point in time, so
traffic can be sporadic. The energy budget at a certain time might even
not be enough to transmit a whole packet in its original form.  
ER (p6): A good compression stategy should do its best to deal with
intermittend and unpredictable network activity.  
ER (p7): One can try to use SCHC as a sort of "transport", think in
little chunks, and fit as many as possible as those in a known activity
window.  
ER (p8): The context can be configured out-of-band, or in-band through a
dedicated protocol. Both have issues (how doing that practically in the
former case, and how to be efficient in the latter).

AP (not as Chair): I love your work, it touches very good use cases. I'd
personally like to see this advancing. More devices and communication
technologies can benefit of this.

MH: Could you explain how to solve the problem with the Base Station?  
ER: It's not that easy, it'd require standardization in 3GPP. In slide
6, the IP would be provided by the API or the tunneling. The device
might not have a real IP.

JCZ: That was interesting, I support this. It's not specific for a
particular radio technology, and there's a similar work ongoing in IEEE.

ER: I think that's potential to do work here.  
SA: What you mention also on the context exchange is interesting, nice
work.  
SC: We're looking into a combination of small profiles that can be later
updated, also for looking into very constrained devices.

## \[18:10\] SCHC architectural proposal \[15min\]   {#1810-schc-architectural-proposal--15min-1}

*   Associated draft: draft-ietf-schc-architecture
*   Presenter name: Laurent Toutain
*   Objective of the discussion: Discuss a SCHC architectural proposal
    including management feature and SCHC Header

LT: This is about putting together the SCHC developments of the latest
here into an architecture.  
LT: The architecture has to be generic and at a very abstract layer, for
working also with non IETF protocols.  
LT: We introduce the concept of "discriminator" to understand the origin
of the packet. That basically tells what stack to use at the recipient
endpoint.  
LT: Goals, constraints, and open points on how to do inband management. 

LT: Now running out of time, we'll continue discussing also at interim
meetings.

AP: The zero-energy-device use case is interesting also in this respect.

## \[xxxx\] AOB \[QS\]   {#xxxx-aob-qs-1}

EV: I love the new energy and projects in the WG.

* * *



[1]: https://datatracker.ietf.org/wg/schc/about/
[2]: https://datatracker.ietf.org/wg/schc/
[3]: https://www.ietf.org/mailman/listinfo/schc
[4]: https://www.worldtimebuddy.com/?qm=1&lid=3067696,5391959,1816670,5128581&h=3067696&date=2023-11-9&sln=17-18.5&hf=0
[5]: https://datatracker.ietf.org/meeting/118/floor-plan?room=berlin-3-4
[6]: https://datatracker.ietf.org/meeting/119/agenda
[7]: https://datatracker.ietf.org/meeting/118/agenda/lpwan-drafts.pdf
[8]: https://datatracker.ietf.org/meeting/118/agenda/lpwan-drafts.tgz
[9]: https://meetings.conf.meetecho.com/ietf118/?session=31645
[10]: https://meetings.conf.meetecho.com/onsite118/?session=31645
[11]: https://notes.ietf.org/notes-ietf-118-schc
*[MT]: Marco Tiloca


*[IM]: Ivan Martinez


*[PT]: Pascal Thubert


*[AP]: Alexander Pelov


*[LT]: Laurent Toutain


*[AM]: Ana Minaburo


*[EV]: Éric Vyncke


*[CG]: Carles Gomez


*[MH]: Maryam Hatami


*[ER]: Edgar Ramos


*[JCZ]: Juan-Carlos Zúñiga


*[SA]: Sergio Aguilar


*[SC]: Sandra Cespedes