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

Qin Wang <qinwang@berkeley.edu> Tue, 01 October 2013 19:03 UTC

Return-Path: <qinwang@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 8587D21E826C for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 0XYFs6IFQlbe for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:03:33 -0700 (PDT)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id C25C221E8286 for <6tsch@ietf.org>; Tue, 1 Oct 2013 12:03:19 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id e14so14851579iej.38 for <6tsch@ietf.org>; Tue, 01 Oct 2013 12:03:19 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rCQp3TCDX+UjhiI6qnPq6XAkI6HtuTB28IjHT5z2tXU=; b=Ptwdqk/wJch4QLqYRifxJvFgSFPd6c5U5BJFMpL9ecg6zZGThJJy37v59Mi9v7daCT eifCbfsRkg90IrTEjR7RXPuDRN+hW3KT4R4ljnwd7vMLDb0RYy9fOPmybeXe/Z3QSTcg yTsAFXyETPhFZ1gUUVa3EaHLK7su9FEyapEOyIDZ9NY96kbTAbPkSktXQXgEB61Zzhxy zfNeTKST7uPbdajUIepPuNupQjD0OAQlzB3s6/D0JmZyAf6X+Mg/ZWmIgPBiDZj399vc ryP/o8on8SjUJUNID6pob0KEvk2y2hO0XAhP7AhbbfgTosPzK9N5IEz6l0GAbtZ06Xs2 ntOw==
X-Gm-Message-State: ALoCoQneZeHSBYXnM94+FYnOWHUUjXGom4d22U9YE9+e0clcCuzytJsnFmF8iIIAXp35ecrqEBXl
MIME-Version: 1.0
X-Received: by 10.50.66.101 with SMTP id e5mr19362286igt.26.1380654199113; Tue, 01 Oct 2013 12:03:19 -0700 (PDT)
Received: by 10.64.130.234 with HTTP; Tue, 1 Oct 2013 12:03:19 -0700 (PDT)
In-Reply-To: <CADJ9OA9aAEgHUuooSpV5opSb+Q=3moqGousMg64EmGKoN0odvQ@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> <CADJ9OA9aAEgHUuooSpV5opSb+Q=3moqGousMg64EmGKoN0odvQ@mail.gmail.com>
Date: Wed, 2 Oct 2013 03:03:19 +0800
Message-ID: <CAAzoce7bxk=W1xmHAU_M5peWi3-s8xRLGQZtrF2J4ufctqPEnA@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary=001a1135ec0c189af904e7b29bc5
Cc: 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
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:03:38 -0000

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
<watteyne@eecs.berkeley.edu>wrote:

> I don't believe we want to split this draft even more, right?
>
>
> 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
>>>
>>>
>>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>