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

Thomas Watteyne <watteyne@eecs.berkeley.edu> Tue, 01 October 2013 18:51 UTC

Return-Path: <twatteyne@gmail.com>
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 2295611E8227 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.634
X-Spam-Level:
X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 8JUYpF3f2tX8 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:51:27 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DB0FE11E8222 for <6tsch@ietf.org>; Tue, 1 Oct 2013 11:51:26 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id q10so7663674pdj.34 for <6tsch@ietf.org>; Tue, 01 Oct 2013 11:51:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=JoQiMwgUQYrMrtRl1OusmDVDokzKCnLI8Ftv4Byrfy8=; b=D1xPshbH12ry0Swe1Tf4tzONd5VOiur7UQu70uolui+/sXvmL1e64GUGjNNMl8hMJd gudTfpZhoRkxf4w5Pu8WdWMANE07HJvhrH//PSKCOe1fDpfJhCDIsxbed5biP22oWoIk sDU9fsgbbDL+vaLNYWaRLwjYu3Rm11C1DO+kwPU/w4Ec8v9lCDqxAPpv/KCskPju/7ix oqpG7hMNNJPihSe0+hie+NkZ1uxSYNY48i9pba3eQ4QyGeVlpU7j6M5quXMDIj7p2XNz pqszPBTsoJ/SzfXJzYhupaRbZORBh0sh3Yq1gCpb9CoDjdQioBN6Ni4fiCgFTTbcUBO5 lX0A==
X-Received: by 10.68.76.65 with SMTP id i1mr31172287pbw.37.1380653486510; Tue, 01 Oct 2013 11:51:26 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Tue, 1 Oct 2013 11:51:06 -0700 (PDT)
In-Reply-To: <CALEMV4bp2+hxcG=8RQtRqt4an6p2FJftsH8YYdxH24XMXZ-OiA@mail.gmail.com>
References: <CADJ9OA9DYm5sA3AQMnqu5KikNU8ef-+tNZX36+qbn3J3Nexh7Q@mail.gmail.com> <CALEMV4bp2+hxcG=8RQtRqt4an6p2FJftsH8YYdxH24XMXZ-OiA@mail.gmail.com>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Tue, 1 Oct 2013 11:51:06 -0700
X-Google-Sender-Auth: Pz2rfnKqV5rYQqwOaB7WlHPKdpI
Message-ID: <CADJ9OA-7GGPJjyG674HTk6Gf=kDFBJkxFy-vEEwiDkvLVvCtKw@mail.gmail.com>
To: 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=e89a8f923c649f1ad304e7b270b8
Subject: Re: [6tsch] minutes discussion models draft 1 October
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 18:51:30 -0000

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 <
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
>>
>>
>