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

Hi, I'm not aware of any IPR that applies to this draft regards, Xavi 2017-09-26 10:16 GMT+02:00 Pascal Thubert (pthubert) : > Authors, Contributors, WG, > > > > As part of the preparation for WG Adoption Call: > > > > Are you aware of any IPR that applies to drafts

Re: [6tisch] draft-richardson-6tisch-roll-join-priority-00 --- RPL DIO message

Hi Michael, In the EB, there is an Information Element described in 15.4 (Synchronization IE) that contains a field named Join Metric (in version 2012 was named Join Priority). I think would be good to change the name of the field to avoid any misunderstanding, considering that this also goes

Re: [6tisch] Plugtest Registration Site...?

Hi Yatch, I think this will be announced soon, maybe this Friday. regards, Xavi 2017-05-31 14:36 GMT+02:00 Yasuyuki Tanaka : > Hi all, > > Is there any web page such as a registration site which provides details > on the plugtest in July...? > > Best, > Yatch >

Re: [6tisch] Protocol Action: 'Minimal 6TiSCH Configuration' to Best Current Practice (draft-ietf-6tisch-minimal-21.txt)

great news! all this started back on 2013 :) X 2017-03-22 14:40 GMT+01:00 Pascal Thubert (pthubert) : > > Congrats to the authors!!! > > A long journey :) > > Pascal > > > Le 22 mars 2017 à 14:38, The IESG a écrit : > > > > The IESG has approved the

Re: [6tisch] Last Call: (Minimal 6TiSCH Configuration) to Best Current Practice

Dear Ralph, thanks so much for your comments. We will go through them and also will consider Jonathan, Brian and Tero's comments sent some days back and provide and updated version of the document asap. kind regards, Xavi 2016-12-23 19:53 GMT+01:00 Ralph Droms : > My

Re: [6tisch] Link Options bitmap in 6P Cell format

Hi Qin, the LinkOptions makes it more flexible for future uses (as it opens more options). I see 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

Re: [6tisch] [6TiSCH] return code in 6p response defined in sixtop draft

Hi Tengfei, see inline 2016-09-23 12:22 GMT+02:00 Tengfei Chang : > Dear all, > > > I have some question about the return code (mainly about the ERROR code) > in 6p response packet define in the draft: > https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02 > >

[6tisch] follow up LIST cmd 6P

Hi, according to our discussion during the last 6TiSCH meeting I want to follow up Tero's proposal for the LIST cmd. here you will find his initial proposal https://www.ietf.org/mail-archive/web/6tisch/current/msg04719.html As a summary, the proposal enables 6P list to return a best effort set

Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-protocol-02.txt

Hi Jiliang, inline again :) 2016-08-02 13:58 GMT+02:00 Jiliang Wang <jiliangwan...@gmail.com>: > Thanks. please see inline my comments. > > On Tue, Aug 2, 2016 at 7:29 PM, Xavier Vilajosana < > xvilajos...@eecs.berkeley.edu> wrote: > >> Hi Jiliang, >> &g

[6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-protocol-02.txt

Title : 6top Protocol (6P) Authors : Qin Wang Xavier Vilajosana Filename: draft-ietf-6tisch-6top-protocol-02.txt Pages : 28 Date: 2016-07-25 Abstract: This document defines the 6top Protocol (6P),

Re: [6tisch] Slot type in 6P cell list

Hi Thomas, Sedat,all I think he refers to link Option, that is whether the slots being allocated are tx, rx, both, shared? etc... The current draft is not explicit with that. The content is implicit in the direction of the negotiation. In a 6top negotiation (despite 2 o 3 step process) the

Re: [6tisch] proposed text to describe SF and 6P in archie

Hi Pascal, Thomas, all inline too (see changes in *foo*) regards, X 2016-06-03 20:41 GMT+02:00 Thomas Watteyne : > Pascal, > > Some typos and suggestions below. > > 4.2.2. Scheduling Functions and the 6P Protocol (6P) > >In the case of soft cells, the cell

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

Response with return >> code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement >> a retry as decided by the Scheduling Function >> >> >> >> >>>>>>> >> >> >> >> Does it make sense .. >>

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

t; >> With the keyword RC_BUSY, one expects that the node is indulge in a 6P >> transaction 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,* >>

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

function may decide for a retry when a RC_BUSY is received > , so how we can differentiate the usage of CT_ERROR and RC_BUSY. > > > > Is it the backoff time that accounts. > > > > *Thanks & Regards,* > > *Lijo Thomas * > > > > > > *From:* 6

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

Hi Diego, What I propose is to lock in the schedule the cells that are being sent in the candidate list, this means that 1) if there are other cells available in the schedule, the node may still be able to propose another (non-overlapping) candidate list. thus still supporting concurrency and 2)

