Subject: [6tisch] content of 6top-interface draft

From: Qin Wang <[email-masked]>
Date: Wed, 5 Feb 2014 02:25:28 +0800

Hi All,

The 6top-interface draft -00 has been published,
http://www.ietf.org/internet-drafts/draft-wang-6tisch-6top-interface-00.txt.
For improving it, I would like to continue our discussion on last CALL
about the content of the draft.

Here is the related description in Charter.
"2. Produce an Information Model containing the management requirements
of a 6TiSCH node. This includes describing how an entity can manage the
TSCH schedule on a 6TiSCH node, and query timeslot information from that
node. A data model mapping for an existing protocol (such as Concise
Binary Object Representation (CBOR) over the Constrained Application
Protocol (CoAP)) will be provided."

According to my understanding, the draft corresponding to the item should
include two parts, i.e.
(1) How an entity can manage the TSCH schedule on a 6TiSCH node, ...
(2) Data model

I think 6top YANG model is corresponding to (2), and 6top commands is the
answer to (1).  In another word, the draft, which corresponds to the item 2
of charter, should describe both 6top YANG model and 6top commands.

What do you think?

Thanks
Qin

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 4 Feb 2014 20:47:28 +0100

Hi Qin,

I agree with you. The YANG model is the most important part as defines the
MIB for 6top. This is generic enough to be used for different management
approaches (centralized/distributed). I see the list of commands as a
helper interface, what matters from IETF point of view are the information
that travels "over the air" so interfaces are less important. However they
are still good to define internal processes or intra-node layer relations.
I see both in the interface draft.

regards,
Xavi

On Tue, Feb 4, 2014 at 7:25 PM, Qin Wang <[email-masked]> wrote:

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

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 5 Feb 2014 00:08:20 -0800

Qin,

I agree with everything Xavi says. For me, the real "body" of the interface
draft is the YANG model. The set of commands can be seen as a conceptual
interface which helps describe the 6top sublayer. IMO, it's find to have
the commands either in the interface of sublayer draft.

Thomas

---

From: Qin Wang <[email-masked]>
Date: Wed, 5 Feb 2014 23:15:41 +0800

Hi Xavi and Thomas,

I agree with what you said. More concretely, in the current version, the
mapping from 6top commands to TSCH primitives is described in 6top command
section. I wonder if it should be remained as it is or moved to sublayer
draft?

Thanks
Qin

On Wed, Feb 5, 2014 at 4:08 PM, Thomas Watteyne
<[email-masked]>wrote:

> Qin,
>
> I agree with everything Xavi says. For me, the real "body" of the
> interface draft is the YANG model. The set of commands can be seen as a
> conceptual interface which helps describe the 6top sublayer. IMO, it's find
> to have the commands either in the interface of sublayer draft.
>
> Thomas
>
>
>> I agree with you. The YANG model is the most important part as defines
>> the MIB for 6top. This is generic enough to be used for different
>> management approaches (centralized/distributed). I see the list of commands
>> as a helper interface, what matters from IETF point of view are the
>> information that travels "over the air" so interfaces are less important.
>> However they are still good to define internal processes or intra-node
>> layer relations. I see both in the interface draft.
>>
>> regards,
>> Xavi
>>
>>
>>> According to my understanding, the draft corresponding to the item
>>> should include two parts, i.e.
>>> I think 6top YANG model is corresponding to (2), and 6top commands is
>>> the answer to (1).  In another word, the draft, which corresponds to the
>>> item 2 of charter, should describe both 6top YANG model and 6top commands.
>>>
>>> What do you think?
>>>
>>> Thanks
>>> Qin
>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 5 Feb 2014 10:10:34 -0800

Qin,

As the editor of both 6top drafts, it's really your call.

My *personal* opinion is that the list of 6top commands defines a
conceptual interface internal to the device, which does not have to be
implemented exactly to remain compliant. Moreover, presenting the list of
6top commands necessarily comes with discussions about what it does to the
6top sublayer, and how it ties into the TSCH primitives. So it will need to
appear in the sublayer draft in some shape anyways. For these reasons, I
believe the list of 6top commands belongs in the sublayer draft. Note that
the discussion above does not apply to the YANG data model, which clearly
belongs in the interface draft.

What do others think?

Thomas

On Wed, Feb 5, 2014 at 7:15 AM, Qin Wang <[email-masked]> wrote:

> On Wed, Feb 5, 2014 at 4:08 PM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> Qin,
>>

---

From: Qin Wang <[email-masked]>
Date: Thu, 6 Feb 2014 03:13:42 +0800

