Wednesday, March 20th, 2024
13:00 (Brisbane, UTC+10) / 03:00 (UTC)
1.5 hours


Chairs: Alexey Melnikov and Henk Birkholz

Note takers: Warren Kumari, Christian Amsüss
Warren notes that Christian actually did all the work, and that Warren
was just a useless slacker...less slacker...

13:00 Administrivia
(5 min; chairs)

HB doing introductions.

Terminology for Constrained-Node Networks

(from LWIG)

CB presenting on 7228bis (see slides)

WK: Is it allowed by charter? Milestone?
CB: "Does it help in operating an IoT system to have terms?" Probably

AM: Is it informational?
CB: Yes.
AM: Then probably OK.

WK: "Documenting operational practices", might need some wiggling.
AM: Warrent should talk to the rest of IESG and confirm that the charter
is Ok as is for a terminology draft. May need to insert a word.

AM: Wanted to accept this already at IETF 118?
Answer: yes

HB: Need charter update beforehand?
CB: Terms part of operation.
AM: Can adopt anyway, just need to make sure charter is OK before
leaving the WG.

Actions / Requests:

Comparison of CoAP Security Protocols

JPM presenting
(see slides)

JPM summarizing changes.
JPM(p5): References are advancing. Next steps. Stable enough to publish.
Can still update if cTLS(?) adopts more compact encoding.

AM: So we start WGLC, park document for normative references?
JPM: We have no normative references, formally.
AM: Shepherd review might question this. Would be weird to reference
non-final version into an RFC. Happy with WGLC and parking?
JPM: Yes.

Actions / Requests:

IoTops security summary (BM)

BM presenting
(see slides)

BM(p2): Not much to say about updates.
BM: Summarizing draft topic: referencing baseline security documents and
pointers to IETF and adjacent technologies.

KW: Do documents already cover EU CRA (Cyber Resilience Act)?
KW: Noting whether documents cover CRA would be good.
HB: Can you help?
KW: Yes.

HB: Shall we start poking about questions on p3?
BM: Complete recent addition first.

MCR: About CRA… RIPE etc talked about this. IMO, no IETF protocols or
procedures will allow you to deal with financial consequences of CRA, so
will not be in scope, maybe we need to say so.
BM(?): If we add more European concerns, it will appear to be relevant
to only European implementers.
MCR: CRA is primarily a legal / policy thing... I don't really think it
is relevant to us.

Kohei Isobe: Have similar topic to KW. Government starts certification
program (?). Singapore is doing similar things. (?)
BM: Not sure how to answer; keeping track of certification requirements
is probably important; not sure how certification is mapped to
implementation technologies, may need to review that.

BM: So what's left: look at CRA, and maybe certification requirements.
"Look at" is not necessarily reference, may also explicitly not
BM: Need more authors for this? Up to group.

BM: Continue or kill it? If it's just me, we don't need this.
AM: We (chairs) had action item to nag people, were not on top of this.

AM as participant: We should get reviews. If people bring up considering
X or Y, that's feedback, otherwise, if ready, send to IESG. We'll try to
get reviews.

AJS(from chat): will review from the NIST PoV
AJS: Seems interesting. What's your rationale for document?
BM: Evolution of what used to be best practices. That shifted as guided
by group into set of menus of available technologies.
AJS: Can you implement an IoT device that way? Maybe talk more offline.

CB: Want to have this. Reluctant to offer formal review b/c I want to
use this document and don't want to read the other ones.
AM: Reviewers are not required to review with knowledge of references.
CB: Can review as a document.
AM: I won't read the references either. It's a plus but not a
requirement for reviews.

AJS: I will review it (without any hats).
(some furthe back-and-forth)

BM(p5): More thoughts -- what does baseline actually mean?! Nothing
really specifies how to surpass baseline. There are not "baseline
requirements", they are jsut "requirements".

HB: ... pointers not only to documents but also to places here.

Actions / Requests:

IoT Operational Issues

KW presenting.
(p2) context, virtual machines on edge devices.
(p3) examples of our servers
(p4) background of users / customers
(p5) normal configuration of our network. Just sometimes connected to a
different networkt through a router, otherwise switched.
(p6) common problems
(p7) more common problems
(p8) yet more common problems.

MCR: Browser situation is indeed upsetting; what problem it creates now
that it solves later?
KW: Many words, which seem to boil down to "under some weird corner
cases, they might not be actively harmful... :-P "
MCR: If Linux had implemented a default zone, would that solve the
KW: Yes.
MCR: Good to know.

KW: Chrome disables IPv6 completely if it can't reach IPv6 on the
Internet, even though link-local is mandatory. Similar on Windows, off
by default.

KW: Apple browser used to have local discovery.

(p9-p11) yet more problems... so many problems!!!
KW(p12) clarifying: "short lived certificate" for me is <30 years
(p12-...) guess what? yet more problems... :-P
(p15) What next? Where can standardizaton help?
Here to find people, link up with people, solve problems in IETF.

HB: Interesting dispatch problem, b/c dispatching a problem here.
HB: Cherry-picking an item, find the right place. Can stay here for the
moment. Interesting exercise. Challenge to us chairs to support process.

HB: Pick one problem, and we go from there.

MCR: I think that over in Routing Area, they do ~operational reports on
certain protocols as a requirement to move from Proposed to Internet
Standard. Quite detailed, some just RIPE presentations. Had struggles in
6man with browsers. We need browser that is IoT focused and not
dominated by bank issues.
KW: ~Browsers are developed for Internet, not for LAN any more.

MCR: No I-D associated with this presentation. I'd welcome a written
version of this, and have conversations on your experiences. Some
relevant BCPs may be around.

HB: If writing I-D is OK for you, great. Can help lower the threshold.
Happy to help with I-D-ifying this as an individual.
MCR: ~Also happy to help processing mails. It's not necessarily we have
to publish, but discuss. When we go to 6man etc, an I-D gives easier
context for them.
MCR: BTW, seen much of this before. Often lacking connection between
people having the same problems.
WK: Seems like nobody considered how the bits fit together when we
started this whole Internet thing. May help to open a list of issue,
maybe on Github or some other list. Avoid side tracking and losing

(CA, chat only): The "routers in virtualization tools" item looks like
one well addressable by mDNS proxying for which I think some solutions
are around and would only need to be added to the containers.