Subject: Re: [6tisch] FW: New Version Notification for draft-sudhaakar-6tisch-coap-01.txt

From: Qin Wang <[email-masked]>
Date: Tue, 1 Apr 2014 15:47:01 -0700 (PDT)

Hi Raghuram and Pouria,

As you explain, the management resource is R/W data, and information resource is Read-only resource. In YANG model, the feature is expressed with  "config" attribute, i.e. if config = false, then the corresponding data is Read-only, otherwise, the data will be R/W. 

I'm wondering if this "config" feature will be associated with uri automatically while mapping YANG model to 6tisch CoAP. 

Thanks
Qin

On Tuesday, April 1, 2014 5:08 AM, Raghuram Sudhaakar (rsudhaak) <[email-masked]> wrote:
 
A new version of ³6TiSCH Resource Management and Interaction using CoAP²
draft has been posted. The authors request the group to review and comment.

-raghuram

On 3/29/14, 8:59 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-sudhaakar-6tisch-coap-01.txt
>has been successfully submitted by Raghuram S Sudhaakar and posted to the
>IETF repository.
>
>Name:        draft-sudhaakar-6tisch-coap
>Revision:    01
>Title:        6TiSCH Resource Management and Interaction using CoAP
>Document date:    2014-03-29
>Group:        Individual Submission
>Pages:        14
>URL:            
>http://www.ietf.org/internet-drafts/draft-sudhaakar-6tisch-coap-01.txt
>Status:        
>https://datatracker.ietf.org/doc/draft-sudhaakar-6tisch-coap/
>Htmlized:      http://tools.ietf.org/html/draft-sudhaakar-6tisch-coap-01
>Diff:          
>http://www.ietf.org/rfcdiff?url2=draft-sudhaakar-6tisch-coap-01
>
>Abstract:
>   The [IEEE802154e] standardizes the TSCH mode of operation and defines
>   the mechanisms for layer 2 communication between conforming devices.
>   6top defines a set of commands to monitor and manage the TSCH
>   schedule.  To realize the full functionality of sensor networks and
>   allow their adoption and use in real applications we need additional
>   mechanisms.  Specifically, we need to define how to interact with
>   6top, control and modify schedules, monitor parameters etc.  Higher
>   layers monitoring and management entities are then able to use these
>   capabilities to create feedback loops.  Although, there have been
>   many custom implementations of such feedback loops between the
>   routing, transport and MAC layers in sensor network deployments,
>   there has been a lack of standards based approaches.  The goal of the
>   memo is to define the messaging between monitoring and management
>   entities and the 6top layer and a mapping to the 6top commands.  The
>   document also presents a particular implementation of the generic
>   data model specified in [I-D.wang-6tisch-6top-interface] based on
>   CoAP and CBOR.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 1 Apr 2014 15:51:29 -0700

Wouldn't it be possible to keep the same URI, but authorize the PUT method
only on "config" parameters (i.e. return a 4.05 "Method not allowed" if
used on non-config data)?

On Tue, Apr 1, 2014 at 3:47 PM, Qin Wang <[email-masked]> wrote:

> Hi Raghuram and Pouria,
>
> As you explain, the management resource is R/W data, and information
> resource is Read-only resource. In YANG model, the feature is expressed
> with  "config" attribute, i.e. if config = false, then the corresponding
> data is Read-only, otherwise, the data will be R/W.
>
> I'm wondering if this "config" feature will be associated with uri
> automatically while mapping YANG model to 6tisch CoAP.
>
> Thanks
> Qin
>

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Wed, 2 Apr 2014 14:38:19 +0000

Qin,
The config attribute in the YANG model can be interpreted in two ways.

  1.  As an explicit method definition – i.e PUT/POST is enabled or not
  2.  As a logical check in the parser implementation (as Thomas suggests)

I lean towards option 2, as it easily allows us to make a resource R->R/W or R/W -> R without changing the methods/spec. We only need to remove/add the logical check in the parser.

Method #1 creates an explicit association between the config parameter and the URI – it defines what methods are allowed on the URI.

Method #2 also creates an association between the config parameter and the URI. However, it is not an explicit part of the URI but works behind the scenes.

-raghuram

From: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 1, 2014 at 3:51 PM
To: Qin Wang <[email-masked]<mailto:[email-masked]>>
Cc: raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pouria Zand <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] FW: New Version Notification for draft-sudhaakar-6tisch-coap-01.txt

Wouldn't it be possible to keep the same URI, but authorize the PUT method only on "config" parameters (i.e. return a 4.05 "Method not allowed" if used on non-config data)?

On Tue, Apr 1, 2014 at 3:47 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Raghuram and Pouria,

Thanks
Qin

On Tuesday, April 1, 2014 5:08 AM, Raghuram Sudhaakar (rsudhaak) <[email-masked]<mailto:[email-masked]>> wrote:
A new version of ³6TiSCH Resource Management and Interaction using CoAP²
draft has been posted. The authors request the group to review and comment.

-raghuram

On 3/29/14, 8:59 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
wrote:

>until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
>The IETF Secretariat
>

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Qin Wang <[email-masked]>
Date: Wed, 2 Apr 2014 10:38:24 -0700 (PDT)

I like method #2 also.

In this sense, do we still need the flag of "management resource" / "information resource"?

Thanks
Qin
On Wednesday, April 2, 2014 10:39 PM, Raghuram Sudhaakar (rsudhaak) <[email-masked]> wrote:
 
Qin,

-raghuram

From: Thomas Watteyne <[email-masked]>
Date: Tuesday, April 1, 2014 at 3:51 PM
To: Qin Wang <[email-masked]>
Cc: raghuram sudhaakar <[email-masked]>, "[email-masked]" <[email-masked]>, Pouria Zand <[email-masked]>
Subject: Re: [6tisch] FW: New Version Notification for draft-sudhaakar-6tisch-coap-01.txt

Hi Raghuram and Pouria,