Thomas,

I totally agree with you that the command list, its behavior description,
and its interaction with TSCH primitives should belong to sublayer draft,
and even If the interface draft has a section about command list, that
works as helper as Xavi said.

But, I still feel we miss something in the interface draft, because the
current version of 6top YANG model only defines 6top MIB in YANG, does not
include how to operate the MIB, in another word, how a entity interact with
TSCH schedule via accessing 6top MIB. I guess the missing part is 6top RPC
(Remote Procedure Call) in YANG, if it is not the command list.

What do you think?

Qin

On Thu, Feb 6, 2014 at 2:10 AM, Thomas Watteyne
<[email-masked]>wrote:

>>>>> For improving it, I would like to continue our discussion on last
>>>>> CALL about the content of the draft.
>>>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 5 Feb 2014 15:06:42 -0800

Qin,

I see what you mean. If I understand correctly, what you are suggesting is
to:
- move the 6top command to the sublayer draft
- add text in the interface draft to describe how interacting with the
YANG-based data model translates into calls to the 6top commands

Please correct me if I'm wrong.

This does make sense a priori. That being said, I would imagine that the
YANG-based data model translates almost 1-to-1 to 6top commands. For
example, an creating an element in the cellList causes the CREATE.cell
command to be called. If this is true, this "glue text" between the YANG
data model and the 6top commands can be kept to a minimum.

What do others think?

Thomas

On Wed, Feb 5, 2014 at 11:13 AM, Qin Wang <[email-masked]> wrote:

> On Thu, Feb 6, 2014 at 2:10 AM, Thomas Watteyne <

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Thu, 6 Feb 2014 12:36:49 +0100

Hi Thomas, all,

I see this glue text as a sequence diagram describing the actions that are
triggered when a packet containing a representation of an element of the
YANG model is received in a node. If the mapping is 1 to 1 then it does not
make a lot of sense to have text indicating that. However if the received
information requires a complex set of actions to happen then would be good
to have that description.

What would also be interesting is to differentitate READ elements in MIB
from WRITE elements in the MIB. For example statistics seem to be read-only
elements in the MIB (from an external point of view) while CellList can be
READ/WRITE elements. So it seems that at least we need to describe the way
the MIB can be used.

what do you think?

On Thu, Feb 6, 2014 at 12:06 AM, Thomas Watteyne <[email-masked]
> wrote:

>>>> I agree with what you said. More concretely, in the current version,
>>>> the mapping from 6top commands to TSCH primitives is described in 6top
>>>> command section. I wonder if it should be remained as it is or moved to
>>>> sublayer draft?
>>>>
>>>> Thanks
>>>> Qin
>>>>
>>>>
>>>>
>>>>
>>>>>> I agree with you. The YANG model is the most important part as
>>>>>> defines the MIB for 6top. This is generic enough to be used for different
>>>>>> On Tue, Feb 4, 2014 at 7:25 PM, Qin Wang <[email-masked]>wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I think 6top YANG model is corresponding to (2), and 6top commands
>>>>>>> is the answer to (1).  In another word, the draft, which corresponds to the

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Thu, 6 Feb 2014 14:25:45 +0000

Are READ and WRITE the only way to get information out of / into the MIB?
Thanks,
Pat

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana Guillen
Sent: Thursday, February 06, 2014 6:37 AM
To: Thomas Watteyne
Cc: [email-masked]; Qin Wang
Subject: Re: [6tisch] content of 6top-interface draft

Hi Thomas, all,

I see this glue text as a sequence diagram describing the actions that are triggered when a packet containing a representation of an element of the YANG model is received in a node. If the mapping is 1 to 1 then it does not make a lot of sense to have text indicating that. However if the received information requires a complex set of actions to happen then would be good to have that description.

What would also be interesting is to differentitate READ elements in MIB from WRITE elements in the MIB. For example statistics seem to be read-only elements in the MIB (from an external point of view) while CellList can be READ/WRITE elements. So it seems that at least we need to describe the way the MIB can be used.

what do you think?

On Thu, Feb 6, 2014 at 12:06 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Qin,

I see what you mean. If I understand correctly, what you are suggesting is to:
- move the 6top command to the sublayer draft
- add text in the interface draft to describe how interacting with the YANG-based data model translates into calls to the 6top commands

This does make sense a priori. That being said, I would imagine that the YANG-based data model translates almost 1-to-1 to 6top commands. For example, an creating an element in the cellList causes the CREATE.cell command to be called. If this is true, this "glue text" between the YANG data model and the 6top commands can be kept to a minimum.

