IOTOPS at IETF 124 Montreal

Wednesday 5 November 2025
21:00 (UTC)/ 16:00 (Montreal)
1 hour

Meetecho: https://meetings.conf.meetecho.com/ietf124/?session=34638
Notes: https://notes.ietf.org/notes-ietf-124-iotops
Chairs: Alexey Melnikov and Henk Birkholz

Note taker: Michael Richardson

16:00 Administrivia
(5 min; chairs)

16:05 Authorized update to MUD URLs
draft-ietf-iotops-mud-acceptable-urls
(5+5 min; Michael)

16:15 Ownership and licensing statements in YANG
draft-ietf-iotops-ol
(5+5 min; Eliot/Carsten)

~~16:25 Doing an Inventory of IoT devices using IDevID scanning
draft-richardson-iotops-mud-query
(5+5 min; Michael)
~~

16:35 IoT DNS Security and Privacy Guidelines
draft-mishra-iotops-iot-dns-guidelines
(5+5 min; Jim Mozley)

16:45 Privacy Preference Declarations and Taxonomy for IoT
draft-dsmullen-ppd-architecture/draft-dsmullen-ppd-taxonomy
(10 mins; Daniel Smullen):

17:00 FIN

Authorized Updates to MUD URLs

• MCR:

  • Question: How can we evolve your MUD profiles? Need to use DHCP
    or LLDP, but that has drawbacks
  • Essentially with the updates, you can change the last URL
    component
  • If we want to do a merger or aquisition, that will work
  • Please read the draft, it is ready for WGLC, but it needs review
    comments
  • Any comments (about content or why did not want to review it?)

• AM:

  • Actions: DNS directorate review ; HTTP Directorate review; ...
    WGLC

• MCR:

  • People who know things about DNS or URLs should review

• AM:

  • ART directory probably as well

• Behcet Sarikaya

  • Did MUD exist in 2021?

• HB:

  • Yes

16:10 Ownership and licensing statements in YANG
draft-ietf-iotops-ol-01
(5+5 min; Eliot/Carsten)

• YANG Doctor review done, -01 was as a result of YANG review.
• Issues slide.
• FLIP coin for typing of license identifier. (Unless anyone in WG has
  an opinion - if so, send to list)
• Carsten: important to note, this is about the data in flight that is
  created by this model (not the model itself). Data in flight is
  complex enough to have copyright/license conditions on it.

16:18 IoT DNS Security and Privacy Guidelines
draft-mishra-iotops-iot-dns-guidelines
(5+5 min; Jim Mozley)

Carsten: most of this advice relates to all devices, not just IoT?
Jim: yes, for example, the pattern of DNS queries can identify a device
- which true also for non IoT devices
Eliot: most of the stuff in the security consideration section has to
move up. How does resolver discovery work for devices with no management
interface. How could we make this better? Maybe add "unresolved issues",
or "hard problems" section, non-normative so spawn out more thinking
here and within other organizations.
Carsten: DNS over CoAP is almost done and published as an RFC.
Alexey(no hat): some (more?) rational on reason for various
recommendations is good for the future.
It would be nice to document the reasons for the recommendations so that
in ten years, we'd remember why that decision was made.

16:30 Privacy Preference Declarations and Taxonomy for IoT
draft-dsmullen-ppd-architecture / draft-dsmullen-ppd-taxonomy
(5+5min; Daniel Smullen)
Michael: Is the IETF the right place to talk about the policies? The
IETF might be the right place for the bits-on-the-wire discussion.
Daniel: yes, there is a simultaneous effort with IoT vendor fora.
Vicky: what personal privacy option can turn my IoT device into a brick
is something I want to know beforehand. So maybe that requires some
labeling? It has nothing to do with the bits, but has something to do
with the solution.
Daniel: we need the protocols before we can do the labels.
Eliot: agree with Daniel, its a chicken and egg situation for the
protocol. If we do not define it, then the policy people won't have a
grammar to work with. Separate policy from the protocol. .. policy could
go into a MUD file. The vendors might be reticent to do this, because
there might be an incentive to not do this. Issue: how will one know
if the vocabulary correct? We need to put the first stake in the ground,
and then iterate. Can we get some peer SDOs to step up, and that might
bring the vendor to the table.
Daniel: trifecta: 1. No signal mechanism. 2. no vocabulary. 3. no
adoption. Let's do signaling first.

16:44 Using MUD in Constrained Environments
draft-iotops-romann-iotops-mud-constrained
(5+5min; Jan Romann)

Henk: we are using MUD as a discovery mechanism in RATS to learn about
endorsements and golden values for a device. Have been using the term
"secure documents", and the MUD URL falls into the category of insecure
documents. Likes the idea that this leads to secure.
Henk (CHAIR): IOTOPS looks like the right place for this work.
Carsten: Good stuff to persue. Two comments, when using the word IOT, it
means that constrained devices can participate in it, but not restricted
to constrained devices. When talking about MUD, we should talk about all
participants, and that includes securing the MUD URL, and that means
possibly relying upon WebPKI.

16:53 RFC7228bis -- Carsten Bormann
RFC7228 gives us quantified terms like "constrained devices"
Carsten: Suggest just doing WGLC now.
ACTION: do WGLC now.
Henk suggests comparing notes with CCC/RATS against bitmask here.

Closed at 17:00.