[6tsch] minutes webex 13 September 2013

[Thomas Watteyne <[e-mail]>]

All,

You will find the minutes of today's webex below.

FYI, all the minutes and slides are archived a
https://bitbucket.org/6tsch/meetings/.

Thanks to Xavi and Dominique for taking notes!

As usual, fix anything we might have missed directly in the e-mail and
reply. We will approve and adopt the minutes at the next call.

Thomas

---

Minutes Webex 13 September 2013, 6TiSCH group

Note: timestamps in PDT.
Taking notes *(using Etherpad)*

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

Present *(alphabetically)*

   1. Thomas Watteyne
   2. Pascal Thubert
   3. Alaeddine Weslati
   4. Cedric Adjih
   5. Diego Dujovne
   6. Dominique Barthel
   7. Geraldine Texier
   8. Maria Rita Palattella
   9. Pouria Zand
   10. Qin Wang
   11. Raghuram Sudhaakar
   12. Tom Phinney
   13. Xavi Vilajosana

Recording

   - Webex recording (audio+slides,streaming)
   -
   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=71384822&amp;rKey=95f5ec34911eadf4<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=71384822&rKey=95f5ec34911eadf4>
    *[63min]*

Slides

   - slides_130913_webex.ppt<https://bitbucket.org/6tsch/meetings/src/master/130913_webex/slides_130913_webex.ppt>:
   slides shared during the call

Action Items

   - *Xavi* to send to ML (1) the list criteria currently defined on CoAP
   observe pattern and (2) whether it is possible to extend this list.
   - *Thomas* to send list of CoAP elements that can be used in 6TiSCH to
   ML.
   - *Thomas* to confirm rough consensus about "Can CoAP be used to
   transport 6TiSCH signaling traffic" on ML.
   - *Thomas* to confirm rough consensus on "RPL OF0 parameters" on ML.
   - *Pouria* to present WirelessHART and and ISA100.11a equivalent formats
   for "report flow" at next week's call.

Agenda

   - Administrivia *[3min]*
      - Approval agenda
      - Approval minutes last call
   - Chartering process *[15min]*
      - Updates to charter text
         - latest
version<https://bitbucket.org/6tsch/charter-ietf-6tsch/src/50a000b0a6ade2e7fdac2c711fc06478abc39963/charter-ietf-6tisch-00.txt?at=master>
         - diff<https://bitbucket.org/6tsch/charter-ietf-6tsch/diff/charter-ietf-6tisch-00.txt?diff1=edb2cb03a632&diff2=50a000b0a6ade2e7fdac2c711fc06478abc39963&at=master>
(click
         "Side-by-side diff")
         - "On the Difference between Information Models and Data Models"
         (RFC3444) <http://tools.ietf.org/html/rfc3444>
      - Process
         - Dashboard <https://datatracker.ietf.org/wg/chartering/>
         - Ballot<https://datatracker.ietf.org/doc/charter-ietf-6tisch/ballot/346294/>
      - CoAP *[30min]*
      - presentation *[Raghuram,Xavi]*
      - discussion
   - Rank rounding error, churn and hysteresis *[10min]*
      - Context and overview discussion *[Pascal,Qin,Xavi]*
      - discussion on hysteresis RFC6719<http://tools.ietf.org/html/rfc6719>
   - AOB *[2min]*

Minutes

   - *[08.05]* Meeting starts
   - *[08.07]* Administrivia
      - Approval minutes last call

      No issues raised. Minutes approved.

      - Approval agenda

      No issues raised. Agenda approved.

      - *[08.08]* Chartering process
      - Review process:
         - Dashboard <https://datatracker.ietf.org/wg/chartering/>
         - Ballot<https://datatracker.ietf.org/doc/charter-ietf-6tisch/ballot/346294/>
         - History<http://datatracker.ietf.org/doc/charter-ietf-6tisch/history/>
         - Great feedback during "Internal Review" state.
         - Some back-and-forth between members of IESG and Pascal/Thomas.
         Triggered some rewording of the charter (see below).
         - State changed to *External review* from Internal review.
      - Updates to charter text
         - latest version on
BitBucket<https://bitbucket.org/6tsch/charter-ietf-6tsch/src/50a000b0a6ade2e7fdac2c711fc06478abc39963/charter-ietf-6tisch-00.txt?at=master>
         - diff on
BitBucket<https://bitbucket.org/6tsch/charter-ietf-6tsch/diff/charter-ietf-6tisch-00.txt?diff1=edb2cb03a632&diff2=50a000b0a6ade2e7fdac2c711fc06478abc39963&at=master>
(click
         "Sid-by-side diff")
         - official charter
