Subject: [6tsch] minutes WebEx 19 April 2013

From: Thomas Watteyne <[email-masked]>
Date: Mon, 22 Apr 2013 21:48:23 -0700

All,

You will find the minutes of the last webex below, and the presented slides
attached. Thanks to Xavi and Dominique for taking notes). Please fix
anything I might have missed directly in the e-mail and reply.

These minutes and slides are archived at
https://bitbucket.org/6tsch/meetings/.

Thomas

----

Note: timestamps in PDT.

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

1. Xavi Vilajosana
2. Dominique Barthel
3. Thomas Watteyne

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

* Alfredo Grieco
* Dominique Barthel
* Herman Storey
* Maria Rita Palattella
* Pascal Thubert
* Raghuram Sudhaakar
* Robert Assimiti
* Subir Das
* Thomas Watteyne
* Xavi Vilajosana
* Yoshihiro Obha

Slides
------

* Attached

Agenda
------

* change to draft charter [20min]
* Rough consensus on draft draft charter?
* 6tus naming convention [10min]
* Next steps [20min]

Minutes
-------
* [08.06] [Pascal,Yoshihiro] Sync'up about security draft. Pascal met with
Rene Struik, who could help us describe the key exchanges involved in a
6TSCH network. Open questions include how to bootstrap (the security aspect
of) a keys, and what exact keys can be used. Yoshihiro agrees that this
should be discussed.
    * Action Item Pascal to close the loop between Rene and Yoshihiro.
* [08.10]  Overview of the agenda. [Thomas]
* [08.11] Changes to draft charter. [Thomas]
    * overview of changes:
        * Thomas present slides.
        * added term "diversity", as suggested by Tom, as well as "low
power operation"
          > Closes https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/1/
        * In the 6tus draft, limiting the scope of bootstrapping to TSCH,
not security. As suggested by Michael.
          > Closes https://bitbucket.org/6tsch/charter-ietf-6tsch/issue/2/
            * 6tus  layer  initializes the TSCH vs initializes the whole
network.
            * [Pascal] depends on whether we have the capability to do that
work or not. Boostrapping the network will be better objective but depends
on the 6tus draft. 6tus should cover boostraping slots, cells, etc.
Security is part of the security work item.
            * [Robert] distinguish between network boostrapping and
security boostrapping makes sense. Boostrapping the network is simple,
security aspects are more complex and this has to be in another work item.
Security can be operated from the link layer, etc... too much for the same
work item
            * [Thomas] Let's keep the text as it is now (and as it is on
the slide), le's deal with security in security work item.
            * Action Item Thomas maybe change the nature (informational) of
the security work item.
    * overview of charter
        * Thomas shows charter on shared screen.
        * introduction has grows a lot. Longer than usual charter. Leave it
as this?
        * [Pascal] Other PHY? provide different sizes for the time slot?
make sure that we agree on working group description: the same as previous
weeks. Models: centralized, decentralized, best efforts (minimal
configuration)
        * [Pascal] Determinsm: should we use the term? Let's agree on what
we can achieve. Using 6TSCH, we can provision a track, and know the
probability of end-to-end delivery. Yet, you cannot never have 100%
reliability, because of the nature of wireless.
        * [Herman] Determinsim depends on the applications. Applications
have a tolerance, if you are polling it is not deterministic, applies to
schedule transmission and comes with the tolerance (robot == few ms),  you
can have a network that is not scheduled but provides determinsm because it
is fast enough. Scale and  tolerance are important considerations, slotted
is a practical artifact to implement determinism, clarify whether the
determinism "word" should appear as is in the charter. (keep in but discuss
what it means in our context)
        * [Pascal] We need to be ready for discussions about determinsim in
the BOF.
    * work items.
        * 6 as defined before
    * non-milestone work items:
        * implementers guide
        * inter-operability guide
        * coexistence guide between different protocols  (including
different TSCH)
        * applicability statement
        * All as informational RFCs.
    * [Thomas] Can we reach a consensus on the draft charter language?
        * [all] Rough consensus.
* what to call 6tus.
    * [Thomas] overview of the mailing list (not expressing opinion)
        * 6tus not adaptation layer, since it does not try to fit one
protocol into another
        * no layer as there are no fields added
            * [Pascal]
                * disagree with this statement, since time and frequency
packet is sent on contains inforamtion, and can be used as a label.
                * 6tus has a GMPLS aspect,  6tus layer can switch packets
exactly like GMPLS. We can see 6tus as GMPLS (2.5 layer) that "substitutes"
routing once the schedule is set. So it has some relationship to a layer.
It is not an adaptation layer (no transformation), but it can be described
as a layer.
            * [Robert]
                * As 6tus is a mechanism to agree between the PCE and the
node, 6tus should be called a "protocol".
                * A management entity is not a layer.
                * It is important to clarify whether 6tus includes
information on the headers, and when used. This  is a good indications of
the kind of "thing" we are talking.
            * [Pascal]
                * We have to see 6tus as GMPLS. It is a layer that is able
to decide on routing (what is the next hop) acording to the cell the packet
was received on. A node using 6tus can not forward a packet to the routing
layer if it knows that a packet was received on a particular cell, and if
it has some switching table mapping incoming to outgoing cells. Packets
which can not be switched can be forwarded by the normal routing engine
(RPL).
            * [Dominique]
                * In that sense 6tus is a layer that can forward packets
(layer 2.25?).
 * Next steps
    * [Thomas] With rough consensus on draft charter text, let's resume our
technical discussions.
    * First step is to clean up our drafts, as suggested by Adrian during
last webex.
    * went over all drafts, and contacted authors to discuss possible
changes.
    * Identified issues to be closed before submitting a new version of the
draft
    * Let's get this done in the next couple of weeks.
* [09.04]
    * Action Item Thomas Call for adoption draft charter text.
* [09.05]
    * meeting ends