Minutes IETF116: lpwan: Thu 04:00
minutes-116-lpwan-202303300400-00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Date and time 2023-03-30 04:00
Title Minutes IETF116: lpwan: Thu 04:00
State Active
Other versions markdown
Last updated 2023-03-29

minutes-116-lpwan-202303300400-00

Meeting Information

LPWAN WG info

SCHC WG info

Data / Time

Meeting Information

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]

### [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]

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