[6tsch] minutes discussion models draft 1 October

[Thomas Watteyne <[e-mail]>]

All,

You will find the minutes of the discussion about the models draft from
this morning at
https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also
copy-pasted below).

Thomas

---

Minutes Webex 1 October 2013, 6TiSCH group, models draft team

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

   1. Thomas Watteyne
   2. Raghuram Sudhaakar

Present *(alphabetically)*

   1. Alaeddine Weslati
   2. Dan Romascanu
   3. Diego Dujovne
   4. Pascal Thubert
   5. Pouria Zand
   6. Qin Wang
   7. R. Nabati
   8. Raghuram Sudhaakar
   9. Thomas Watteyne

Agenda

   - Present pre-draft ToC *[Raghuram/Pouria]*
   - Discuss ToC
   - Define contents of each section

Minutes

   - *[08.05]* meeting starts.
   - *Raghuram* shares pre-draft through Webex
      - goals for today: define ToC, define contents of each section, pick
      title
      - Scope is to include data and interaction model for CoAP. At a later
      stage, extract information model as separate draft.
      - "6TiSCH data model" or "6TiSCH CoAP data model"?
   - *[Thomas]* personal opinion: have CoAP in title
   - *[Qin]* why interaction model on top of information model?
   - *[Raghuram]* we want to define message flows between PCE and nodes.
   Data model is exact definition of payload. We had rough consensus on using
   name-value pairs. Interaction model for CoAP or RSVP in future drafts.
   Interaction model provides abstract model of interaction between entities.
   - *[Qin]* RFC3444, interaction flows should be part of the data model?
   We should not conflict with RFC3444.
   - *[Thomas]* We may want to split the interaction from this (data model)
   draft.
   - *[Qin]* Data definition and coding is common part. For me, experience
   with different definitions. Don't want another terminology.
   - *[Dan]* Not extremely familiar with 6TiSCH but experience with data
   and information model. In the IETF, we have clear definitions about data
   and information model. RFC3444 accepted and used as reference. There are
   differences, i.e. interaction model. We need to stick with RFC3444 as close
   as possible.
   - *[Raghuram]* Goal of interaction model is try to extract information
   model at a later stage. CoAP is one of the transports we are using today,
   but we can use other protocol at a later stage. We can name it differently
   later "interaction method".
   - *[Dan]* If we are inventing a new name, it does not matter too much.
   We are looking at mapping different transports.
   - *[Raghuram]* Goal of interaction model is to extract the information
   model.
   - *[Raghuram]* Change to ToC: remove interaction?
   - *[Thomas]* Could be replaced by example scenarios.
   - *[Pascal]* We have identified interaction at L2, L3 and L5. We need to
   have discussion about the models.
   - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example
   interactions". Message formats would be moved up to 3.3, name-value pairs
   proposed.
   - *[Thomas]* Rough consensus?
   - *[Qin]* what's the different between management and informational
   resources?
   - *[Raghuram]* management resources are R/W, informational resources are
   R (e.g. DAGrank).
   - *[Thomas]* We could walk through ToC?
   - *[Raghuram]*
      - 3.1 naming convention for URI schemes. For example, root resource
      "6t". Includes naming convention for resources under root resource.
      - 3.2 resource of 6top we want to expose, i.e. management and
      informational resource.
      - 3.2.4 user installed resources, e.g. subscribe for particular
      implementation.
   - *[Raghuram]* Should we have extensible resources?
   - *[Thomas]* Yes.
   - *[Qin]* What the functional description of a resource? Related to not
   only management but also informational resources. Should we put every
   description attached to every resource? Looking at the content, I can
   imagine a resource list, with a description for each one. Suggestion is to
   put description just following the resource list.
   - *[Raghuram]* Fine with that.
   - *[Pouria]* Other change "functional description of resources" will
   fold into 3.2.1 and 3.2.2.
   - *[Raghuram]* Resource is just the URI, linked to particular 6top
   variable. Methods would fall under description of resource.
   - *[Qin]* Description of the MIB?
   - *[Raghuram]* End-user should be able to get a specific parameters.
   Returned as name-value pairs. If an entity wants the entire MIB, we will
   have a separate resource.
   - *[Thomas]* Mapping of 6top commands included?
   - *[Raghuram]* Yes. Mapping of table of 6top commands presented in
   previous calls.
   - *[Pouria]* In resource management, information that can be written by
   PCE, or commands to be executed.
   - *[Raghuram]* Everything that change the TSCH schedule falls under the
   management resource.
   - *[Raghuram]* Section 4 will be moved up. A message format will be
   attached to each URI.
   - *[Thomas]* Map the attributes from minimal draft and the commands from
   6top draft.
   - *[Raghuram]* That is the plan.
   - *[Thomas]* What are extensions?
   - *[Raghuram]* We don't want to define the URI for every attribute, we
   want to enable people to install a new resource with a definition.
   - *[Raghuram]* In that context, what are profiles?
   - *[Thomas]* Profile is overarching modification to basic behavior: e.g.
   adding resources or adding method to existing resource.
   - *[Qin]* Understanding about profile: resource is fixed, behavior of
   resource can be configurable.
   - *[Pascal]* +1 it's very important we are able to do add to basic
   behavior.
   - *[Diego]* How can we describe a trigger, e.g. number of measurements
   to average over.
   - *[Thomas]* Do we have a solution?
   - *[Raghuram]* Yes, complex triggers are defined using well-known
   formats. RFC already defines how to encode several thresholds. Output would
   be sent on CoAP response or observe notification. One generic method for
   any kind of trigger.
   - *[Raghuram]* In profiles, modify or add behavior. Add is easy.
   Profiles as a way to define extra sets of complex triggers. Discovery. What
   we could express as profiles are extra complex triggers.
   - *[Thomas]* What are the next steps?
   - *[Raghuram]* Updated version of draft by next week to discuss
   progress. Invite contributors.
   - *[Thomas]* Name of draft?
   - *[Raghuram]* What about "6TiSCH CoAP data model".
   - *[Thomas]* We need to know editor to create repository.
   - *[Raghuram]* AOB?

   No other business raised.

   - *[09.05]* meeting ends.