Minutes interim-2022-iotops-01: Wed 15:00
minutes-interim-2022-iotops-01-202210121500-00

Meeting Minutes IOT Operations (iotops) WG
Date and time 2022-10-12 15:00
Title Minutes interim-2022-iotops-01: Wed 15:00
State Active
Other versions markdown
Last updated 2025-03-14

minutes-interim-2022-iotops-01-202210121500-00

IoT Operations

Chairs

Scribe

  • Michael Richardson
  • later: Christian Amsüss
  • your name here

MINUTES

CoRE Resource Type (rt) assignment for draft-ietf-anima-constrained-join-proxy

(CA very sparsely) so pledge establishes DTLS with R through UDP port
forwarding at fe80::..., the JP will tunnel that through CoAP resource
for stateless-UDP-wrapping, and JRC needs to know that it's being
accessed through a port forwarder (so it must not encode its own URIs as
full URIs lest the P will try to reach 2001:db8::... and can't do that
for lack of a route).

See
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-join-proxy#section-9.1
.

iot-nets

Brendan presenting from slides

discussion

MCR: I'm hearing this is a roadmap document to different protocols we
have. From outsider PoV that's good, we haven't done IoT stuff in a
particular place. It's security related ... while we think of software
updates as security related, am not sure rest of industry does. I'm OK
with document that has bunch of pointers for current state of the art of
various things. If ENISA has good threads and is easily readable, we can
refer to it.
BM: Happy to refer to other docs if has adequate content. ENISA doc is
5y old now, misses remote attestation and confidential computing. Those
are foundational now. Nonwithstanding that, there are still NIST and
ETSI documents to review. Maybe between the 3 of them there's something
more complete. ENISA is pretty consumable (only it's 100p long).
HB (hats off): You mention remote attestation, confidential computing.
Would that extend to zero-trust architecture, is that in ENISA?
BM: Not through it cover-to-cover; don't know.
HB: Positioning some IETF work in that domain of perception would be
useful. On readability (also pulling in chat comments): Their taxonomy
is not too readable either ("THREAT.NET.ACL.BROAD"). Is a threat
taxonomy in more readable way part of the work?
BM: Taking MCR's comments from the 114 review, we need to revisit how
the draft should be written. Taxonomy might not be relevant, or might be
moved out from titles. My inclination was to leave some taxonomy in
there so, so we can think of what applies to what.
HB: I heard we have two things. Threat model (don't have to start at
zero) and baseline referring to IETF building blocks. BM, do you
envision this as one or disentangled? Taxonomy could be inherited even,
and baseline is the more solid output?
BM: No assumptions there. Happy with whatever is best WG result. The
mapping is the important part. Baseline probably too, but there are
copies of that already.

BM: a semi-living document would be useful!
EL: I agree that this is going to be a living document. Probably next
IETF,

HB: created a raise hand if you think a baseline/mapping doc for iot as
an informational/bcp I-D is a useful work item for item
results: raise hand: 10, do not raise hand: 2

CB: when we adopt something, a message is sent to a new work ML that
goes to other SDOs. The gating function of adoption is that work is
being started and that we/the-IETF is interested in doing the work. (We
should not fine-tune the document before adoption. Of course, if the
document is misleading, then that's a problem.)
HB: would you have some idea about the timing of adoption call? Would a
discussion for a month be good?
CB: we are having a meeting and we are having the right discussion, but
we need a version of the document that brings out the discussion that we
are having, but is more indicating of what we are trying to achieve.
Optimistically, this can be done before the 24th. Start the adoption
call before IETF, and we discuss the results during IETF.

HB: github would help... general agreement.

ACTION: MCR asks about report to IESG as required in our charter, and
was told that the chairs had already done this, but had not shared to
the list, but chairs will do this.
ACTION: chairs to create ietf-wg-iotops organization
ACTION: Brendan to work on revised ID for adoption call to start.