## THIS IS A DRAFT!!! ##

# Minutes, 27 November 2015 interim, 6TiSCH WG #

Note: timestamps in PST.

Connection details
------------------

* Date: 7-8AM Pacific
* Webex link: https://cisco.webex.com/ciscosales/j.php?MTID=md64a0958ae4154c0553f056bf42b756a 
* Webex Recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=593dfc3212814becb59dd237f7804d5b
* Wiki: https://bitbucket.org/6tisch/meetings/wiki/150925_webex
* Slides: https://bitbucket.org/6tisch/meetings/src/master/151127_webex/slides_151127_webex.ppt


Taking notes _(using Etherpad)_
-------------------------------

* Diego Duvojne
* Thomas Watteyne
* Michael Richardson
* Pascal Thubert
* Tengfei Chang

Present _(alphabetically)_
--------------------------

1. Thomas Watteyne
1. Pascal Thubert
1. C-Y Lee
    1. Call-in User_4 (did)
1. Diego Dujovne
1. Jonathan Munoz
1. lavanya (didn't identify him/herself)
1. Malisa Vucinic
1. Michael Richardson
1. Michel Veillette
1. Nicola Accettura
1. Pat Kinney
1. Sedat Gormus
1. Tengfei Chang
1. Xavi Vilajosana
1. Zhuo Chen

Action Items
------------
* Pascal to publish Architecture draft update
* Xavi to publish Minimal draft update
* Chairs to propose new charter to responsible A-D (Brian)
* Thomas to push adoption e-mails to the 6TiSCH ML
* Zhuo to kick a ML discussion on whether P2P routing and HbH scheduling apply to IP forwarding, G-MPLS, or both 

Agenda
------

* Administrivia _[2min]_
    * Approval agenda
    * Approval minutes last call
* Charter Update _[15min]_
* Minimal Support: status _[15min]_
* Architecture: status and directions _[15min]_
* 6lo drafts (BBR and 6LoRH) _[10min]_
* AOB _[1min]_

Minutes
-------

* _[07.??]_ Meeting starts
    Agenda change: Propose Xavi to start first. No opposition, approved. Minimal is first.
    
* [07.06]  Minimal Support: status _[15min]_
    * large list of issues created in bitbucket
    * last issue (#3) needs to be discussed
    * Xavi goes through summary of all changes. Made changes following the recommendation from the reviewers
        * editorial changes
        * changes to RPL
        * what happens if the network is not multi-hop
    * intended status: no 
    * [Michael] no intended surveys, but BCPs ("profile") say that, "when using protocol X in context Y, you SHOULD use parameters Z". This is for operators rather than implementors. Minimal says you to use RPL, which you would not implement if you were just using IEEE802.15.4e. AD asked whether this will be used beyond a plugtest.
    * [Pascal] node requirements for IPv6 is informational, it does not mandate behaviors. Just information about the mote; but doesn't use "MUST". Minimal draft does say you need to compute the RPL rank according. That draft is what this is specified, so it's not just setting parameters. Think we are beyond informational.
    * [Malisa] agreed with Pascal & Michael, would make sense to publish as standards track. The DTLS profile that is a similar scope, is intended to be published as standards track.
    * [Michael] RFC6434 list RFCs that you are expected you should look at. RFC6434 should not have been informational. Strictly speaking, informational are not standards.
    * [Michael] we have a BCP number, but no informational numbers.
    * [Thomas] Consensus on Standards track. How do we proceed? We are building on top of it Default setup on top of it. 
    * [Michael] A good answer. We have not articulated that. 
    * [Thomas] It is important to publish this. Standard track. RPL rank no anywhere else. This is the spec.
    * [Pascal] Nobody wants informational, better standard track. Recommendation for developers than for deployers.
    * [Thomas] Discuss on the ML.
    * [Pascal] To get an RFC number, highly respected. Already implemented, tested. 
    * [Thomas] Anything else?
    X: Publish it. 
    * [Thomas] Send it to the ML and send a note.
    * [Pascal] Copy the link to the diff to see the changes. Thanks. Great work.
* [07.25] Charter Update _[15min]_
    * [Pascal] Starts discussion on Charter. We are closing Architecture and Minimal. Plan: Architecture and Minimal published, start a new charter.
    * [Pascal] Charter: Is a contract with the IESG, 5 elements. 6top sublayer,  6top protocol. Lots of work on IEEE, there is a 6tisch interest group. The plan is go to standards track and then go to IEEE for next gen. Second item: Scheduling Function. We intend to keep SF at the IETF. SF0 standards track too. Tracks on discussion on Detnet. Secure Bootstrap on the ML, keep it up. Architecture next step. Take the work back to the WG, wait until completed the WG and publish it.  
* [07.30] Architecture: status and directions _[15min]_
    Terminology tickets: 38 and 39. Update the link on Architecture. Next step to publish -09 and then discuss on the ML and work on the tracks. The architecture is built on too many pieces. Capture more detailed information, can be on the specification level. Hop-by-hop scheduling: we did not really work on it, we have seen interest on it, Chonggang provided help. Make tracks work. Fragments forwarding listed on Archie forever, either work on it or live without it. Clarified dependencies. More explicit on dependencies. 
    * comments from Kris is that we have different ways of doing forwarding, routing and scheduling. This turns into many combinations, which is complicated.
    * proposal is to select a small number of combinations
    * Pascal talks about the different forwarding models (slide 20)
        * we now have IPv6 forwarding+RPL+static
        * we are now working on now have IPv6 forwarding+RPL+neighbor-to-neighbor (SF0)
        * we have work in front of us with reactive P2P (RPL P2P or AODV v2)/ Charlie Perkins has indicated he might be interested in working on reactive P2P. That's a great fit with hop-by-hop scheduling.
        * question is whether we want to classical IPv6 forwarding.
    * Pascal indicates this table locks the number combinatorial combinations. This table is the proposal. That table is in the draft.
    * [Zhuo] saw that in the routing there is PCE.
    * [Pascal] PCEP is the protocol to install routes. PCE is the component which calculates the routes. Route computation happens inside the PCE. Forwarding happens in the devices. In centralized, the control plane centralized in the controller. In RPL, the routing is distributed. PCE is not a protocol. What would you like in that box? At this stage we don't have an idea what the protocol is.
    * [Zhuo] In my mind, thinking about track with hard cells. Track with soft cells. Something in future is track configured by the node.
    * [Pascal] that's what we have put in the lowest row the HbH scheduling will allocate soft cells.
    * [Zhuo] can that be a track?
    * [Pascal] had that discussion with Thomas, it's our decision.
    * [Pascal] alternatives:
        * we install the HbH in the routing table, or we use track forwarding in this table. Decision was not made yet. Proposal is to keep IPv6 forward. We are nowhere on the GMPLS way. If we want to go quickly to market. Let's take that to the ML.
    * action item: Zhuo to start a discussion on the ML
    * [Zhuo] OK
    * [Thomas] +1 on the table. Great overview of the roadmap. When will be published.
    * [Pascal] submit -09 now, but pushed to IESG very late in the process
    * [Pascal] RFC4861 is clearly designed not work in NBMA case. This is the case of the 6TiSCH mesh. Ralph asked us to work on this.
    * [Thomas] second idea to publish it ASAP.
* [16.57] WG adoption calls on both drafts, we need to answer that call to weight on the adoption. This is very important for the work we do at 6TiSCH.
    * BBR is what we have in our architecture
    * 6lo routing dispatch is what we need to compress RPL. 6TiSCH has been complaining about that. 6lo is ready to adopt this compression mechanisms.
    * [Thomas] please send the initial call e-mails to 
    * Action item: Thomas to push adoption e-mails to the 6TiSCH ML
    * 
* _[08.??]_ Meeting ends