IOTOPS meeting at IETF 121

Chairs opened the meeting and presented the agenda.
There was no bashing.

Michael and Eliot were dualing hedgedoc note takers.
No we weren't. Yes we were.
Christian also puts in a few characters.

CoAP protocol comparison

slides

Jon Matteson presented an update of the CoAP security protocols.

A few things are not fixed, but that will happen with the forthcoming
-08 version.

Only update in -07 was a reference and some short text to TLS 1.3
Reduced (WIP)

cTLS is stable … but not much activity.

No questions for Jon.

Rechartering

slides

Alexey began the rechartering discussion. More formal proposal since
Vancouver. To be discussed on the mailing list as well as in the room.

Henk:

Ops items are mixed; now ? trying to separate them out.
We're not chartered for std track documents.

AP: Add SCHC to replace LPWAN in p2.
EL: Also SCIM and ASDF.

(p3)

Maybe move some MUD-related work to IOTOPS. This requires a change so
that standards and BCPs can be done.

WK: WG was designed as discussion-type group; not publish, just chat.
AM: We solidified over time. Can still time.

AP: Have been working on YANG and CoREconf. IoTops is OPS-area. Today,
these are not in scope (happen in CoRE), but are in IoTops area.
AM: Do you suggest moving YANG things here?
AP: Just question, not suggestion.
AM: Hard to agree/disagree, possibly a fit…
AM: we just looked at the type of documents to move over and suggested a
charter to match. If you have a specific proposal, please send it.

MCR: s/live/life/
MCR: pray continue.

(p4)
MCR: on CoREconf, … YANG documents?
MCR: To some extent, it's the same people here and there anyway. From a
scope PoV, YANG experts may prefer sitting through relevant docs here
rather than in CoRE.
HB: Natural progressions of CoREconf could be CoREconf push; CoAP has
different properties than others, that could be interesting to have
here.

MCR: In alldispatch had topics of IoT intranet browsers. Tiro and Dan
presented, prepare for possible BoF result is it winds up here.
AM: If(!) any of that winds up here, does the text match?
MCR: Depends on solutions.
WK: Sounds like secarea. There is overlap with what SUIT has in its
charter; talk to sec-ADs.

MT: On WG relations; COSE could also go in (p2). On defunct WGs, LWIG
has documents adopted and otherwise, maybe authors want to resurrect
implementation considerations documents, maybe here. Would the
rechartered IOTOPS be an appropriate venue?
AM: If concrete proposals, send to list.
MT: Input now archived at
https://mailarchive.ietf.org/arch/msg/iotops/L5q_4hI4oLT5lpgUH8XyMTFbcvY/

CB: Zone identifier situation is ugly. Looking at this from IoT
perspective is what we don't want in CoRE b/c it's operational (about
systems with multiple interfaces with non-routable interfaces).
MCR the zoneid debate in 6man has been very difficult, and might be a
rathole, but maybe there is a unique IoT perspective which would lead to
a useful consensus.

EL: Happy to see MUD :-)
EL: COncerned about division between this and opsarea-WG. Need notion
about what group is for before slinging. IESG was firm about not doing
protocol specs like any other ops group. Doesn't solve Mahesh(?)'s
problem.
EL: Do you like big groups or small groups (tight charter, know when
work is done; but also coordination)? Nice about opsarea WGs: flexible.
Maybe what's needed is 2nd opsarea slot during meeting.

MCR: If this were solvable with scheduling, it'd be solved already. It
needs mindshare and right people looking at it, and evidence of that
visisble to chairs and ADs.

FP via chat: This IESG has pushed for small WGs.
FP now in room: IESG says it's easier to get tightly scoped chartered.
(?)

WK: Largely agree with EL.
WK: An option might be to charter another WG to meet simultaneously with
IoTops.

EL: Depends on how ADs want to devide the work. Is there opsops work to
be done? Could split. Don't have to be doctrinaire.

AM: Have a proposal, WK can relay it, we'll see what people say.
WK: This started to get MUD out of ops; the rest of the update followed.

(p5)

(p6)

HB: For reference, the "one year" is a few years ago.
WK: You did sent something.

HB: Procedurally, can put draft charter to list; repeat comments on list
as part of "rechartering attempt".
HB: Rechartering alone will not help getting work over the finish line,
have to facilitate review.

RFC7228bis

(really at IETF121; slides as in Vancouver)

CB (p15): Plan was to get discussion on the list, get pre-WGLC reviews,
an update, WGLC.
CB: Not much has happened, to some extent authors' fault.
CB: Do that. HB: 3 or 4? CB: Yes.

CB (p9): Somewhat arbitrary numbers in red circle. Text says numbers
grow over time.

CB (p7): Rooted in chips available when written; think we still have the
2 classes.

MCR: Read it 1y ago. Was, like, yeah, let's go.
MCR: Even if not for sale any more, devices still in the field.
MCR: "I need a few thousand C1 devices" is a useful thing to say. Will
numbers change?
CB: C3 and up, I think yes
MCR: I think they shouldn't, ints are cheap, can easily have C25.

AM: Reviewers?
WK: Who read it?

CB: Avoid "review", people understand "full review signed with blood"

EL: Review in this context should be qualified as to what was reviewed.

Show of hands: Pleae raise a hand if you can commit time to a review for
7228bis?
Yes: 11, No: 2
WK: Names in chat please
Names: CA, Eliot

AP: Relevant as classification. We get questions like "you have stack,
what can we port it to? 16bit controller?" Small devices will be
continue to be used.

AP: Trade-off between application code and network stack code. For
customers, network stack is "overhead" that pushes them to bigger MCU.
In advertisement of how-much-flash, people may expect this to be "for
the application".
AP: OTA updates take half the flash. Should be visible somewhere there.

CB: There are new categories for firmware update. Good input -- have to
marry those.

Craig ?: Talking to power system controller people. What they care about
is longevity (10-20y) but also minimize cost over time.

EL: CB, please repeat a bit of Vancouver. Are tags the right solution?
Are tags? Are these classes hiding tags? Maybe got BLE, some tag for
CPU, etc.
EL: Who is consumer? A config system can eat a lot of complexity. An IoT
device won't care.

CB: Right now we have 2 kinds of scales, one on classes, one of SI
units. This is not meant for "take them to you vendor I need this chip".
Don't want to put in too much details. Reason for added categories is
that there are different capabilities on the devices.
EL: Worried about combinatorics.
CB: This is not for interchange.
EL: Let's take this offline.
WK: Tags sound like tags.

ML: The way we use 7228, we cite it in papers so people get the context.
Others working on MPUs would also like to describe those that way. For
talking about research and design.
AM: thoughs on tag vs. class?
ML: Don't care what they're called.

AP: I'd focus on features that are important for networking. IDC about
HDMI. Do care about secure element.

HB: Having witnessed confidential computing qualities classification ...
let's not pull this in. "Something exists in there that I think is a
secure element" should be the limit of it. So either complementary work,
or sec interop.
AP: Maybe just 3 classes, "nothing, something but not too secure,
integrated"
AM: NIST has something.
(some grumbling)

CB: Adding references to more elaborate categories to the very
rule-of-thumb one sounds good.

AOB

MCR: Agenda topic was from Brendan -- but that's my topic, Brendan is
not available (DoS'd by boss). We'll need coauthor to get that finished.
SUIT may have similar conversation.
HB: Brandon is not MIA, he is prioritizing step-by-step, let's talk in
SUIT.