Re: [6tsch] minutes discussion models draft 1 October
Qin Wang <qinwang@berkeley.edu> Tue, 01 October 2013 19:06 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 87FC521E80C5 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.715
X-Spam-Level:
X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.261, 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 FBtQWmF5sfwC for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:06:38 -0700 (PDT)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0E95411E8273 for <6tsch@ietf.org>; Tue, 1 Oct 2013 12:06:30 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id u16so14873225iet.33 for <6tsch@ietf.org>; Tue, 01 Oct 2013 12:06:29 -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=9KyLaIMu4CcYq4ToHuKfVAsCLe3jYlsFiGKJr8p40lQ=; b=YUgw5b5wioEjEOMjGyhql9QDJGtNI/W2OXXOLs+eFNyvgbO+bzeKpI2X/+sw/QiLlv niklwtSjZsu5cOo1CQTRgSPue/uX1f3R1ak+Tz1NLlPvpcXXwkvwlLtL3nGKwn6hCYI/ D7qR3uvlJuk1L/ieM8odaB+Gg4Ove1ab2jnRkRFcH811VA9a4eAkrz06QUpWfHTyVrt3 ZrISGzV3pFqMZR05AptqlhlNpa7gjK8BdW6Qt8OL1ldjUGGGReMSYEAnxIgkG8xn3J1d F4SlQ3hP84B5FMuomm85tEPworSaso2DNrpiQGfxE3ZYoNzanNTVA4renxG1TXQ0ugFA BCFA==
X-Gm-Message-State: ALoCoQlJaCEjEQxbdsB12F4b3muEO0PfQSjOnsitmMthpXdNp5DG07m0cHap8UDPHZx6EU87RlLa
MIME-Version: 1.0
X-Received: by 10.50.43.170 with SMTP id x10mr19263241igl.45.1380654389356; Tue, 01 Oct 2013 12:06:29 -0700 (PDT)
Received: by 10.64.130.234 with HTTP; Tue, 1 Oct 2013 12:06:29 -0700 (PDT)
In-Reply-To: <CALEMV4Zfh9XTpcp3nEa_mmLRj5MnGyKB1VEsssuzFWfS3ThDyw@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> <CALEMV4Zfh9XTpcp3nEa_mmLRj5MnGyKB1VEsssuzFWfS3ThDyw@mail.gmail.com>
Date: Wed, 02 Oct 2013 03:06:29 +0800
Message-ID: <CAAzoce5uJty2gASusJmTVXocyaANjaGauC6R_HVtUnrrnakorA@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary="089e01176cad6fa79404e7b2a677"
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
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:06:47 -0000
Xavi, Agree! Qin On Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Guillen < xvilajosana@eecs.berkeley.edu> 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 <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] minutes discussion models draft 1 October Thomas Watteyne
- Re: [6tsch] minutes discussion models draft 1 Oct… Xavier Vilajosana Guillen
- Re: [6tsch] minutes discussion models draft 1 Oct… Thomas Watteyne
- Re: [6tsch] minutes discussion models draft 1 Oct… Qin Wang
- Re: [6tsch] minutes discussion models draft 1 Oct… Thomas Watteyne
- Re: [6tsch] minutes discussion models draft 1 Oct… Xavier Vilajosana Guillen
- Re: [6tsch] minutes discussion models draft 1 Oct… Qin Wang
- Re: [6tsch] minutes discussion models draft 1 Oct… Qin Wang
- Re: [6tsch] minutes discussion models draft 1 Oct… Maria Rita PALATTELLA
- Re: [6tsch] minutes discussion models draft 1 Oct… Romascanu, Dan (Dan)
- Re: [6tsch] minutes discussion models draft 1 Oct… Pascal Thubert (pthubert)
- Re: [6tsch] minutes discussion models draft 1 Oct… Romascanu, Dan (Dan)
- Re: [6tsch] minutes discussion models draft 1 Oct… Maria Rita PALATTELLA