versions<http://datatracker.ietf.org/doc/charter-ietf-6tisch/>
         - Re-ordered work items:
            1. "6TiSCH architecture"
            2. Information Model
            3. "Minimal 6TiSCH Configuration"
         - Changes to scope:
            - work item 2 now includes a mapping of the information model
            to a data model (e.g. CoAP/CBOR)
         - Clarifications:
            - About the use of RPL in the minimal draft: we are not
            changing RPL at all. Using RPL and OF0 in minimal draft.
         - "On the Difference between Information Models and Data Models"
         (RFC3444) <http://tools.ietf.org/html/rfc3444>
            - This RFC highlights the difference between Informational
            Model (e.g UML diagrams) and Data Model (How data is
represented and
            managed, e.g. CBOR)
         - *[08.13]* CoAP *[30min]*
      - presentation
         - CoAP overview: *[Raghuram]*
            - Carsten is one of the authors of CoAP.
            - Can be described a "HTTP for Low Power Lossy devices"
            - Analogous to HTTP. Follows REST architecture.
            - CoAP brings the REST features to the LLN domain.
            - Designed for minimal payload size.
            - Includes options relevant to the LLN domain.
            - On top of UDP.
            - Defines messaging architecture.
            - Defines request/response formats.
            - Supports identification of resources through URIs.
            - Publish/subscribe features (different from HTTP)
            - 4 types of messages:
               - CON: confirmable (reliable)
               - NON: non-confirmable (unreliable)
               - ACK: acknowledgement
               - RST: reset
            - With CoAP, we can achieve reliable content delivery/request
            - Two identifiers:
               - Message ID: match messages of type Acknowledgement/Reset
               to messages of type Confirmable/Non-confirmable
               - Token: used to correlate requests and responses
            - These two identifiers allow different models:
               - piggy-backing, where response is payload of ACK
               - asynchronous, where response comes on its own, possibly
               after the ACK.
            - 4 Basic Methods: GET/PUT/POST/DELETE
            - Multiple Respsnse categories (similar to HTTP):
               - 2xx
               - 4xx
               - 5xx
            - Options and URIS.
               - Identification of resources
               - Representation of the resource
                  - Content-format: defines the type of the content, e.g,
                  text, uint16, etc.
               - Conditional options.
               - matching options to identify specific resources
               - age for caching, etc.
            - URI Scheme:
               - Options are the containers of the parameters (uri).
               - Notion of URI in http.
               - Size of names in the URI affect size of options so this is
               recommended to be minimal.
               - Does not define the max size of the payload. recommend to
               have it smaller than PDU.
            - CoAP other topics:
               - Security using DTLS
               - DICE
               - Service Discovery
               - Proxying - reverse proxies/ relay proxies.
               - Caching - Max age
            - Observe feature in CoAP: *[Xavi]*
            - The purpose is to stay aware of the updates of the state of
            the resource. Don't want to actively poll all the time.
            - Interested node registers to a resource, and will be pushed
            data from the server.
            - The observer sends a GET request to the server. The server
            responds with the current state of resource, and adds the
client to the
            list of observers.
            - "Observe" is an option of the GET method and response.
            - In the response, the "Observe" option identifies the
            notification with a 24-bit integer value.
            - This value increments between notifications, and is used to
            order the data received.
            - The observe option does not have anything to do with the
            query that is done. So it seems that the GET can contain
Content-Match
            fields to make it conditional. That is, if observe header
is there, then
            this will be notified upon server side changes on the
resource (applying
            condition).
            - *[Dominique]* How can a client know that the server is able
            to add the client to the list of listeners?
            - draft-core-observe states:

            The Observe Option is not critical for processing the request.
            If the server is unwilling or unable to add the client to
the list of
            observers of the target resource, then the request falls
back to a normal
            GET request.

            - *[Qin]* What kind of criteria can be used in the observe
            pattern? That is, can the client somehow specify "exotic"
criterie (e.g.
            "send this metric when I have only one routing parent")
design the criteria
            to get a notification?

            Action item: *Xavi* to send to ML (1) the list criteria
            currently defined on CoAP observe pattern and (2) whether
it is possible to
            extend this list.

            - discussion > Action item: *Thomas* to send list of CoAP
         elements that can be used in 6TiSCH to ML.
            - Next step: continue with CoAP payload discussion. CBOR??
         - Call for rough consensus on using CoAP in 6TiSCH:

         No issue raised. Rough consensus on the call. Action item: *Thomas* to
         confirm rough consensus on "CoAP can be used to transport
6TiSCH signalling
         traffic" on ML.

         - *[08.55]* Rank rounding error, churn and hysteresis
      - Context and overview discussion
         - RPL has a mechanism for loop avoidance.
         - RPL OF0 - rank is a 2 byte value.
         - Several factors are used to compute the OF0.
         - minHopRankIncrease -> makes integer part be a monotonically
         increasing byte
         - DAGRank(rank) is a function indicative of the rank of a node.
         - How do we propose changes/hints to the computation of the ETX.
      - Call for rough consensus on use OF0 as described in
      http://www.ietf.org/mail-archive/web/6tsch/current/msg01247.html.

      No issue raised. Rough consensus on the call. Action item: *Thomas* to
      confirm rough consensus on "RPL OF0 parameters" on ML.

      - discussion on hysteresis
         - RFC6719 <http://tools.ietf.org/html/rfc6719>

         Running out of time. Moved to next week's call.

         - *[09.09]* AOB
      - Presenting WirelessHART and and ISA100.11a equivalent formats next
      call?

      Action item: *Pouria* to present WirelessHART and and ISA100.11a
      equivalent formats for "report flow" at next week's call.

      - Any other business?

      No other business raised.

      - *[09.08]* Meeting ends