What do others think?

Thomas

On Wed, Feb 5, 2014 at 11:13 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,

I totally agree with you that the command list, its behavior description, and its interaction with TSCH primitives should belong to sublayer draft, and even If the interface draft has a section about command list, that works as helper as Xavi said.

But, I still feel we miss something in the interface draft, because the current version of 6top YANG model only defines 6top MIB in YANG, does not include how to operate the MIB, in another word, how a entity interact with TSCH schedule via accessing 6top MIB. I guess the missing part is 6top RPC (Remote Procedure Call) in YANG, if it is not the command list.

What do you think?

Qin

On Thu, Feb 6, 2014 at 2:10 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Qin,

My personal opinion is that the list of 6top commands defines a conceptual interface internal to the device, which does not have to be implemented exactly to remain compliant. Moreover, presenting the list of 6top commands necessarily comes with discussions about what it does to the 6top sublayer, and how it ties into the TSCH primitives. So it will need to appear in the sublayer draft in some shape anyways. For these reasons, I believe the list of 6top commands belongs in the sublayer draft. Note that the discussion above does not apply to the YANG data model, which clearly belongs in the interface draft.

What do others think?

Thomas

On Wed, Feb 5, 2014 at 7:15 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Xavi and Thomas,

I agree with what you said. More concretely, in the current version, the mapping from 6top commands to TSCH primitives is described in 6top command section. I wonder if it should be remained as it is or moved to sublayer draft?

Thanks
Qin

On Wed, Feb 5, 2014 at 4:08 PM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Qin,

I agree with everything Xavi says. For me, the real "body" of the interface draft is the YANG model. The set of commands can be seen as a conceptual interface which helps describe the 6top sublayer. IMO, it's find to have the commands either in the interface of sublayer draft.

Thomas

On Tue, Feb 4, 2014 at 11:47 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

I agree with you. The YANG model is the most important part as defines the MIB for 6top. This is generic enough to be used for different management approaches (centralized/distributed). I see the list of commands as a helper interface, what matters from IETF point of view are the information that travels "over the air" so interfaces are less important. However they are still good to define internal processes or intra-node layer relations. I see both in the interface draft.

regards,
Xavi

On Tue, Feb 4, 2014 at 7:25 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

The 6top-interface draft -00 has been published,  http://www.ietf.org/internet-drafts/draft-wang-6tisch-6top-interface-00.txt. For improving it, I would like to continue our discussion on last CALL about the content of the draft.

According to my understanding, the draft corresponding to the item should include two parts, i.e.
(1) How an entity can manage the TSCH schedule on a 6TiSCH node, ...
(2) Data model

I think 6top YANG model is corresponding to (2), and 6top commands is the answer to (1).  In another word, the draft, which corresponds to the item 2 of charter, should describe both 6top YANG model and 6top commands.

What do you think?

Thanks
Qin

_______________________________________________
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

_______________________________________________
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

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

---

From: Qin Wang <[email-masked]>
Date: Thu, 6 Feb 2014 22:51:38 +0800

Xavi,

We can add "config" statement in the read only data definition. Here is an
example in RFC6020.

list interface {
    key "name";
    leaf name {
      type string;
    }
   leaf speed {
     type enumeration {
         enum 10m;
         enum 100m;
         enum auto;
        }
    }
   leaf observed-speed {
     type uint32;
     config false;
   }
}

where observed-speed is READ-only and others are READ/WRITE.

What do you think?

Qin

On Thu, Feb 6, 2014 at 7:36 PM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> On Thu, Feb 6, 2014 at 12:06 AM, Thomas Watteyne <
>>> I totally agree with you that the command list, its behavior
>>> description, and its interaction with TSCH primitives should belong to
>>> sublayer draft, and even If the interface draft has a section about command
>>> list, that works as helper as Xavi said.
>>>

---

From: Qin Wang <[email-masked]>
Date: Thu, 6 Feb 2014 23:21:00 +0800

Hi Pat,

According to RFC6020, YANG is used to model configuration and state data
manipulated by the Network Configuration Protocol (NETCONF). And, the
operations of NETCONF Protocol defined in RFC4741 include: get, get-config,
copy-config, delete-config, edit-config, and some others. Particularly,
edit-config can be one of Merge/Replace/Create/Delete. It is more than Read
and Write. In addition, I think the operations of NETCONF can cover what we
need in 6top, i.e. Create/Read/Update/Delete.

What do you think?

