Great!
On Thursday, August 16, 2018, 9:38:13 AM EDT, The IESG
wrote:
The IESG has approved the following document:
- '6TiSCH Operation Sublayer Protocol (6P)'
(draft-ietf-6tisch-6top-protocol-12.txt) as Proposed Standard
This document is the product of the IPv6 over the TSCH mode of
Hi Alexey,
Thank you for your further comments. Please see inline.
Qin
On Thursday, April 12, 2018, 1:20:01 PM EDT, Alexey Melnikov
wrote:
Hi Xavi,
On Fri, Apr 6, 2018, at 4:39 PM, Xavi Vilajosana Guillen wrote:
Dear Alexey,
We are answering here the two emails we received from you
Xavi,
The response to Nicola is very good.
Many thanksQin
On Monday, March 26, 2018, 1:53:26 AM EDT, Xavi Vilajosana Guillen
wrote:
Dear Nicola,
Thank you so much for your proposal and review of the draft. We did not answer
before as we wanted to discuss all the comments we received
notifying you in advance, and
thank you for your review again.
ThanksQin
On Monday, March 5, 2018 8:21 PM, Brian E Carpenter
wrote:
Hi,
On 27/02/2018 05:31, Qin Wang wrote:
...
> [Qin] Add following textin both section 3.1.1 and 3.1.2
> In case a race conditionhappens duri
Hi Bian,
Thank you for your comments. Please see inline.
On Friday, February 23, 2018 6:11 PM, Brian E Carpenter
wrote:
Hi Qin, see in line:
On 24/02/2018 04:16, Qin Wang wrote:
> Hi Brian,
> Thank you very much for your comments. Please see inline.
>
> On Monday, Febru
Hi Brian,
Thank you very much for your comments. Please see inline.
On Monday, February 19, 2018 6:22 PM, Brian Carpenter
wrote:
Reviewer: Brian Carpenter
Review result: Ready with Issues
Gen-ART Last Call review of draft-ietf-6tisch-6top-protocol-09
I am the assigned Gen-ART reviewer fo
Pascal and Diego, thank you very much for your comments.
Xavi, let me know what I can help.
ThanksQin
On Friday, September 29, 2017 8:30 AM, Xavi Vilajosana Guillen
wrote:
Hi,
yes I will do it asap.
thanks Pascal for the comments!!X
2017-09-29 14:12 GMT+02:00 Thomas Watteyne :
Thanks
No, I'm not aware of any IPR that applies to this draft.
Qin
On Tuesday, September 26, 2017 4:16 AM, Pascal Thubert (pthubert)
wrote:
Authors,
Contributors, WG, As part of the preparation for WG Adoption Call: Are
you aware of any IPR that applies to drafts identified above?
mandatory. This idea can maintain the consistency with ADD
and DELETE. Which one do you think is better? Using the empty cell or using
two CellLists in the response message? Best regards, Remy From: Qin Wang
[mailto:qinwang6...@yahoo.com]
Sent: Thursday, September 07, 2017 3:39 AM
To: Liubing
Hi Ramy,
I can see your point. I think, as you proposed, a list of relocated cells in
Response message may be a good idea, because it supports more flexibility. Take
Fig 15 as an example. Assume only (4,2) is available at nodeB. If (1,2) is
relocated to (4,2), then, the list of relocated cells
Hi Diego,
I'm not sure if you got this email. So, I re-send it.
ThanksQin
On Monday, May 1, 2017 5:22 PM, Qin Wang wrote:
Dear authors,
I read through SF0 (v4). The following is my comments.
2. Introduction ü “The Scheduling Algorithmcollects the cell
allocation/deletionrequests
defined and explained in SF0 draft. What do you think?
Thanks Qin
On Wednesday, June 7, 2017 3:54 PM, Qin Wang wrote:
Hi Jonathan,
Thank you very much for your review. Please see inline.
Qin
On Wednesday, June 7, 2017 11:21 AM, Jonathan Muñoz
wrote:
Dear 6P authors, W.G,
I
Hi Jonathan,
Thank you very much for your review. Please see inline.
Qin
On Wednesday, June 7, 2017 11:21 AM, Jonathan Muñoz
wrote:
Dear 6P authors, W.G,
I read the 6top Protocol draft - v05, and I find it very clear. I have some
questions and few comments. Hopefully you'll find them u
Hi Diego and all,
According to my understanding, TTL is the lifetime of a Message and its
function is different from Timeout. For example, when nodeA sends a ADD-Request
to nodeB, nodeA can set Timeout in a local Timer counting for the maximum
waiting time for Response from nodeB, and, at same t
Hi Diego,
Just below Figure 1, the text is as follows.
-1. If
REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more cells.2. If
(SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do nothing.3.
If SC
Dear authors,
I read through SF0 (v4). The following is my comments.
2. Introduction
ü “The Scheduling Algorithmcollects the cell allocation/deletionrequests from
the neighbors and thenumber of cells which are currently under usage.” ==>
addition/deletion? allocation/deallocation?
4. SF0
Hi Remy,
Regarding to your question on 4.2.6. 6P CellOptions, the first column is the
cell's type from node A's point of view, and the second column is the cell's
type from node B's point of view. Does it make sense?
ThanksQin
On Thursday, February 2, 2017 8:09 AM, Remy Leone
wrote:
Hi Xavi,
I have just read minimal v19, and the difference between v18 and v19. I have
some comments as follows.(1) In section 8, K2 is used to replace KL in the
sentence "Provisioning a network with a fixed link key K2 is not secure." I
wonder if it should be K1 instead of K2 to be used to repla
ction and decided to
CLEAR my TX cells to my current next hop and move on, I do not exactly know how
many cells have been allocated and what they are.
Does that make sense ?
Regards,
Sedat
On 21 Jan 2017 12:19 am, "Qin Wang" wrote:
Hi Sedat,
I think CLEAR is usually used when i
Hi Sedat,
I think CLEAR is usually used when inconsistency in schedules of a pair of
nodes is detected. In your case, DELETE, instead of CLEAR, can be used. In
addition, DELETE already has CellOption field. Make sense?
ThanksQin
On Friday, January 20, 2017 11:22 AM, Sedat Gormus
wrote:
Hi Xavi,
Thanks for the summary. Please see inline.
>
>
>I tried to summarize the action items we identified during the call. Please
>comment if you do not agree. Here a list:
>
>
>1 clarify the use of RC_END_OF_LIST text upon receiving a list command and
>reaching the end of the list
[Qin]: ag
Hi Simon,
I agree to your detailed analysis about with/without adding Confirmation. I
would like add the possible processes after the transactions.
After 2-way transaction, node A will find the inconsistency by generation
counter when it starts a new transaction. And then, node A can send CLEAR
Hi Yatch and all,
I think 6top as a sublayer should support broadcast/multicast, but it may not
necessary for 6P to support scheduling cells for broadcast/multicast
dynamically. There may be two solutions for broadcast/multicast. One is use EB
cell in slotframe 0, because it is not supposed that
Hi Tengfei,
My impression on your proposal is that you are trying to use the combination of
the length of ADD CellList and DELETE CellList as sort of operation code.
Right? If 6P really needs so many operations, why do we just add more operation
codes, which could cost just 1 more bit?
ThanksQin
+1
Qin
On Friday, December 9, 2016 6:23 AM, peter van der Stok
wrote:
+1 peter
I hope the bootstrap drafts can be combined.
Tengfei Chang schreef op 2016-12-09 11:45:
> +1. I support to adopt this draft. It's important to have this secure
> joining process in 6TiSCH network.
>
> Teng
consistency until a subsequent transaction; it
may take a long time.
The reactive approach using timeout doesn't have such disadvantages;
furthermore, it's simpler than the the schedule generation management,
in my opinion.
I still cannot see why the generation management at 6P is re
to confirm inconsistency if the schedule generation
inconsistency detection was disabled...
Best,
Yatch
On 2016/11/29 22:40, Qin Wang wrote:
> Hi Yasuyuki,
>
> I'm not sure I fully understand you.
>
> Let's assume node A wants to ADD cells with nodeB in 2-step
> transaction.
Hi Yasuyuki,
I'm not sure I fully understand you.
Let's assume node A wants to ADD cells with nodeB in 2-step transaction. After
nodeA sends ADD Request to nodeB, the Timeout of nodeA is set. nodeB receives
the ADD Request, adds the cells to its schedule and sends Response back to
nodeA at same
Hi Yasuyuki,
Regarding to the reasons of inconsistent allocation asked in your email, I
think, roughly speaking, they are (1) failure in communication because of PHY
problems like bed channel condition, collision, and (2) failure in processing
because of MAC problems such as buffer overflow.
Th
+1
Qin
On Wednesday, November 23, 2016 3:37 PM, Kristofer PISTER
wrote:
+1
ksjp
On Wed, Nov 23, 2016 at 5:15 AM, Prof. Diego Dujovne
wrote:
+1
El nov 23, 2016 10:06 AM, "Xavi Vilajosana Guillen"
escribió:
Hi, I also support this draft as a zero touch approach to enable secure join
+1Qin
On Wednesday, November 23, 2016 2:56 AM, Pascal Thubert (pthubert)
wrote:
Dear all :
The sense of the room at the WG meeting at IETF 97 in Seoul was that
draft-richardson-6tisch-dtsecurity-secure-join and
draft-vucinic-6tisch-minimal-security could be combined as a staged join
+1
Qin
On Tuesday, November 22, 2016 2:17 AM, Thomas Watteyne
wrote:
In thread "Node Behavior at Boot in SF0"
(https://www.ietf.org/mail-archive/web/6tisch/current/msg04883.html), we ended
up discussing the following paragraph
https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-0
Hi Thomas,
>From the SF0 presentation slides, I can see the Timeout mechanism is still in
>discussion. It is not clear who will be responsible for setting Timeout, SF0
>or 6P. And this modification you mentioned is related. Right? Maybe I missed
>something.
ThanksQin
On Wednesday, November
Hi Nicola and Diego,
Since we agree Timeout is needed no matter what schemes we will choose, let's
make calculation about the Timeout in different schemes. Assume:t1: Node A 6top
prepares ADD Requestt2: Node A 6top sends out ADD Request, ending with MAC-ACK
successt3: Node B 6top processes ADD R
Hi Nicola,
I want to confirm my understanding first.
Your proposal is to introduce a new 6P message, i.e. 6P ACK message, into a
transaction, then the sequence of a original 2-way ADD transaction will be: (1)
node A SF0 sets "adding TX cells" OPEN, and 6top layer sends ADD request to
nodeB(2) n
the priority field for example also interesting.
I agree however that we use 5-extra bits per requested cell and that the
timekeeping and priority fields are not in the scope as of today. Maybe even 8
if we leave some reserved bits as 15.4.
thoughts?X
2016-10-05 17:27 GMT+02:00 Qin Wang :
Hi Tero
Hi Tero,
Thank you for the update.
According to my understanding, the flag used in 6P is trying to define the
communication direction of scheduled cell(s). So, I wonder if 2 bits flag is
enough.
ThanksQin
On Wednesday, October 5, 2016 11:03 AM, Tero Kivinen wrote:
Qin Wang writes
Hi Xavi,
In IEEE802.15.4e, LinkOptions is defined as follows.
Is it what you are going to use? Then, another way is to use two bits to
express TX/RX/Share. I'm not sure which way is better than another.
ThanksQin
On Wednesday, October 5, 2016 9:40 AM, Xavier Vilajosana
wrote:
Hi,
fo
Hi,
Regarding to how to choose a error code when multiple error codes could be
candidate, I think we can use a simple rule as follows. If a specific error
code, such as RC_ERR_NORES, is matched to the abnormal situation, then the
specific error code must be used. If there is no specific error co
Hi Xavi,
I think there are two scenarios which may result in the number of cells in the
CellList of response packet less than numCells_max, (1) when node B has N
cells, where Offset wrote:
Hi,
according to our discussion during the last 6TiSCH meeting I want to follow up
Tero's proposal for
Hi Pascal
In the paragraph"The SF may be seen as divided between an upper bandwidth
adaptation logic that is not aware of the particular technology that is used
to obtain and release bandwidth, and an underlying service sublayer that
maps those needs in the actual technology, which means m
Hi all,
I think Sedat raised a good question.
The explicit expression of LinkOption may be more flexible and more efficient
if we can find application in which a Node knows the need of two-way
communication bandwidth at a time. In another word, the current assumption for
implicit expression is
Hi Diego,
I understand your concern and your proposal to have two return codes
corresponding to no enough resource and candidate cells in Lock status. But I
think SF is better place to handle it. For example, in Metadata of response
message, 1-bit Flag can be used to distinguish (1) No Enough
+1
Qin
On Tuesday, May 24, 2016 1:22 PM, Xavier Vilajosana
wrote:
Looks good to me!
===A node MAY support concurrent 6P Transactions from different neighbors. In
this case the cells involved in the ongoing 6P transaction MUST be locked until
the transaction finishes. For example, in
Hi Seema and Satish,
Thank you for your comments. We will correct the tpyo you mentioned.
Regarding to 3-step transaction, let me explain the motivation behind it.
Assume node A is a Child of node B, then usually node B has more knowledge
about the cell usage, right? But sometime, the Child may
Hi all,
Do we really need the term "Link"? IMO, "Link" in 6TiSCH is same as Bundle.
Right?
ThanksQin
On Friday, April 22, 2016 9:07 AM, Maria Rita PALATTELLA
wrote:
#yiv5085214591 #yiv5085214591 -- _filtered #yiv5085214591 {panose-1:2 4 5 3 5
4 6 3 2 4;} _filtered #yiv5085214591 {font
ually sync.
What do you think?
Pascal
Le 8 mars 2016 à 22:34, Qin Wang a écrit :
Hi Diego,
I also have question regarding to the third message, i.e. Child acknowledge.
In this case, the Child must accept the selected cells in the Parent's message
if it received the message. Right? In an
d the serialization of requests but I agree
that is a non goal today.
Regards,
Pascal
Le 8 mars 2016 à 22:10, Qin Wang a écrit :
Hi all,
I'm not convinced that token is necessary yet. From the discussion in the last
WG meeting, we have agreed that the Token is used in the 6P messag
Hi Diego,
I also have question regarding to the third message, i.e. Child acknowledge.
In this case, the Child must accept the selected cells in the Parent's message
if it received the message. Right? In another word, if the Parent knows the
Child has received the message correctly, the Parent c
Hi all,
I'm not convinced that token is necessary yet. From the discussion in the last
WG meeting, we have agreed that the Token is used in the 6P message exchange
between neighbors. Based on the agreement, let's consider the two following
scenarios.
(1) nodeA send ADD_Request(token=1) to nodeB,
Dear all,
In today's Webex meeting, we were talking about the feedback from Bonoit about
the new Charter, see [6tisch] Benoit Claise's No Objection on
charter-ietf-6tisch-01-00: (with COMMENT), and want to continue the discussion
in the ML.
The question is what is exactly we want to do with Yan
I think both of the two format are fine. But, if IEEE802.15 recommends the
second one, I think we should choose the second.
ThanksQin
On Monday, January 11, 2016 11:17 AM, "pat.kin...@kinneyconsultingllc.com"
wrote:
Thank you for the figures, I agree on both, especially the second one.
Hi Pascal and all,
I think chunk is a good idea to avoid conflicts in cell allocation. According
to my understanding, a Chunk is a part of a superframe, and thus inherits the
properties of the superframe like priority.
In the draft-ietf-6tisch-6top-interface, you can find two data structures
re
Hi Pat,
According to my understanding, in the TSCH mode of 802.15.4, if the attribute
of a slot is Shared, slotted- aloha access should be allowed in the slot. Right?
ThanksQin
On Friday, December 11, 2015 2:29 PM, "pat.kin...@kinneyconsultingllc.com"
wrote:
Xavi;
As I understand slot
Hi Maria Rita and all,
For support RPL structure of parent & children, I agree to think upstream and
downstream resource reservation separately. But, I'm not sure if we should use
3-phase protocol for upstream resource reservation, because that means 1/3
communication cost will be added for one
HI Charlie,
See the inline. I marked with names for others to read.
Hello Qin,
Thanks for your quick reply. Follow-up below...
On 10/27/2015 8:44 AM, Qin Wang wrote:
1.There is a strong need for non-local statistics, for instance flow
statistics[Qin] Since different Scheduling Function (SF
Hi Charlie,
Thank you very much for your comments. We will address the comments in your
attached file (Diff draft-wang-6tisch-6top-sublayer-03.txt -
draft-wang-6tisch-6top-sublayer-03cep.txt.htm) in the next version. In the
following, I would like to discuss with you regarding to your questions
Hi Pascal and all,
I don't understand the meaning of "with the capability for IoT routers to
appropriatechunks of the matrix without starving, or interfering with, other
6TiSCH nodes." (even IoT routers is replaced with "6tisch router"). I cannot
figure out what the capability is. Can you expla
Hi Pascal,
Can you explain more about "with the capabilityfor IoT routers to appropriate
chunks of the Time/frequency matrix withoutstarving, or interfering with, other
6TiSCH nodes."?
ThanksQin
On Friday, October 9, 2015 11:57 AM, Pascal Thubert (pthubert)
wrote:
Dear
all :
?
ThanksQin
On Wednesday, September 30, 2015 2:16 PM, Tero Kivinen
wrote:
Qin Wang writes:
> In the IEEE802.15.4e, there are two attributes related with a cell, i.e.
> LinkOption and LinkType. LinkOption indicates TX, RX, Shared, or Timekeeping;
> and LinkType indicates
the reader. Thanks for the reply!
Randy From: Qin Wang [mailto:qinwang6...@yahoo.com]
Sent: Wednesday, September 30, 2015 10:43 AM
To: Turner, Randy; 6tisch@ietf.org
Subject: Re: [6tisch] 6top-interface-04 Hi Randy, In the IEEE802.15.4e,
there are two attributes related with a cell, i.e.
Hi Randy,
In the IEEE802.15.4e, there are two attributes related with a cell, i.e.
LinkOption and LinkType. LinkOption indicates TX, RX, Shared, or Timekeeping;
and LinkType indicates Normal or Advertising. According to my understanding, if
the attributes of a cell are set as LinkOption = TX and
Hi Pat,
Since there are two approaches mentioned in the discussion, i.e. (1) containing
6top-to-6top message in a specific payload IE (coapie), (2) using the mechanism
provided by IEEE802.15.9 to convey the 6top-to-6top message, I would like to do
more evaluation. I couldn't find the IEEE802.15.
some answer? I may missed something.
ThanksQin
On Wednesday, July 22, 2015 12:36 AM, Tero Kivinen wrote:
Qin Wang writes:
> Before going to 802.15.9, I would like to discuss more about the
> coapie approach. In the 802.15.4e, the range (0x2-0x9) of group ID
> for payl
Hi Tero,
Thank you for your comments.
Before going to 802.15.9, I would like to discuss more about the coapie
approach. In the 802.15.4e, the range (0x2-0x9) of group ID for payload IE is
unmanaged. I thought IEEE802.15.4 WG had discussed how to use those Group ID,
and also taken the requirement
Hi All,
The new version 6top interface draft has been published
https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-interface/. One of the
new parts is the container SecurityAttributes of YANG model. According to the
discussion on WG meeting, the SecurityAttributes is designed following the
14, 2015 5:36 AM, Michael Richardson
wrote:
Qin Wang wrote:
> Thank you very much for your comments. Can I bring the discussion thread
to
> 6tisch ML?
Yes, you can forward, or I can reply. I will include my entire email if you
want... yeah let me just write.
I was
t. 237
michel.veille...@trilliantinc.comwww.trilliantinc.com |
From: Qin Wang [mailto:qinwang6...@yahoo.com]
Sent: 1 juillet 2015 11:28
To: Nicola Accettura; Michel Veillette
Cc: 6tisch@ietf.org; diego.dujo...@mail.udp.cl
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05 Hi Michel and Nicola,
I think Michel's
Hi Michel and Nicola,
I think Michel's idea is interesting. But, according to my understanding, the
Frame Pending setting just means there is frame following, does not mean that
the current bandwidth provided by TSCH schedule, including hard cells and soft
cells, is not enough to convey those fr
).
make sense?
ThanksQin
On Wednesday, June 10, 2015 9:12 PM, Michael Richardson
wrote:
Qin Wang wrote:
> NeighborList contains the Link information, and the information about
> Parent is contained in TimeSource for saving space. Make sense?
I don't see how container
Hi Michael,
Regarding to including DAG rank into 6top NeighborList, I think, besides RPL,
there may be other routing protocols working on top of 6top in the future.
Thus, it could be better to decouple 6top sublayer and upper layer protocol
like RPL.
What do you think?
What other people think?
[mailto:6tisch-boun...@ietf.org]On Behalf Of
Qin Wang
Sent: mardi 9 juin 2015 13:58
To: Michael Richardson; 6tisch@ietf.org
Subject: Re: [6tisch] 6top and neighbour list Hi Michael, NeighborList
contains the Link information, and the information about Parent is contained in
TimeSource for saving
37
michel.veille...@trilliantinc.com www.trilliantinc.com |
From: Qin Wang [mailto:qinwang6...@yahoo.com]
Sent: 9 juin 2015 16:46
To: Michel Veillette; Michael Richardson; 6tisch@ietf.org
Subject: Re: [6tisch] 6top and neighbour list Hi Michael and Michel, The
attached file is the Yang mode
Hi Michael,
NeighborList contains the Link information, and the information about Parent is
contained in TimeSource for saving space. Make sense?
ThanksQin
On Wednesday, June 10, 2015 1:33 AM, Michael Richardson
wrote:
1) I was reading draft-ietf-6tisch-6top-interface-03.
2) It
Hi Michael and Michel,
The attached file is the Yang model, which has been embedded into 6top
interface draft.
ThanksQin
On Wednesday, June 10, 2015 4:23 AM, Michel Veillette
wrote:
Hi Michael
You will find in attachment the 6TiSCH YANG modules with a more consistent
indentation
Hi Anand,
Regarding to power management, there is a parameter in the IEEE802.15.4 PIB,
i.e. phyTXPower. You can control the transmitting power by changing its value.
Is that what you want? If so, I think 6tisch MIB will provide the interface to
access phyTXPower, which will be defined in the 6ti
Hi Micheal and Jonathan,
You bring up a good question, i.e. how to use EBs. I have the related
questions.(1) Is it possible for a 6TiSCH network to change its timeslot
format, or channel hopping sequence, or Frame & Link structure after ASN starts
counting?(2) Is it possible to have more than on
Xavi,
The format is very clear.
I think there is typo on line 54. That should be channel hopping sequence?
ThanksQin
On Tuesday, May 12, 2015 9:44 PM, Pascal Thubert (pthubert)
wrote:
#yiv9648369827 #yiv9648369827 -- _filtered #yiv9648369827
{font-family:Calibri;panose-1:2 15 5 2
eed that
analysis for anything 6TiSCH, not minimal specifically.
Cheers,
Pascal
> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: mardi 12 mai 2015 06:44
> To: Pascal Thubert (pthubert)
> Cc: Qin Wang (qinwang6...@yahoo.com); Michael Richardson
Hi Diego and Thomas,
Firstly, I want to go through the combination of {Tx, Rx, Shared} and {Hard,
Soft}. I think Tx or Rx can go with both Hard and Soft, but Shared can only go
with Hard. The reason is Shared cell could be used by more than a pair of
nodes, so monitoring function (i.e. self moni
+1
Qin
On Monday, May 11, 2015 12:25 PM, Xavier Vilajosana
wrote:
Dear all,
after the last call we would like to close the security section in minimal. We
wrapped up all comments from the previous days and from the meeting and here is
our proposal:
This draft assumes the existence
Hi Carsten,
My understanding about the model is: a URI is associated with a set of access
permission. Correct?
If we want that different Client has different access permission to a resource,
e.g. node A is allowed to GET/PUT /6t/cellList in node C, but node B is only
allowed to GET /6t/cellList
S can establish a authorization access to resources even with ACE.
ThanksQin
On Friday, May 8, 2015 12:24 AM, Thomas Watteyne
wrote:
Isn't that exactly authorization, for which (Half of) the A in ACE stands for?
On Thursday, May 7, 2015, Qin Wang wrote:
To address Kris
To address Kris's question, I agree with Tero that there are two security
elements involved, one is something like DTLS to secure the network access;
another is ACL to guarantee right access to the database in devices.
ThanksQin
On Thursday, May 7, 2015 9:46 PM, Thomas Watteyne
wrote:
+1.
Qin
On Wednesday, May 6, 2015 9:40 PM, Tom Phinney wrote:
Let's put this to bed (i.e., reach a conclusion for this aspect).
Saying less is very much in the spirit of "minimal".
+1
===
On 2015.05.05 14:46, Kris Pister wrote:
> This is my proposed text for all of section 8. This d
Pascal,
The protection against transmission errors on EBs rely on the CRC in PSDU,
right?
ThanksQin
On Wednesday, May 6, 2015 6:34 PM, Pascal Thubert (pthubert)
wrote:
Hum...
But then, if the JN does not know K1, how can it validate the MIC? Do we have
another way to protect aga
Hi Pascal,
After the discussion in the thread "Removing the "e" in the charter", do you
still ask agreement about solution on the second point?
Personally, I prefer the text suggested by Pat, because it can decouple 6TiSCH
from IEEE802.15.4 MAC. But, if the minimal draft is not final standard, I
Hi all,
I understand that reference IEEE 802.15.4 includes IEEE802.15.4e by definition.
But I have a problem in writing 6TiSCH draft if we remove "e" in reference.
Here is an example. "A 10ms time slot length is the default value defined by
[IEEE802154e]. Section 6.4.3.3.3 of [IEEE802154e] de
Hi Ismail,
The reason is there could be more than one frame IE/Link IE. The length of
Frame IE/Link IE equal to number of frame/link times the length of one
frame/link data.
Make sense?
QIn
On Saturday, April 25, 2015 8:06 PM, ismail hakkı turan
wrote:
Hello,I am currrently tryin
Hi Thomas and Xavi,
I agree that with the a well-known key based MIC, some useless "start to join"
can be avoided. However, it is under the assumption that there is no other
6tisch networks, right? If there are more than one 6tisch networks in the same
area, and all of them use the well-known k
90 matches
Mail list logo
