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

[Thomas Watteyne <[e-mail]>]

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


On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <[e-mail]> 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 <
> [e-mail]> 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 <
>> [e-mail]> 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
>>>
>>> ---
>>>
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>