Interim #10 2022

Data / Time

• Date: October 4th, 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

Interim Agenda

## [16:05] Administrivia                                [05min]
* Note-Well, Scribes, Agenda Bashing
* WG Status
* Rechartering Discussion

## [16:10] Data Model Reviews                           [10min]
* Laurent Toutain
* Answers to be given to IESG

## [16:20] NB IOT reviews                               [10min]
* Ana Minaburo and Eric Vyncke
* Follow-up of the AD review of NB-IoT

## [16:30] Device Identifiers                           [20min]
* Laurent Toutain

## [16:50] LPWAN rechartering and AOB                   [ QS ]
* Pascal

Interim To Do's for next time

• Alexander to ping (again) compound ack authors for IPR

Meeting Minutes

[16:05] Administrivia

[05min]

• Note-Well, Scribes, Agenda Bashing
• WG Status
• Rechartering Discussion

Alexander presents the note well as usual.
Last meeting's minutes approved.

• Ana: IPR has been sent and for Sigfox draft all received;
• Alex: some missing for compound ack (JCZ, pmaybe someone else?)
• compound ack includes a YANG model. What should shepherd write? No
  Yang doctor review performed but Yang model very simple?
• Eric: shepherd write-up can be updated is required, better to
  contact authors if you have comments, also still time to request a
  YANG doctor review
• Alex: will write shepherd write-up.
• Everybody can send the review of both drafts Sigfox and Compound-Ack

[16:10] Data Model Reviews 

[10min]

• Laurent Toutain
• Answers to be given to IESG

Laurent answered to all the comments received so far from the IESG.

Eric: The color change in the review summary on datatracker is a manual
process, the red that is still there has to be fixed manually.

Eric: Laurent has nothing more to do. Note that when the author
publishes it's good to notigy the A-Ds that have apending position on
the draft. This one should be approved by end of week

[16:20] NB IOT reviews 

[10min]

• Ana Minaburo and Eric Vyncke
• Follow-up of the AD review of NB-IoT

Ana: Two reviews - green
Pascal: The draft liaision letter was written to indicate the
advancement of the document to 3GPP.
Eric plans close the LC at the end of september just before the last
IESG meeting.
For the 3GPP liaison we need to wait.

[16:30] Device Identifiers 

[20min]

• Laurent Toutain

Laurent already presented at the last IETF meeting. This is getting
importnant now that we havea model. the Yang DM only covers RFCs 8724
abnd 8824. But we do not associated rules to devices. We still need to
do that.

One thing that is important is to identify to whom a set of rules
belongs.
Laurent provides the OPENSCHC ID . There's also RFC 9039, but there is
no indicatiopn of protocol and the MAC address in there might not exist
as a unique in LPWANs

We need to wrap the Yang Data Model with more info like device ID. This
may depend on the network.

Pascal: We need to identify the terminal in P2P also. It is not a device
ID but the capability. Which Rules you support and not who you are.

Laurent: The only capability is SCHC or not
Pascal: Is not only the capability of knowing or not SCHC but also the
Rules you known, because if you don't have all the Rules you cannot do
SCHC either. In the PPP draft, the device opens the PPP connection and
passes a compression method and the URN of the rules. The compression
method can be SCHC. If the app does not support it the conncetion does
not come up. If the app cannot fetch the URN, the connection does not
come up. But we have no use of an ID in that flow. At which point we
need an ID? do we only need the Rules? At least we must trust that the
rules we fetch are correct because if tehy are forged, all bets are off.

Laurent: maybe we can rely on Layer 2 to send the rules, so we don't
need identifiers.
TODO: discuss this on the mailing list?

Laurent: another point was the Access control and see how the network
configuration needs to be done.
Laurent answers to Stephen Farell mail, about the privacy of the
identifiers.

Pascal: We need to agree in the ML if we need a DeviceID (do we really
need it?); the Rules need to be instanciated, for instance if the IP is
compressed there is a need to replace a generic $IP with the device IP
address.

• We need to document why we need an ID first
• We need to be sure that the Rules we are receiving are correct and
  have not been touched.
• For that the device could pass the hash of the rule set expressed in
  a canonical fashion together with the URN, that the application
  could validate when it fetches the ruleset.

Eric: this way it can be stored locally

Pascal: this is critically important because an app in a control network
will not be able to fetch a ruleset from the manufacturer of the device.
A control network is typically isolated from the internet, so there
needs to be a local server with all the rulesets available.

Alex: Describe why we need the ID will probably give us the way to go
forward.

Laurent: To have a signature is not easy

Alex: you can have YANG-CBOR representation of the data of the YANG
file.

Pascal: you can download the rules and then verify the hash. Or the
device can send the hash to the core, and the core can then use this
hash to ensure the right rules are retrieved.

Eric: the same can be applied to SDN as well.

Pascal: the same thing can be applied to factories - it is important to
be able to fetch the rules locally.

[17:04] Meeting adjourns