* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lwig Status Pages

Light-Weight Implementation Guidance (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2011-Mar-27 —  

IETF-99 lwig minutes

Session 2017-07-20 1810-1910: Athens/Barcelona - Audio stream - lwig chatroom


minutes-99-lwig-00 minutes

          LWIG @ IETF 99 - July 20th, 2017
          Note takers: Mohit Sethi
          New Note Well
          0. Agenda bashing 5 min
          Some draft needs more work before pushing to IESG.
          Suresh, AD: Energy Efficiency. Requested IoT and Int review. AD eval
          follows. Hope it will be with IESG in a month or month and half.
          1. Minimal ESP Daniel Migault
          ESP likely to be used by small devices.
          Document has received significant feedback.
          Authors believe doucment ready for WG adoption.
          Changes sinces 04:
          - Clarified purpose
          - Not designing another version of ESP
          - Clarified text on SPI
          - How to avoid generating random SPI. Randomness is still needed.
          - Padding was corrected and mentioned as mandatory.
          - Next header
          - ICV clarification
          - Known implementations
          @Hannes: Can you tell something more about implementations. Which of
          the IoT OS implement that
          @Tobias: Shahid Raza implementation in Contiki. LMU
          @Hannes: We should not do that work. IPSec does not provide benefits. Add
          fragmentation. Doesn't do us a service.
          @Tero: 15.4 peer wise. Cannot do TLS. Don't need TLS. For constrained
          devices you pick one. Use IPSec everywhere and don't use anything else.
          @Hannes: Are you going to use this.
          @Behcet: Out of Scope
          @Hannes: Standardizing something. Done something. Guidance.
          @Suresh: Early independant draft. Why do you see a need for this. We
          are figuring out if somebody else has a need for this. Bit early.
          @Tero: Not standardizing something new. What kind of tricks you can
          do. Same thing we did with minimal IKE. NAT traversal. In most minimal
          @Hannes: Bad idea to standardize minimal IKE. Stripped out randome
          things. Right thing to do in some deployments and not in other. Feels
          @Tero: 15.9 does not need NAT traversal and uses minimal IKE. Using this
          is better than proprietary.
          @Zhen: Hannes you supported. Work is not normative.
          @Mohit: RFC7942 Improving awareness about implementation
          @Zhen: You want to continue have in LWIG? Do we ask for call for
          adoption? If you think we need to solve this in LWIG group.
          Solve yes: More than 10
          Solve no: Few (One)
          2. TCP over Constrained Nodes    Carles Gomez Montenegro
          CoAP originally designed over UDP. CoAP over TCP in progress.
          Other application protocols such as MQTT, XMPP for TCP.
          TCP is being and will be used in constrained node networks.
          Status: Updated in IETF 97,98 and today is last update 03.
          Details on RIOT and OpenWSN implementation
          MSS: Desirable to limit the MTU to 1280 bytes
          Delayed Acknowledgements- Disabling delayed ACKs is recommended
          @Markku Kojo: Confusing if traffic is transactional. Server is not
          responding slowly. ACKs come with response. That is not transactional
          if data is not coming back from server.
          Another updated to annex of document: RIOT TCP implementation.
          @Rahul: Differ. Even in case uIP. Impossible for application to generate
          same seq number.
          @Carles: This case the app needs to have reliability.
          @Rahul: Current uIP. Every connection has one buffer.
          @Carles: Need to verify versions.
          OpenWSN implementation : no retransmission
          WG adoption. Authors think it is stable. Getting more complete.
          @Abhijan: Slow start. Not utilizing b/w. Work on limited
          transmit. RFC3402? Improving TCP performance. Working on something
          similar. Considering this dimension?
          @Zhen: Did you read draft
          @Abhijan: yes I have.
          @Carles: yes, we can consider this. If maybe TCP fast open maybe good
          idea? We can revise the document.
          @Abhijan: That will be good.
          @Michael: TCPM co-chair. I suggest adopt. Work is needed. Heading in
          right direction. Milestone may not realisitic.
          Read this draft: 10
          Supporting this: About 20
          Not supporting: None
          3. Neighbor Management Policy and Implementation Consideration for
          6LowPAN  -
          Rahul A. Jadhav
          Node density can be anything. Cache size is small.
          How do you prioritize enteries here. Ensure proper routing such that
          network paths don't keep on changing.
          50-100 nodes. Neighbor table size is 10. You need to have a neighbor
          managmenet policy.
          RIOT is FCFS
          DAO storm. Neighbor cache is full of parent enteries.
          100 of nodes in one deployment.
          RPL is example.
          PANA client. Same problem exists in 6tisch.
          Neighbor management operations:
          Eviction- Can evict non preferred parent. Use this intelligence.
          Clearing unused NCEs.
          Propose a reservation based policy.
          All this is reactive. However this has limitations. Child has lost state
          information. No way in RPL.
          Clearly out of LWIG. Like to bring it to ROLL
          @Michael Richardson: If it was only implementaiton advise. Maybe this
          belongs in neighbor discovery. RPL networks without actually doing router
          advertisements. Maybe put it in both DIO. There is protocol action.
          @Carsten: If hosts in ND. IF routers then in ND or routing protocol.
          @Michael: Needed by both.
          @Carsten: Then it is ND.
          @Zhen: Do you have comments on Reactive. For proactive which is right
          working group.
          @Carsten: Even if 6lo has done work, it is good to have work how to do
          it. Useful document to have.  Needs comments to 6lo-6775-update document
          @Michael: Agree. All of advise here.
          @Rahul: Keep
          Read: 5
          Adopt this document in LWIG: About 8-9
          Not adopt this document: None
          4. Minimal g-IKEv2 by Tobias Guggemos  5min
          Group IKE is going to be standardized soon
          No document
          Follow up on minimal IKE.
          We did find useful group key management
          @Hannes: DICE work. Separate working group. Decided to abandon. Made
          changes to DTLS which some people did not want.
          Implemented in RIOT. Need 6kB of memory.
          Works on every MCU device.
          @Michael: 6kB to get to end of the process. How much persist.
          Results are pretty good.
          @Hannes: If DH you need bignum. You need RAM otherwise stuff will not
          end. 10kB RAM for reasonable protocol run.
          Exchange only happens once.
          Providing guidelines for minimal server conf.
          Is there interest.
          @Carsten: When I would use this. I open a channel to server. I do a get
          for key.
          @Hannes: We have work on group communication. ACE working group commn. You
          went for wrong thing. Refers to a document. Minimal IKE doesn't do you
          favor. ACE add PK.
          @Brian: Other draft is still be formed. There is one implementation. Not
          for IoT implementation.
          @tero: Old implementaiton. Msec was shut down.There is AD support. Can
          go to IPsecme.

Generated from PyHt script /wg/lwig/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -