Note takers: Matthias

Introduction

No changes to the agenda

I. WG Drafts status

draft-lwig-coap (Matthias)

How to continue: Prepare WGLC for IETF 94

Reviews: Simon Lemay, Jamie

Add Security section: Shahid Raza, Olaf Bergmann
- API between CoAP and DTLS implementations (Matthias, Shahid)
- Numbers for lightweight implementations (Shahid)
- Estimate on far it can be pushed based on a simple use case (Olaf)

draft-lwig-energy-efficient (Carles)

No more comments on last issue, appears stable

WGLC? 

CZ: DSME issue: Do not ask same question again. comments were sporadic, no followup on mailing list, can be ignored; confirm there are no opposing
Robert: Take it forward, since feedback is limited

Humm WGLC: yes (humms) -- no (no humms)

tls-minimal (Sandeep)

Profile done in DICE
Waiting for numbers from Hannes

Shahid: how different from DICE profile?
Sandeep: Profile has no numbers on constrained environments
Shahid: Is there something specific for TLS not in DICE? That would be useful and a reason for the document.
Sandeep: Other reason is having numbers for the different nodes.
Shahid: Which TLS implementation do you have?
Sandeep: TinyDTLS, since main focus is DTLS
Robert: Focus is on ECC calculations, which is vvalid for both TLS and DTLS

II. Open Mic Discussion

1. how to handle existing wg doc

Publish the documents in the pipe.

2. how to move forward


Robert: Hard to get this kind of information out of people
Brian: Keeping the documents open does not give you referencable work; not a good approach. Updating documents would require participants to provide feedback
Shahid: 6TiSCH could be a good new topic for LWIG, there was an Interop and authors might have input. LWIG depends on outcome of other IoT WGs.
Robert: Interops help improving the specs, but nobody shares how it was implemented
Shahid: OpenWSN implementation is open-source, there is no problem with proprietary implementations, IPR, etc. Will try to push Thomas
Sandeep: Not only provide how to make it lightwight, but also share why it is an issue
CZ (hat off): people are reluctant to share implementation experience; sharing makes implementation more visible (good for open source); always good to keep documents open as implementations evolve -> maybe virtual open WG?
Robert: Do not have to meet every time; do not see an issue with WG existing, but we need input
Ari: Was there an outreach to get more information?
CZ: Yes, but "open" implementers are not that involved with IETF
Ari: Maybe provide incentives.
Brian: We did design WGs that did not meet, but they were designed short-lived. Still is okay, my concern is that this still requires people to contribute. Agree with assessment of the chairs.
Robert: Maybe motivate LWIG work within the WGs where the protocols live
Brian: +1, get mroe input via mailing lists
Shahid: What is the plan for the WG?
Robert: Get consensus. If consensus is to 2) shut down, docs in the pipeline will still be published; 1b) continue virtually; 1a) continue as is
Robert: LWIG will meet in Japan
Ari: 1a would be the ideal goal. What tools?
Brian: IESG wants to see more people involved in the discussion; tools?
Oleg Hahm: We have several implementors in the Riot community and we could try to find LWIG contributors about the full stack
Shahid: I can push Simon Duquennoy to contribute on implementing 6TiSCH

Humm
1a) Continue as we are and try to making it more active (loud)
1b) Continue as low-activity WG, e.g. mailing list only (no)
2) Finish open docs and conclude the WG: (no)