Subject: [6tsch] minutes discussion models draft 1 October

From: Thomas Watteyne <[email-masked]>
Date: Tue, 1 Oct 2013 11:22:48 -0700

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.

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 1 Oct 2013 11:42:44 -0700

HI all,

I have a question raising from the minutes (sorry I could not connect
today).

If title of the draft is "6TiSCH CoAP data Model" this means that in the
future we will have "6TiSCH *foo *data Model". Is that the direction we
want? Data Model is the way to represent message content (i.e what goes in
the payload and is used by 6top commands). Why is this specific to CoAP?

Another aspect is interaction models, i.e message flows which in that case
they are related to the capabilities of the transport mechanism.

just thoughts..  Sorry if I really go back to something you already
discussed and it is really clear.

X

On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <[email-masked]
> wrote:

>       - 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.
>    - *[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.
>    - *[Pascal]* We have identified interaction at L2, L3 and L5. We need
>    to have discussion about the models.
>    - *[Raghuram]* management resources are R/W, informational resources
>    are R (e.g. DAGrank).
>    - *[Qin]* What the functional description of a resource? Related to
>    not only management but also informational resources. Should we put every
>    - *[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.
>    - *[Thomas]* Map the attributes from minimal draft and the commands
>    from 6top draft.
>    - *[Thomas]* Profile is overarching modification to basic behavior:
>    e.g. adding resources or adding method to existing resource.
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 1 Oct 2013 11:51:06 -0700

Xavi,

Quick reply:
- the term CoAP is in the title to follow RFC3444.
- we decided to put some examples in this draft about different ways of
using this data model (e.g. a node GETting the state of some other node in
the network). We had some discussion about the difference between
information and interaction models; we decided to have those as a different
document to not loose any of the "generic" nature of this data model.

Thomas

On Tue, Oct 1, 2013 at 11:42 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> All,
>>
>>    - *[Qin]* RFC3444, interaction flows should be part of the data
>>    model? We should not conflict with RFC3444.
>>    - *[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.
>>       - 3.1 naming convention for URI schemes. For example, root
>>       resource "6t". Includes naming convention for resources under root resource.
>>    - *[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.
>>    - *[Diego]* How can we describe a trigger, e.g. number of
>>    measurements to average over.

---

From: Qin Wang <[email-masked]>
Date: Wed, 2 Oct 2013 02:56:13 +0800

Xavi and all,

When we talk about data model (DM), there are likely several points of
view. For example:
(1) DM is a set of messages, their format, and the behavior caused by the
messages.
(2) Besides (1), also includes the interface with specific protocol, e.g.
URI in CoAP.

>From the point (1) of view, I agree Xavi. But, because URI is involved, so,
it becomes CoAP Data Model.

So, can we separate the common part of DM, i.e. point (1) from protocol
specific part of DM, i.e. something like URI?

What do you think?

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 1 Oct 2013 11:58:26 -0700

I don't believe we want to split this draft even more, right?

On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]> wrote:

> From the point (1) of view, I agree Xavi. But, because URI is involved,
> so, it becomes CoAP Data Model.
>
>> Another aspect is interaction models, i.e message flows which in that
>> case they are related to the capabilities of the transport mechanism.
>>
>>>    - *[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.
>>>    - *[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.
>>>    - *[Pascal]* We have identified interaction at L2, L3 and L5. We
>>>    need to have discussion about the models.
>>>    - *[Qin]* Understanding about profile: resource is fixed, behavior
>>>    of resource can be configurable.

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 1 Oct 2013 12:01:10 -0700

Hi Qin,

I agree with you .. URI is to indentify the resource, i.e how do we access
a particular service offered by the management layer, I agree that this
should have CoAP name on it if this is bound to URI. then the data model(
the content of what we sent on the payload) this should be generic right?

so I see it in two separete things.

1-interaction model using CoAP
2-content/data model generic..

X

---

From: Qin Wang <[email-masked]>
Date: Wed, 2 Oct 2013 03:03:19 +0800

Just change sections, e.g. separate current section 3 into

3. messages and format
4. Mapping to URI

Just thought.

Qin

On Wed, Oct 2, 2013 at 2:58 AM, Thomas Watteyne
<[email-masked]>wrote:

>>>>    - *[Raghuram]* management resources are R/W, informational
>>>>    resources are R (e.g. DAGrank).
>>>>    - *[Pouria]* Other change "functional description of resources"
>>>>    will fold into 3.2.1 and 3.2.2.
>>>>    - *[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.
>>>>    - *[Pouria]* In resource management, information that can be
>>>>    written by PCE, or commands to be executed.

---

From: Qin Wang <[email-masked]>
Date: Wed, 2 Oct 2013 03:06:29 +0800

Xavi,

Agree!

Qin

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 2 Oct 2013 08:03:20 +0000

Hi Qin, Xavi,
I do agree too about having separated sections within the same draft.
As Thomas pointed out, it is better to not split things too much.. and keep them together. It makes sense in this way.
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Tuesday, October 01, 2013 9:06 PM
To: Xavier Vilajosana Guillen
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] minutes discussion models draft 1 October

Xavi,

Agree!

Qin

On Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

I agree with you .. URI is to indentify the resource, i.e how do we access a particular service offered by the management layer, I agree that this should have CoAP name on it if this is bound to URI. then the data model( the content of what we sent on the payload) this should be generic right?
so I see it in two separete things.
1-interaction model using CoAP
2-content/data model generic..

X

On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Xavi and all,

When we talk about data model (DM), there are likely several points of view. For example:
(1) DM is a set of messages, their format, and the behavior caused by the messages.
(2) Besides (1), also includes the interface with specific protocol, e.g. URI in CoAP.

>From the point (1) of view, I agree Xavi. But, because URI is involved, so, it becomes CoAP Data Model.

So, can we separate the common part of DM, i.e. point (1) from protocol specific part of DM, i.e. something like URI?

What do you think?

Qin

On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
HI all,
I have a question raising from the minutes (sorry I could not connect today).
If title of the draft is "6TiSCH CoAP data Model" this means that in the future we will have "6TiSCH foo data Model". Is that the direction we want? Data Model is the way to represent message content (i.e what goes in the payload and is used by 6top commands). Why is this specific to CoAP?
Another aspect is interaction models, i.e message flows which in that case they are related to the capabilities of the transport mechanism.
just thoughts..  Sorry if I really go back to something you already discussed and it is really clear.
X

On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
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

---

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?

*        [09.05] meeting ends.

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Oct 2013 11:07:05 +0000

Hi,

I made this observation in the call yesterday. It would be good to use the terminology as defined in RFC 3444 in what concerns information models and data models. Information models define objects and the relation between them in a generic manner and are protocol neutral. Data models are less abstract, include implementation- and protocol-specific details, and are usually associated to data modeling languages. Using other terms, or worse - the same terms in a different manner - is confusing.

I suggest to add to the document a section of terminology which either points to RFC 3444, or describes the differences from what is described in 3444 and also explains other terms like 'interaction model'.

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana Guillen
Sent: Tuesday, October 01, 2013 10:01 PM
To: Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] minutes discussion models draft 1 October

Hi Qin,

X

What do you think?

Qin

Thomas

---

Note: timestamps in PDT.

*         [09.05] meeting ends.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Oct 2013 14:12:32 +0000

Hello Dan;

I understand that we want to stick to RFC 3444 for Data and Information models. The limit to overcome is probably our understanding and practice of that specification.

In addition to the static representation, we have a need to discuss the dynamic view of the 6TiSCH operation and we are looking for appropriate terms.

At ISA100.11a this abstraction is often referred to as a "communication paradigm". Examples there are client-server, publish-subscribe and source-sink, which is a MP to MP distribution for alarms and alerts. We could reuse that terminology, with, in our case, the additions of classes for end-to-end (app layer), hop-by-hop (network layer) and one hop (Link layer) interactions.

It seems from the discussion that the applied model for a "communication paradigm" could be called an "interaction model".

For this particular draft, I'd then expect something like a Yang data model that can be trivially translated in CBOR for consumption by constrained devices.

Additionally, we would propose a layer 5 interaction model to transport that data. That interaction model would probably implement the client-server and eventually the source-sink paradigms with CoAP methods. But that would be an example not a limitation, since there can be other ways to transport that data, and other ways for format the bits and bytes.

Does that make sense?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: mercredi 2 octobre 2013 13:07
To: [email-masked]; Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] minutes discussion models draft 1 October

Hi,

Regards,

Dan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Xavier Vilajosana Guillen
Sent: Tuesday, October 01, 2013 10:01 PM
To: Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] minutes discussion models draft 1 October

Hi Qin,

X

What do you think?

Qin

Thomas

---

Note: timestamps in PDT.

*         [09.05] meeting ends.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Oct 2013 08:38:58 +0000

Hi Pascal,

I *think* that it makes sense, but I would like to see text in a terminology section of the document defining the terms and providing references where relevant in order to make sure.

Regards,

Dan

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Wednesday, October 02, 2013 5:13 PM
To: Romascanu, Dan (Dan); [email-masked]; Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: RE: [6tsch] minutes discussion models draft 1 October

Hello Dan;

Does that make sense?

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: mercredi 2 octobre 2013 13:07
To: [email-masked]<mailto:[email-masked]>; Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] minutes discussion models draft 1 October

Hi,

Regards,

Dan

Hi Qin,

X

What do you think?

Qin

Thomas

---

Note: timestamps in PDT.

*         [09.05] meeting ends.

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 3 Oct 2013 08:49:50 +0000

Hello Dan,
We actually have a terminology draft for 6TiSCH...
Shouldn't we define the terms we need in that terminology draft, and refer to it in the model draft? Instead of having a terminology section? It is just a thought...
What do you think?
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, October 03, 2013 10:39 AM
To: Pascal Thubert (pthubert); [email-masked]; Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] minutes discussion models draft 1 October

Hi Pascal,

Regards,

Dan

To: Romascanu, Dan (Dan); [email-masked]<mailto:[email-masked]>; Qin Wang

Hello Dan;

Does that make sense?

Pascal

Hi,

Regards,

Dan

Hi Qin,

X

What do you think?

Qin

Thomas

---

Note: timestamps in PDT.

*        [09.05] meeting ends.