Minutes IETF101: lwig

Meeting Minutes Light-Weight Implementation Guidance (lwig) WG
Title Minutes IETF101: lwig
State Active
Other versions plain text
Last updated 2018-03-28

Meeting Minutes

Minutes taker: Rahul Jadhav

0. Carlos: TCP Usage Guidance in the Internet of Things (IoT) (15min)

1. Rahul: Neighbor Management Policy for 6LoWPAN  (10 min)

2. Carsten: Virtual reassembly buffers in 6LoWPAN (10 min)

3. Francesca:  Comparison of CoAP Security Protocols (10 min)

4. Rene: Alternative Elliptic Curve Representations (15 min)

Carles presenting TCP Usage Guidelines in IoT

Guidance sections better organized
    1. Updated introduction: TCP criticism in IoT scenarios
    2. Valid & invalid reasons for TCP unsuitability

Split in sction 4. Major rehaul.
Updates related to OS/stack specific implementations.
The comparison table is updated with socket support, concur conn rows.

Potential changes identified for 03.

Suresh: Questions about appendix. Highly dynamic content.
Implementation status update section.
Hannes: Get data .. getting data from papers is not very representative.
Mohit: Makes sense about having these numbers.
Hannes: Use of analyzer for getting code/data sizes..
Rahul: There are lot of points there which are design points and not easily
changeable. Suresh: Dont agree with this. There are lot of implementation
specific information which may change, for say in 5 years. Carsten: Comparison
table will be in the document

Rahul presenting

Mohit: You're in contact with contiki maintainer?
Rahul: Contiki authors are also part of this work as co-authors

[15:50] Virtual reassembly buffer
Carsten presenting.
Explians 4944 reassembly mechanism.
Problem stmt in context to current frag/reassembly.
Discusses the proposed solution. Fragment forwarding.
[Thomas]: had discussed in DT about 6lo vs lwig .. implementation in progress..
Suresh: I dont see an issue .. some point we can do joint last call.
Samita: We are ok with the plan that thomas/carsten has mentioned.
Carsten: who has implemented this. Thomas/Yatch raised hands.

[16:08] Alternative Elliptic Curve Representations Rene not able to take mic
... will be presenting later

Francesca presenting
Status update for the document.
Mohit: how many have read the document? Show of hands... There is a clear
interest. GOing for hum for adoption. Pretty clear that there is clear
interest. Confirm it on ML.

[!6:13] Alternative Eliiptic Curve Representations Rene presenting Explains ECC
algorithm Zoo in context to NIST curves, ECDSA, CFRG curves, DH Key agreement,
EdDSA. Explains implementation details

Suresh: I read the draft .. could not figure out what is the implementation
guidance? We may not have the expertise in this group to review crypto etc..
Rene: we essentially define mapping .. there is no security impact ... if you
want to do light weight implementation ... the draft sort of is also a tutorial
for major part. Suresh: what is lacking is what to do? not clear what is for
implementers? Should discuss this on ML. John Mattson: Excellent ref for
summarizing the stds. in future we might want to have diff terminology the nist
curves... performance is poor for 25519... for key generation. Rene: I have
some calcs .. but depends on implementations.  for Iot devices you can exploit
fancy techniques. Havent really seen any real implementation which meets 
actual security requirements. John : it will be nice to have this info in new
version. Rene: can give some numbers.. Hannes: we have this challenge ..
definitely useful work.. happy to work on this. Bob: There are other things to
optmize other than code. Rene: well, always.

Zhen: There can be many points to be useful for implementors. Speaking as
chair, this doc needs to focus on implementation guidance. Mohit: Would be
useful to have more eyeballs other that LWIG ... need more crypto experts .
Hannes: Type of expertise that is needed is .. someone who implements a crypto
lib and participates in stds development. Need to have extra effort to get such
persons .. Should forward this doc/ppt to those people, it will be useful.