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

Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu> Tue, 01 October 2013 19:01 UTC

Return-Path: <xvilajosana@berkeley.edu>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209D311E824E for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgwkHPtPIyyw for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:01:18 -0700 (PDT)
Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB021F9DF6 for <6tsch@ietf.org>; Tue, 1 Oct 2013 12:01:12 -0700 (PDT)
Received: by mail-pd0-f181.google.com with SMTP id g10so7609228pdj.40 for <6tsch@ietf.org>; Tue, 01 Oct 2013 12:01:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VF/lQGjABJ8CKMs7vMPuBprh07sczidh/TNpgLQmQZ4=; b=XBkiwqKsssOiGr+TIp1aHv62MSgEKIFfpmAfNTlh+2bjvhfKxNfbViNuLq2joME5Ki NeIwf2sdq8PrhX/a2+hdscPdFa7H2BQAdeQ7rEa3SYPhVzVrxp4YghJLE88RDwoMZjND w7Qs0P7q+lvFT3w2xc7rX73NkaUDew9ul7FruFomNDu/Cy2dJeICEDImdDHFTJAIs4tU gnMcqQd8JyXLxPvKaH66MLfoQVE+DO+e3BTMDquuWx62y8dzWRQzCNpEgJDe9kpmZe8f XBzcO0Pr4Ek+XXfuVUm2sx1BXLuHaxteJoXys36BxQU7/rj5NWEfIz0SzQtQmIqCtnyO UIAw==
X-Gm-Message-State: ALoCoQnmRxNzq/gkefw3+jgZb/EO5WSP+/QT0ha3YZZLC75qb3NcULR1xZN1CSmHHZcpwSkdGEBN
MIME-Version: 1.0
X-Received: by 10.68.192.195 with SMTP id hi3mr31309617pbc.18.1380654070224; Tue, 01 Oct 2013 12:01:10 -0700 (PDT)
Received: by 10.70.34.44 with HTTP; Tue, 1 Oct 2013 12:01:10 -0700 (PDT)
In-Reply-To: <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=qzrNTb_-JbgOJA@mail.gmail.com>
References: <CADJ9OA9DYm5sA3AQMnqu5KikNU8ef-+tNZX36+qbn3J3Nexh7Q@mail.gmail.com> <CALEMV4bp2+hxcG=8RQtRqt4an6p2FJftsH8YYdxH24XMXZ-OiA@mail.gmail.com> <CAAzoce5VGo--V=-Ona-skaS62Kfvnf02eDE=qzrNTb_-JbgOJA@mail.gmail.com>
Date: Tue, 1 Oct 2013 12:01:10 -0700
Message-ID: <CALEMV4Zfh9XTpcp3nEa_mmLRj5MnGyKB1VEsssuzFWfS3ThDyw@mail.gmail.com>
From: Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu>
To: Qin Wang <qinwang@berkeley.edu>
Content-Type: multipart/alternative; boundary=047d7ba970e669e64104e7b293ca
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] minutes discussion models draft 1 October
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: xvilajosana@eecs.berkeley.edu
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2013 19:01:22 -0000

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 <qinwang@berkeley.edu> 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 <
> xvilajosana@eecs.berkeley.edu> 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 <
>> watteyne@eecs.berkeley.edu> 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
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>