Re: [6tisch] security section in minimal

It is OK for me. +1 Diego 2015-05-11 4:19 GMT-03:00 Maria Rita PALATTELLA maria-rita.palatte...@uni.lu: Hi Xavi, (all) the suggested text covers all the discussed we have been having so far. and it is in line with the scope of minimal. THUS, +1 from my side. Thanks! Maria

[6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts

Dear all, Regarding the discussion on the 6top-sublayer and the 6top-sf0 drafts, I would like to point out two items: - First, If there is a preference for the parent's schedule over the child, I think the transaction should be started always from the parent side, but requested (maybe)

[6tisch] Fwd: New Version Notification for draft-dujovne-6tisch-6top-sf0-00.txt

-- Forwarded message -- From: Date: 2015-10-19 18:08 GMT-03:00 Subject: New Version Notification for draft-dujovne-6tisch-6top-sf0-00.txt A new version of I-D, draft-dujovne-6tisch-6top-sf0-00.txt has been successfully submitted by Diego Dujovne and

Re: [6tisch] new term: 6top "Scheduling Function"

Dear all, I agree on the term "Scheduling Function" Regards, Diego Dujovne 2015-10-12 13:24 GMT-03:00 Xavier Vilajosana : > Hello, > > I support the term Scheduling Function (SF) and once we reach consensus I > will update the

Re: [6tisch] Minutes, 27 November 2015 interim, 6TiSCH WG

Pascal, I would correct the time [16:57] for [7:57]. Regards, Diego 2015-11-27 13:43 GMT-03:00 Pascal Thubert (pthubert) : > Note: timestamps in PST. > Connection details > >- Date: 7-8AM Pacific >- Webex link: > >

Re: [6tisch] Agenda for January 8th, 2016 interim call, 6TiSCH WG

Thomas, Yeap, just re-checking them now. Regards, Diego 2016-01-08 11:00 GMT-03:00 Thomas Watteyne : > reminder, 6TiSCH interim meeting in 1 hour > > On Tue, Jan 5, 2016 at 5:48 PM, Pascal Thubert (pthubert) < > pthub...@cisco.com>

Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

(2) Candidate Cells in Lock Status. Because SF analyze the ADD > Request Message and prepare Response Message, it should not difficult for > SF to provide the value of the 1-bit Flag. > > What do you think? > > Thanks > Qin > > > On Tuesday, May 24, 2016 11:29 AM, Prof. Diego

Re: [6tisch] 6P and Sf0 issue: IANA IDs

ss this at the > interim next Friday to prepare for any request / question to the 6TiSHC SG > or WG15 who are meeting in Macao the week after. > > > > CC’ing Brian in case I missed something? > > > > Cheers, > > > > Pascal > > > > *From:* 6tisch [

Re: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot

in and > are there to boost the bandwidth for that critical phase. > > > > Cheers, > > > > Pascal > > > > *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Prof. > Diego Dujovne > *Sent:* jeudi 3 mars 2016 17:12 > *To:* 6tisch@ietf.

Re: [6tisch] 6P and Sf0 issue: Examples of error handling

are required, I think it makes sense that retrying within a > transaction. > > What do you think? > > Tengfei > > On Thu, Mar 3, 2016 at 9:41 PM, Prof. Diego Dujovne < > diego.dujo...@mail.udp.cl> wrote: > >> Dear all, >>One of the secti

Re: [6tisch] 6P and Sf0 issue: Statistics for SFs and Relocation

rt) <pthub...@cisco.com>: > I’d support that, Diego > > > > If the visible operation of the device depends on it and that influences > the interoperation, it is good to document a base way of doing things. > > > > Cheers, > > > > Pascal > > > > *From:

Re: [6tisch] SF0 - Cell reclamation by RPL parent

Anand, Let me comment inline below. Regards, Diego 2016-03-07 7:36 GMT-03:00 S.V.R.Anand : > Hi Diego and others, > > Since we are discussing about the message transactions in SF0, this mail > is with > respect to the RPL parent,

Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

Pascal > > > > *From:* Qin Wang [mailto:qinwang6...@yahoo.com] > *Sent:* mercredi 9 mars 2016 16:48 > *To:* Pascal Thubert (pthubert) <pthub...@cisco.com> > *Cc:* Tero Kivinen <kivi...@iki.fi>; 6tisch@ietf.org; Prof. Diego Dujovne > <diego.dujo...@mail.udp

[6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

Dear all, In order to continue the discussion we left unfinished at the Interim meeting in March 26th, I will open a number of threads to take action on several pending issues for the drafts: draft-wang-6tisch-6top-sublayer-04 (which will be renamed to 6top-protocol)

[6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

Dear all, Given that there is parent preference in cell selection, a child-initiated transaction triggers a three-step exchange: 1- Child sends request to Parent with whitelist/blacklist of slotoffsets 2- Parent selects cells 3- Child acknowledges and finishes the transaction The main

Re: [6tisch] Remote Mentoring: Internet Draft Review Team: 6tisch: Portugese / English

Nalini, I can help with this draft, you can send them my email address to start the discussion. I'm not in Brazil (I'm in Chile), but we may be able to arrange a videoconf if necessary, given that we do not have a huge time difference. Regards,

Re: [6tisch] My adoption-time review of SFO

thout getting complex? > > > > Pascal > > > > *From:* S.V.R.Anand [mailto:an...@ece.iisc.ernet.in] > *Sent:* jeudi 19 mai 2016 08:17 > *To:* Pascal Thubert (pthubert) <pthub...@cisco.com>; Prof. Diego Dujovne > <diego.dujo...@mail.udp.cl> > *Cc:* 6tisch@iet

Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

t;> In case a node does not have enough resources to handle concurrent 6P >>> Transactions from different neighbors or if the cells requested are >>> locked, it MUST reply to that second request with a 6P Response with return >>> code IANA_6TOP_RC_BUSY. The node receivin

[6tisch] New error type for concurrent transactions on 6top protocol draft

Dear all, I proposed today to add a new type of error for CellList proposal during the transaction. The idea follows the solution proposed today at the Webex call by Xavi to define a lock when two concurrent cell requests arrive to the node. For example, if node B requests a cell from

Re: [6tisch] My adoption-time review of SFO

Dear all, During today's webex call, I presented a slide where the comments below were going to be addressed on the next version of the draft. However, I raised the point about: Ø 4. Rules for CellList Why is this here? Which cell are allocated is not SF0 ‘s business,

Re: [6tisch] My adoption-time review of SFO

fact that one of these units is mapped to a particular slot offset > / channel offset should not be its business. I see it as a layer violation… > > What if for instance the SF is in the root? Should it really manage down > to the cell? > > > > Pascal > > > > *From:* P

Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

saction currently and can go for a retry. But in the draft it says > RC_BUSY with no resources available. It is bit confusing. > > > > > > *Thanks & Regards,* > > *Lijo Thomas * > > > > > > *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Xavier > V

[6tisch] Fwd: New Version Notification for draft-ietf-6tisch-6top-sf0-01.txt

Dear all, I have submitted a new version of the SF0 draft to fulfill the pending changes after the discussions on the ML and interim calls. Regards, Diego A new version of I-D, draft-ietf-6tisch-6top-sf0-01.txt has been successfully submitted by Diego

[6tisch] SF Timeout calculation (Ticket #53)

Dear all, Yesterday, we had a discussion about ticket #53 from the issue tracker, on the way to calculate the SF0 timeout value. There is current a proposal to calculate the timeout on SF0 between the arrival of the MAC-layer ACK for the request packet and the arrival of the

Re: [6tisch] Call for adoption of draft-richardson-6tisch-dtsecurity-secure-join as WG document

+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 in 6TiSCH. > > regards, > X > > 2016-11-23 8:55 GMT+01:00 Pascal Thubert (pthubert) : > >> Dear all : >> >>

Re: [6tisch] [6P+SF0] CALL FOR CONSENSUS: sending a CLEAR request to old parents

I agree witb Yatch: On Step 1, keep the original CLEAR command at boot time. Step 2 is OK for me: In fact, the only way SF0 would detect that the node is no longer available or that RPL has decided a parent change is that there will be no more effectively used cells towards that neighbour, so

Re: [6tisch] Shared / Dedicated cell policy on SF0

lls they are > scheduling are truly dedicated. In general, cells scheduled with 6P > are possibly shared with multiple TX devices. In other words, I think > it'd be better to always perform CCA on a cell scheduled with 6P. > > Best, > Yatch > > > On 2016/10/31 22:23,

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Yasuyuki, Thomas, I suggest to keep the CLEAR command after reboot/failure. Regards, Diego 2016-11-16 11:05 GMT-03:00 Thomas Watteyne : > @Tengfei, > Does that suggestion work for you or should we

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

.fr>: > Diego, > Fine for me. Could you bring it up during the WG meeting tomorrow? > Thomas > > On Thu, 17 Nov 2016 at 00:02 Prof. Diego Dujovne < > diego.dujo...@mail.udp.cl> wrote: > >> Yasuyuki, Thomas, >> I suggest to k

Re: [6tisch] SF0 Cell Estimation Algorithm (draft-ietf-6tisch-6top-sf0-02)

2016-11-11 17:14 GMT-03:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>: > Yasuyuki, > -02 version does not take into account symmetry. > In fact, we do not specify which type of cells (RX,TX) we > are allocating, we only say that we need to allocate them as

[6tisch] Shared / Dedicated cell policy on SF0

Dear all, SF0 has assumed until now that it was only working on dedicated cells, but 6P now provides the possibility to use shared cells. I would like to hear your thoughts on the following alternatives: a) if we allow shared cells to be used SF0, how to establish a

Re: [6tisch] SF Timeout calculation (Ticket #53)

> formula should look like the following: > > timeout = 2^macMaxBE * TXATTEMPT * Slotframe_length_in_seconds [seconds] > > Do you see why I'm saying that the timeout that does not produce > inconsistencies is very long? > > What do you feel is incorrect in my approach? > &

Re: [6tisch] SF Timeout calculation (Ticket #53)

know it's counter-intuitive: if you give more priority to 6P packets you > will in fact allow data to stay very comfortable in the dedicated cells > allocated. > > Nicola > > > 2016-10-31 20:48 GMT+01:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl> > : > >&g

Re: [6tisch] SF Timeout calculation (Ticket #53)

sible >> impairment with the node A schedule knowledge. >> >> Instead, if the 6P response was out of time, A will not send any 6P ack, >> will not open the TX side. B will not receive any 6P ack within a timeout >> (that can be the same length as that starting on the A si

Re: [6tisch] SF Timeout calculation (Ticket #53)

Nicola, I would try to focus on the draft, however, let me answer briefly the shared/dedicated point of view below. Regards, Diego 2016-10-31 15:18 GMT-03:00 Nicola Accettura : > Hi Diego, > > thank you for your answer too. >

Re: [6tisch] [6TISCH] RELOCATE command in sixtop?

Pascal, The relocation process from SF0 is meant also to detect collisions after random allocation, among other sources of packet loss, such as narrowband interference or noise. Regards, Diego 2016-11-02 12:06 GMT-03:00 Pascal Thubert (pthubert)

Re: [6tisch] [6TISCH] Specify the number of cells to be added or deleted in SF0

Nicola, I agree with your comment, but the cell estimation algorithm changed: we now estimate the number of required cells from the number of requested cells (to add or delete) and the number of effectively used cells. What is still not clear to me is if the simulation results from the

Re: [6tisch] [6TISCH] Specify the number of cells to be added or deleted in SF0

>> As Sixtop left lots of details in SF, my thought is SF should give more >> specific information or clues for developer/implementer to implement. >> Of course, those information will come out from real experiments. >> >> Thanks for all you replying! >> >>

Re: [6tisch] 6P "design team" session this Friday, same time as interim meeting

Dear all, From the part of the meeting I could attend, I could not detect an agreement on the timeout calculation, as 6P requires. Can we discuss this on the ML? Regards, Diego 2016-12-16 17:05 GMT-03:00 Simon Duquennoy : > Hi

Re: [6tisch] nits on draft-ietf-6tisch-6top-sf0-02

Thomas, During the last Webex I commented that I used these comments to modify and correct the draft. I eliminated (almost) every instance of "effectively used cell" and fixed the problems raised by Randy. Regards, Diego 2017-03-28 9:31 GMT-03:00 Thomas

[6tisch] SF0 Performance paper

Dear all, As I mentioned during today's interim, there is a new publication (2017) from authors currently not related to SF0 that shows SF0 performance in an experimental platform compared to their own proposal. http://www.sciencedirect.com/science/article/pii/S092054891730106X

[6tisch] Fwd: New Version Notification for draft-ietf-6tisch-6top-sf0-03.txt

For your information, there is a new version of SF0 available. Regards, Diego Dujovne A new version of I-D, draft-ietf-6tisch-6top-sf0-03.txt has been successfully submitted by Diego Dujovne and posted to the IETF repository. Name: draft-ietf-6tisch-6top-sf0

[6tisch] Fwd: New Version Notification for draft-ietf-6tisch-6top-sf0-04.txt

Dear all, I have changed the status of SF0 to Experimental and posted revision -04. Regards, Diego A new version of I-D, draft-ietf-6tisch-6top-sf0-04.txt has been successfully submitted by Diego Dujovne and posted to the IETF repository. Name:

Re: [6tisch] comments SF0

Xavi, I answer to your comments inline. I am really grateful for your comments, since most the new version had not had a detailed revision since the migration from OTF to SF0. Regards, Diego 2017-04-30 8:37 GMT-03:00 Xavi Vilajosana Guillen

[6tisch] Timeout implementation on 6P/SF0

Dear all, During today's Webex call we discussed transaction timeout implementation problems. As a result, the proposed solution is that SF will include a TTL field with the timeout value that the SF will wait to finish the transaction. This will avoid inconsistencies if

Re: [6tisch] Fw: Qin comments on SF0

Thomas, Yes, I got this e-mail (June 9th). Regards, Diego 2017-06-21 8:13 GMT-04:00 Thomas Watteyne : > Diego, > Can you confirm you got this e-mail? One thing that has worked well in the > past is to track issue raised in either

Re: [6tisch] Timeout implementation on 6P/SF0

he time duration for > nodeB to sent back Response message. > > What do you think? > > Thanks > Qin > > > On Friday, May 19, 2017 12:18 PM, Prof. Diego Dujovne < > diego.dujo...@mail.udp.cl> wrote: > > > Xavi, Lijo: > The idea I have

Re: [6tisch] Timeout implementation on 6P/SF0

;> As SF0 address a scheduling scheme, it would be better if the algorithm >> suggest the values. >> >> >> >> Or maybe you could detail it with an example or a flow diagram. >> >> >> >> >> >> *Thanks & Regards,* >> >> *Li

Re: [6tisch] Sheperd's WGLC review for draft-ietf-6tisch-6top-protocol-08

All, Let me chime in. See my coments inline. Thanks, Diego 2017-09-29 9:12 GMT-03:00 Thomas Watteyne : > Thanks Pascal for the feedback. @Xavi, would you have a second to turn > those suggestions into issue on the bitbucket repo? > > On

Re: [6tisch] Regarding IPR on draft-ietf-6tisch-6top-protocol

No, I'm not aware of any IPR that applies to this draft Le mardi 26 septembre 2017, Pascal Thubert (pthubert) a écrit : > Authors, Contributors, WG, > > > > As part of the preparation for WG Adoption Call: > > > > Are you aware of any IPR that applies to drafts identified

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

t; >> >> Pascal >> >> >> >> *From:* Tengfei Chang [mailto:tengfei.ch...@inria.fr] >> *Sent:* mardi 31 octobre 2017 13:17 >> *To:* Prof. Diego Dujovne <diego.dujo...@mail.udp.cl> >> *Cc:* Pascal Thubert (pthubert) <pthub...@cisco.com>

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

My proposal would be to merge both SFX and MSF since they look complementary - from my point of view -. Any comments? Regards, Diego 2017-10-31 10:43 GMT-03:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>: > Dear all, > From a f

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

.fr>: > That's exactly what we need to discuss in Singapore. > > On Tue, Oct 31, 2017 at 2:50 PM, Prof. Diego Dujovne < > diego.dujo...@mail.udp.cl> wrote: > >> My proposal would be to merge both SFX and MSF since >> they look complementary - from my point

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

think that's a good idea. The SF shuld be a standalone document. > Cutting it into piece will IMO add delays. Plus, I want the SF(s) to really > be the end of the story, i.e. not leave other things open that are > undefined in the SF. > Thomas > > On Tue, Oct 31, 2017 a

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

Dear all, I cannot find the text for: draft-chang-6tisch-6top-msf Can you provide a link? Thank you. Regards, Diego 2017-10-31 6:35 GMT-03:00 Pascal Thubert (pthubert) : > Dear all : > > > > *Note: Due to EU going CET this WE, this

Re: [6tisch] Fwd: Protocol Action: '6TiSCH Operation Sublayer Protocol (6P)' to Proposed Standard (draft-ietf-6tisch-6top-protocol-12.txt)

Congratulations! El vie., 17 de ago. de 2018 11:03, Pascal Thubert (pthubert) escribió: > Congratulations to the authors for the hard and excellent work on this > draft! > > Pascal > > Début du message transféré : > > *Expéditeur:* The IESG > *Date:* 16 août 2018 à 15:37:58 UTC+2 >

Re: [6tisch] draft-ietf-6tisch-6top-sfx-01 comments

Lotte, Thank you for your comments. They are very helpful to improve and to complete the draft before WGLC. Do you have some preliminary results on the implementation (or an open source implementation) to contribute to the WG? Thank you. Regards, Diego Dujovne

[6tisch] Submission of new version of SFX

Dear all, I forward the submission confirmation for the -01 version of the SFX Scheduling function draft. Thank you. Regards, Diego Dujovne A new version of I-D, draft-ietf-6tisch-6top-sfx-01.txt has been successfully

Re: [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt

Michael, I agree on putting the rank to the maximum value to code that the network is not interested in accepting more members, thus, keeping their internal data private. Regards, Diego Le dim. 23 sept. 2018 à 17:38, Michael Richardson a écrit : > >

Re: [6tisch] review of draft-ietf-6tisch-enrollment-enhanced-beacon

Pascal, Michael: Thanks for the comments. Answers below. Regards, Diego Le lun. 25 mars 2019 à 05:47, Michael Richardson a écrit : > > Thank you for this review! > > Pascal Thubert (pthubert) wrote: > > Page2 Introduction: there?s an EDNOTE:

Re: [6tisch] SeqNum definition in RFC8480 (6P)

Yacht, Let me chime in a little bit. Responses below. Regards, Diego El mié., 24 de abr. de 2019 06:24, Yasuyuki Tanaka escribió: > Hi Xavi, > > > What is the issue you see with this? > > At least, there is an inconsistency in RFC8480. Here is another example: > >

Re: [6tisch] starting WGLC for draft-ietf-6tisch-enrollment-enhanced-beacon-02

I am unaware of any IPR related to this draft. El lun., 19 de agosto de 2019 11:59, Michael Richardson escribió: > Pascal Thubert (pthubert) wrote: > > Authors: please confirm whether any and all appropriate IPR > > disclosures required for full conformance with the provisions of BCP >

Re: [6tisch] [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 - Extended (fwd) Ines Robles: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-

+1 too. Regards, Diego Le mar. 27 août 2019 à 14:12, Pascal Thubert (pthubert) a écrit : > +1 > > > Regards, > > Pascal > > > Le 27 août 2019 à 20:09, Michael Richardson a écrit : > > > > > > This document is part of the enhanced beacon process. > > Comments appreciated to

Re: [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-06.txt

Dear all, A new version of the Enrollment Enhanced Beacon draft was published on Monday Nov. 4th, including all the changes proposed by Carles. Thank you. Regards, Diego Dujovne Le lun. 4 nov. 2019 à 19:15, a

Re: [6tisch] Iotdir early review of draft-ietf-6tisch-enrollment-enhanced-beacon-05

Dear all, I would like to thank Carles for his prompt and detailed review of the enrollment enhanced beacon draft. We have taken care of all the comments and made the corresponding changes. Version -06 was published on Monday, as you may have noticed on the datatracker.

Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

Yoav, Thank you for your feedback. I will add that line on the next version. Regards, Diego Dujovne Le jeu. 16 janv. 2020 à 15:03, Yoav Nir via Datatracker a écrit : > Reviewer: Yoav Nir > Review result: Has Nits > > The draft is short and to the point

Re: [6tisch] [6lo] FW: [802.15-ALL] Sad news about Dr. Robert F. Heile

Really sad, I had the chance to listen to his thoughtful comments and presentations at several of the WG meetings. Regards, Diego Le mar. 29 sept. 2020 à 04:55, Samita Chakrabarti a écrit : > This is a very sad news. Bob Heile used to attend 6lo wg meetings >

Re: [6tisch] Finally !!

Dear all, I can remember the first meeting in 2013, at the 6tisch BOF. Since then, I had the chance to meet and collaborate with great people, which became a really interesting and fruitful learning experience. After 8 years, I can see the results and all the work behind in

Re: [6tisch] time to close WG

Pascal, I agree for that case, you are right. Just keep it in sleep mode until then. :D Regards, Diego Le mer. 23 mars 2022 à 13:52, Pascal Thubert (pthubert) a écrit : > Hello Michael > > We kept it open in case new work comes up. This might happen once RAW