[6tisch] recap of minimal review process

it attached as well) https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/src and includes all changes detailed below. kind regards, Xavi From: Xavier Vilajosana <xvilajos...@eecs.berkeley.edu> Date: 2016-05-03 9:54 GMT+02:00 Subject: Re: Review for draft-ietf-6tisch-minimal-15 To: "Pas

Re: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00

Dear Chonggang, thanks for your comment. The 6P protocol offers a metadata field whose content is defined by the scheduling policy. The metadata can specify whether the cells to be added/remove/counted/ etc.. belong to a particular slotframe, a particular bundle, a particular chunk, etc.. In this

Re: [6tisch] Quick review on draft 15

Dear Pascal, Thomas, I will address the little indications given by Pascal and then publish v15. Is that fine? thanks so much! X 2016-02-26 15:07 GMT+01:00 Thomas Watteyne : > Authors, > I went through the changes between v14 and v15 on the bitbucket repo and > agree

[6tisch] 6LoRH: compression of the inner destination

Dear Pascal, There is something it is not clear to me. How do we compress the inner header destination address assuming we have 6LoRH RH3. could you please clarify that? regards, X ___ 6tisch mailing list 6tisch@ietf.org

Re: [6tisch] for the Plugtest: New Version Notification for draft-ietf-6lo-routing-dispatch-04.txt

Same here. Let's keep current approach for the PT. regards, Xavi 2016-01-24 17:56 GMT+01:00 S.V.R.Anand : > Hi Pascal, > > Thanks a lot for keeping the discussion topics open. I am absolutely fine > with your > suggestion of having the draft as it is for the plugtest. >

[6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-14.txt

Group of the IETF. Title : Minimal 6TiSCH Configuration Authors : Xavier Vilajosana Kris Pister Filename: draft-ietf-6tisch-minimal-14.txt Pages : 28 Date: 2016-01-16 Ab

Re: [6tisch] FW: Consensus call on Summary of proposed resolution for issue 40 V3

Dear Pascal, Pat, I updated the current version of minimal in bitbucket. I addressed issue #42 and Pat comments (thanks!). let me know when to publish v14. regards, Xavi 2016-01-08 19:19 GMT+01:00 pat.kin...@kinneyconsultingllc.com < pat.kin...@kinneyconsultingllc.com>: > There are 2 typos in

Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

posal. > Would you suggest to change the above abstract or is it OK as is? > > Pascal > > *From:* pat.kin...@kinneyconsultingllc.com [ > mailto:pat.kin...@kinneyconsultingllc.com > <pat.kin...@kinneyconsultingllc.com>] > *Sent:* vendredi 18 décembre 2015 15:41 > *To:* Pascal Thubert (

Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Dear all, I wrapped up the proposed changes and integrated them to the version in bitbucket. https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a For simplicity, see here a summary of the changes. Abstract: [OLD] This document describes the

Re: [6tisch] #41 (minimal): intended status for draft minimal (was: internded status for draft minimal)

ivi...@iki.fi>: > Xavier Vilajosana writes: > > 4) minimal defines when EBs are sent and what information from the wide > set of > > options (IEs) provided by 15.4 TSCH is sent in an EB. > > I.e. provides profile for 15.4 to be used in 6tisch. > > > 5) it defines the s

Re: [6tisch] #41 (minimal): intended status for draft minimal

I support Kris point. RFC 2464 for example indicates how to construct the link local address from the MAC layer field The IPv6 link-local address [AARCH ] for an Ethernet interface is formed by appending the Interface Identifier, as defined