Qin

On Thu, Feb 6, 2014 at 10:25 PM, Brett, Patricia (PA62) <
[email-masked]> wrote:

> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Xavier
> Vilajosana Guillen
> *Sent:* Thursday, February 06, 2014 6:37 AM
> *To:* Thomas Watteyne
> *Cc:* [email-masked]; Qin Wang
> *Subject:* Re: [6tisch] content of 6top-interface draft
>
>
>
> Hi Thomas, all,
>
>
>

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Thu, 6 Feb 2014 16:14:31 +0000

Hi Qin,
That certainly covers configuration.  Do you think it is also enough to support troubleshooting?
Regards,
Pat

From: Qin Wang [mailto:[email-masked]]
Sent: Thursday, February 06, 2014 10:21 AM
To: Brett, Patricia (PA62)
Cc: [email-masked]; Thomas Watteyne; [email-masked]
Subject: Re: [6tisch] content of 6top-interface draft

Hi Pat,

According to RFC6020, YANG is used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF). And, the operations of NETCONF Protocol defined in RFC4741 include: get, get-config, copy-config, delete-config, edit-config, and some others. Particularly, edit-config can be one of Merge/Replace/Create/Delete. It is more than Read and Write. In addition, I think the operations of NETCONF can cover what we need in 6top, i.e. Create/Read/Update/Delete.

What do you think?

Qin

On Thu, Feb 6, 2014 at 10:25 PM, Brett, Patricia (PA62) <[email-masked]<mailto:[email-masked]>> wrote:
Are READ and WRITE the only way to get information out of / into the MIB?
Thanks,
Pat

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xavier Vilajosana Guillen
Sent: Thursday, February 06, 2014 6:37 AM
To: Thomas Watteyne
Cc: [email-masked]<mailto:[email-masked]>; Qin Wang
Subject: Re: [6tisch] content of 6top-interface draft

Hi Thomas, all,

what do you think?

What do others think?

Thomas

What do you think?

Qin

What do others think?

Thomas

Thanks
Qin

Thomas

regards,
Xavi

What do you think?

Thanks
Qin

---

From: Qin Wang <[email-masked]>
Date: Fri, 7 Feb 2014 02:24:46 +0800

Hi Pat,

According to my understanding, those operations defined in NETCONF are
basic operations. On top of them, other higher level operations can be
defined. For example, something like Observer of CoAP may be able to
support troubleshooting.

Thanks
Qin

On Fri, Feb 7, 2014 at 12:14 AM, Brett, Patricia (PA62) <
[email-masked]> wrote:

> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* Thursday, February 06, 2014 10:21 AM
> *To:* Brett, Patricia (PA62)
> *Cc:* [email-masked]; Thomas Watteyne; [email-masked]
>

---

From: Pat Kinney <[email-masked]>
Date: Thu, 6 Feb 2014 17:16:26 -0600

During last week's 6tisch call, I committed to sending the following information to the 6tisch reflector:
changes to IEs since 802.15.4e (i.e. MAC changes since 802.15.4e)
how the IEEE 802 works (i.e. IEEE 802.15 information on process)
Information on IG 6tisch reflector and conference calls

The attachment to this email fulfills the above commitment

Regards, Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

---

From: Rene Struik <[email-masked]>
Date: Thu, 06 Feb 2014 19:08:01 -0500

Hi Pat:

Great. If you could also expand on the complete picture w.r.t. the 
802.15.4-2011 rev effort (see my email as of earlier this afternoon, 
copied below), that would be great.

[excerpt of email RS as of Thu Feb 6, 2014, 3:04pm EST]
It would help the 6tisch community to understand somewhat more the 
timeline for the 802.15.4-2011 revision effort. While the below info in 
the minutes is not necessarily incorrect, this reflects letter ballot 
and sponsor ballot timelines, but does not address when proposals are 
expected. Isn't the timeline for that the March 17-21, 2014 meeting, if 
I remember the outcome of the Jan 2014 IEEE 802 meeting correctly? Also, 
if you could cross-reference some IEEE 802 documents on the server for 
the benefit of 6tisch fans that would be great.

On 2/6/2014 6:16 PM, Pat Kinney wrote:
>  1. changes to IEs since 802.15.4e (i.e. MAC changes since 802.15.4e)
>  2. how the IEEE 802 works (i.e. IEEE 802.15 information on process)
>  3. Information on IG 6tisch reflector and conference calls
>
>
> */Kinney Consulting LLC/*
> <mailto:[email-masked]>
>
>
>
>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363