[6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-13.txt

orking Group of the IETF. Title : Minimal 6TiSCH Configuration Authors : Xavier Vilajosana Kris Pister Filename: draft-ietf-6tisch-minimal-13.txt Pages : 28 Date: 2015-11-27 Ab

Re: [6tisch] New Version Notification for draft-wang-6tisch-6top-sublayer-03.txt

get moved to a > different draft? > > In my attached revision, please check for instances of "CEP" for a few > other questions. > > > On 10/19/2015 8:19 PM, Xavier Vilajosana wrote: > > Dear all, > > we have submitted a new version of the sublayer dr

[6tisch] New Version Notification for draft-wang-6tisch-6top-sublayer-03.txt

Dear all, we have submitted a new version of the sublayer draft. kind regards, Xavi - A new version of I-D, draft-wang-6tisch-6top-sublayer-03.txt has been successfully submitted by Thomas Watteyne and posted to the IETF repository. Name: draft-wang-6tisch-6top-sublayer

Re: [6tisch] comments on 15.4 header fields in minimal

want to stay in most of the default values. Therefore, macImplicitBroadcast set to FALSE, and dst address (short) and dst PANID to be explicit (0x). As a second point: Would the use of macImplicitBroadcast change in the new version? thanks! Xavi 2015-09-10 13:38 GMT+02:00 Tero Kivinen <kiv

Re: [6tisch] comments on 15.4 header fields in minimal

ing it this way, especially using PAN ID compression set to 1. > > Robert > > On 27 July 2015 at 05:52, Xavier Vilajosana <xvilajos...@eecs.berkeley.edu > > wrote: > >> Hi, >> >> we discussed this concern at the IETF meeting. In minimal we wanted to >

Re: [6tisch] comments on 15.4 frame format in minimal

XV>>Hola Jose, XV>>see my answers inline please After having taken a look at draft-ietf-6tisch-minimal-11, we would like to share some points/conclusions with you. There are some aspects which were decided just before the Plugtest event in order to guarantee the interop. between the different

Re: [6tisch] comments on 15.4 header fields in minimal

pat.kin...@kinneyconsultingllc.com 15-15-0561-03-0mag-yet-another-document-explaining-pan-id-compression (1).docx On 21, Jul2015, at 12:46, Xavier Vilajosana xvilajos...@eecs.berkeley.edu wrote: Hi, From the discussion today, the section mandating the use of certain 2012 specific

Re: [6tisch] comments on 15.4 header fields in minimal

frames? regards, Xavi 2015-07-22 14:55 GMT+02:00 Tero Kivinen kivi...@iki.fi: Xavier Vilajosana writes: thanks, you are right. The proposed text is already indicating that. In case of a destination broadcast address, the address field MUST be filled by a short address (16bit). Yes

Re: [6tisch] comments on 15.4 header fields in minimal

, Xavier Vilajosana xvilajos...@eecs.berkeley.edu wrote: Hi, From the discussion today, the section mandating the use of certain 2012 specific configuration needs to be changed so we can be independent to the evolution of the 15.4 spec. The current text is: The IEEE802.15.4 header of all

Re: [6tisch] comments on 15.4 header fields in minimal

Hi Tero, thanks, you are right. The proposed text is already indicating that. In case of a destination broadcast address, the address field MUST be filled by a short address (16bit). regards, Xavi 2015-07-22 13:31 GMT+02:00 Tero Kivinen kivi...@iki.fi: Xavier Vilajosana writes: From

[6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-11.txt

Authors : Xavier Vilajosana Kris Pister Filename: draft-ietf-6tisch-minimal-11.txt Pages : 26 Date: 2015-07-06 Abstract: This document describes the minimal set of rules to operate an IEEE 802.15.4

Re: [6tisch] Minimal: error in IE header examples

Sorry option 2 was incorrect.. too fast copypaste 2) Another option is to convert to hex by considering the MSb first within the octet MSb LSb 1100 0x0 0x0 0xF 0xC 0x00 0xFC regards, X 2015-06-24 17:53 GMT+02:00 Xavier Vilajosana

Re: [6tisch] Minimal: error in IE header examples

, The first 7 bits goes is len field bit0-bit6: 000, then goes ID: b7-b14 7E 0110, then type bit 15 0. Which is Correct. Tengfei On Tue, Jun 23, 2015 at 12:14 AM, Xavier Vilajosana xvilajos...@eecs.berkeley.edu wrote: Dear Simon, thanks for your comments. I might have messed bits up

[6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-09.txt

Authors : Xavier Vilajosana Kris Pister Filename: draft-ietf-6tisch-minimal-09.txt Pages : 25 Date: 2015-06-15 Abstract: This document describes the minimal set of rules to operate an IEEE

[6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-08.txt

: 6tisch@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e Working Group of the IETF. Title : Minimal 6TiSCH Configuration Authors : Xavier

[6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-07.txt

: Xavier Vilajosana Kris Pister Filename: draft-ietf-6tisch-minimal-07.txt Pages : 24 Date: 2015-06-12 Abstract: This document describes the minimal set of rules to operate an IEEE 802.15.4 Timeslotted Channel Hopping

Re: [6tisch] Example for minimal with security enabled

Dear Malisa, thanks. I will wait for consensus on this example and if approved I will add it to the examples section in minimal. Others, if there is any objection please say it during the week so we can move forward on our plans to publish v7 of the draft by the end of the week. regards, Xavi

Re: [6tisch] DODAG root rank in minimal draft

Dear Nicola, thanks for your comment! I reviewed both rfc6550 and rfc6552 and you are right. I corrected the draft as follows: +---+ | 0 | R(0) = 0 | | DAGRank(R(0)) = 0 +---+ | | +---+ | 1 | R(1)=R(0)+683=683 | |

Re: [6tisch] ANIMA vs. Join process

Hi, I support Tom's comment. I think our work during these years influenced RestCONF to produce COMI. I think that as long as we have the skills we should keep exploring the security aspects of 6tisch and influence (if needed) other groups when things can be aligned. regards, Xavi 2015-05-22

Re: [6tisch] Minimal draft IEs examples

Dear Tero, thanks for looking in detail into them. I was actually correcting some of these mistakes. As you said Hopping timing IE (0x1d) is incorrect as Ch.Hopping IE (0x9) is a long format . I will soon push a new version with the examples integrated in the draft. regards, Xavi 2015-05-18

Re: [6tisch] Minimal draft IEs examples

(pthubert) pthub...@cisco.com wrote: I like your format Xavi, it is perfectly readable. Cheers, Pascal *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Xavier Vilajosana *Sent:* mardi 12 mai 2015 10:57 *To:* 6tisch@ietf.org *Subject:* [6tisch] Minimal draft IEs examples

[6tisch] Minimal draft IEs examples

Hi, we agreed on replacing the IEs description by several illustrative examples. I worked a little bit on them and I would like to see what is your opinion. As said they will be referred in the text and will be placed at the end in an Examples section. By now there are 3 examples and I need to

Re: [6tisch] Some comments to minimal

Hi Pat, let me make some comments inline. PKI see no reason why the minimal doc should include any IE formatting, instead the minimal doc should reference the 802.15.4 standard. We wanted to make a document which is self-contained as now to implement 15.4e TSCH you need 15.4 and the 15.4e TSCH

Re: [6tisch] last changes on Archie

Hi, I support this resolution. I am interested on Kris comments. X 2015-04-30 2:21 GMT+02:00 Pascal Thubert (pthubert) pthub...@cisco.com: Dear all : At the interim call we found that Archie is mostly ready to ship but for 2 things; 1) we need to decide on the IEEE reference 2) some

Re: [6tisch] a little puzzle

? Thomas On Thu, Apr 23, 2015 at 9:36 AM, Xavier Vilajosana xvilajos...@eecs.berkeley.edu wrote: Hi Thomas, sorry, but I still do not see the benefit :) .. In both case 1 and case 2 Zelda's network will be sending a lot of EBs and Charlie's nodes will be receiving that EBs. In both cases

Re: [6tisch] a little puzzle

Kris, can you explain me Charlie does some testing of option 1, and finds that when there is a Zelda's Toy Shop near one of his stores, his networks take a *really* long time to join. It seems that Zelda's toys send 15.4e EBs too, and they send a lot of them. The sensors that Alice and Bob

[6tisch] security text on minimal

Hi Rene, Michael and Jonathan, I am working on the text for the security section in the minimal draft. I included Rene's suggestion but I still have doubts as during the IETF meeting there was some discussion about it. the security section is composed of 2 paragraphs. As this document refers to