From nobody Wed Feb 1 05:29:26 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A904129DFF for <6tisch@ietfa.amsl.com>; Wed, 1 Feb 2017 05:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.719 X-Spam-Level: X-Spam-Status: No, score=-17.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iw7hcUe_YTh for <6tisch@ietfa.amsl.com>; Wed, 1 Feb 2017 05:29:25 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DCC124281 for <6tisch@ietf.org>; Wed, 1 Feb 2017 05:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11397; q=dns/txt; s=iport; t=1485955764; x=1487165364; h=from:to:subject:date:message-id:mime-version; bh=kEnhdC+otjEjgdAqRgInkT1PqQUCW7LjnJGjXlWug1Q=; b=RxF/pXv5JYA0TgfbDnwF+qDn6Zv4Q4qd8nZAu8HmCYOpjlVGFE1//Zzy WiPsXG2GC0y3oAWXoiRkpoUnOxnvVbJikR1JuAzyH/pHNf4kA+fBFxC29 uKNYbzEonW6JZNpXBiWVskg/PpXKPb6NHK2J0lTd14n0s3LZLdumd/Pxs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQDK4ZFY/4QNJK1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvZGGBCQeNWaIRhSuCDSyFdoIzPxgBAgEBAQEBAQFiHQuFHV4?= =?us-ascii?q?BHBwMPCYBBBsSiVgOLZwSkiaDVIddAQEBAQEBAQMBAQEBAQEBIYZLhiuBVIFdL?= =?us-ascii?q?oISgmsaBZVFhhcBhmaLE4IChRWJb5MAAR84gUsVhH4cgWF1AYcQgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,320,1477958400"; d="scan'208,217";a="206214472" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2017 13:29:24 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v11DTNuu003761 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Wed, 1 Feb 2017 13:29:23 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Feb 2017 07:29:22 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 1 Feb 2017 07:29:23 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Agenda, 03 February 2017 interim, 6TiSCH WG Thread-Index: AdJ8jsTf4QveUKMiTrGkHZvVighb/A== Date: Wed, 1 Feb 2017 13:28:56 +0000 Deferred-Delivery: Wed, 1 Feb 2017 13:28:12 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.14] Content-Type: multipart/alternative; boundary="_000_eae2ed402b7d463cbc79801eca8e83f3XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] Agenda, 03 February 2017 interim, 6TiSCH WG X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 13:29:26 -0000 --_000_eae2ed402b7d463cbc79801eca8e83f3XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Connection details * Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=3D1&lid=3D100,= 12,5392171,1850147&h=3D100&date=3D2017-02-03&sln=3D15-16 * Webex link: https://cisco.webex.com/ciscosales/j.php?MTID=3Dmcdbbe3a4= e38d97d986b507ec12a1f9b1 * Meeting number (access code): 203 224 694 * Meeting password: sixtus (749887 from phones) Agenda * Administrivia [2min] * Approval agenda * Approval minutes last call * Status of drafts [Chairs] [5min] * News from 802.15.12 [Pat] [25min] * Wrap up ML discussions on 6top [Thomas] [25min] * AOB [3min] As usual, if you wish to add/change stuff please let us know; The chairs. --_000_eae2ed402b7d463cbc79801eca8e83f3XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Connection details

Agenda

  • Administrivia [2min]
    • Approval agenda
    • Approval minutes last call
  • Status of drafts [Chairs] [5min]
  • News from 802.15.12 [Pat] [25min]
  • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l3 level1 lfo6"> Wrap up ML discussions on 6top [Thomas] [25min]
  • AOB [3min]

As usual, if you wish to add/change stuff please let us know;=

The chairs.

 

--_000_eae2ed402b7d463cbc79801eca8e83f3XCHRCD001ciscocom_-- From nobody Wed Feb 1 05:35:48 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F95129E01; Wed, 1 Feb 2017 05:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MclwyNod4Wwt; Wed, 1 Feb 2017 05:35:39 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B781295C1; Wed, 1 Feb 2017 05:35:38 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v11DZYaQ010563 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Feb 2017 15:35:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v11DZYDV023184; Wed, 1 Feb 2017 15:35:34 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22673.58406.267887.80681@fireball.acr.fi> Date: Wed, 1 Feb 2017 15:35:34 +0200 From: Tero Kivinen To: Ralph Droms In-Reply-To: <0117261E-F63B-45CD-80E7-E6FD99435F0E@gmail.com> References: <148103459764.1842.9947168180087183897.idtracker@ietfa.amsl.com> <43CFAE07-24CA-48D5-BEE9-4EC5379B2F60@gmail.com> <1500237294.66092.1485795438510.JavaMail.root@canet.uoc.es> <0117261E-F63B-45CD-80E7-E6FD99435F0E@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 20 min Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, 6tisch <6tisch@ietf.org>, IETF discussion list , Xavi Vilajosana Guillen Subject: Re: [6tisch] Last Call: (Minimal 6TiSCH Configuration) to Best Current Practice X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 13:35:41 -0000 Ralph Droms writes: > The EB_PERIOD determines the join time and impacts energy consumption. The > value is a trade-off of this two elements according to the network > administrator, as shorter the EB period more energy is used but sooner the > nodes join the network. This number does not affect different vendor nodes > aiming to join the same network (in terms of inter-operability). For us > this is more a network policy, IMHO defining a default value would not fit > most of the cases. > > Is it necessary for all devices in a network to use the same value EB_PERIOD? Not really. The device wanting to join the network needs to listen to each channel for certain time period to find enhanced beacons. The needed depends on the EB_PERIOD, slotframe size, timeslot length and number of channels. As it cannot know any of those parameters it needs to guess values for all of those, and use them, and if it does not hear any beacons during the timeout period calculated based those guessed values, it can assume that there is no network nearby, and go for extended sleep waiting for network to appear. If the typical values like timeslot length = 10ms, slotframe size = 101, number of channels = 16 and EB_PERIOD of 3 is used, then it knows that: - Slot frame takes 10ms * 101 = 1.01 seconds. - Beacon is sent every 3rd slot frame so every 3.03 seconds. - Beacon is sent on random channel out of 16, so but most likely different channel for every time, so if it waits for one channel for 16*3.03 seconds = 48.48 seconds it should have seen one beacon on that channel - After that timeout it can move to the next channel, as it might be that not all 16 channels are in use, so it needs to listen other channels too, testing all 16 channels takes 16 * 48.48 seconds = 775.68 seconds == abour 13 minutes. So after 13 minutes it can assume that there is no network and go to sleep. If EB_PERIOD is 10 then it needs to wait for 43 minutes... On the other hand in most cases all channels are in use, and it will find the beacon after 25 seconds or so on average with EB_PERIOD set to 3, and 80 seconds if EB_PERIOD is 10... This assumes that network has good parameters, i.e. if the slotframe size would be 100, and number of channels 10, then beacons would always end up on the same channel, and if that channel happened to be the last one scanned it can take long time to find out that channel. Also if that one channel ends up having issues, then beacons might be lost completely. Btw, all of the above do assume that none of the beacons are ever lost, so in practice the device needs to wait for 2-3 times the EB_PERIOD * slotframe size * timeslot length * number of channels before moving to next channel, or it might repeat the process 2-3 times before giving up. On the other hand tsch is quite chatty anyways, so the device should see at least some packets go over the air during the scan, and if it does not hear any radio transmissions during the scan it might skip to next channel must faster. > If so, how is that value communicated or configured in all devices? It is not communicated, and devices do not need to agree on value. -- kivinen@iki.fi From nobody Wed Feb 1 06:16:40 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E8F129D2C for <6tisch@ietfa.amsl.com>; Wed, 1 Feb 2017 06:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iiSMyKSOqgv for <6tisch@ietfa.amsl.com>; Wed, 1 Feb 2017 06:16:37 -0800 (PST) Received: from p3plsmtpa08-01.prod.phx3.secureserver.net (p3plsmtpa08-01.prod.phx3.secureserver.net [173.201.193.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780A1129997 for <6tisch@ietf.org>; Wed, 1 Feb 2017 06:16:37 -0800 (PST) Received: from [10.0.1.4] ([50.158.195.176]) by :SMTPAUTH: with SMTP id Yvhdcc3chXh1gYvhecGby2; Wed, 01 Feb 2017 07:16:06 -0700 From: PWK Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0F408F2F-565C-49CA-9ACB-4F86DC1D3741" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 1 Feb 2017 08:16:05 -0600 In-Reply-To: To: Thubert Pascal References: X-Mailer: Apple Mail (2.3259) X-CMAE-Envelope: MS4wfCb1lOEc+M1w7cIOd3K/bHLDCuvSRySN6p+J2y/FtogLyPQBMJgJdRRtt9MkET5/x2lPJT30dCUhCmv4SPB7F+6rlLPxCIMyWg6iL4+9Tl4Lu6X1jYEH lduauAn336zJzdNvZgDbS654ciAODctEqYzNlGfYSuYbsVEq0lu5eWEf0b+5G8+FcGRO3pu/KoOIHVbE3QoHPTKqY97tNBHebsw= Archived-At: Cc: 6tisch <6tisch@ietf.org> Subject: Re: [6tisch] Agenda, 03 February 2017 interim, 6TiSCH WG X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 14:16:39 -0000 --Apple-Mail=_0F408F2F-565C-49CA-9ACB-4F86DC1D3741 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In preparation for the 802.15.12 portion of the call, here is the link = to the presentation document: = https://mentor.ieee.org/802.15/dcn/17/15-17-0113-00-0012-802-15-12-concept= ual-overview.pptx = . Pascal could you please use this document as part = of the Webex? Thanks, Pat On 1, Feb2017, at 7:28, Pascal Thubert (pthubert) = wrote: Connection details Date: 7-8am Pacific: = http://www.worldtimebuddy.com/?qm=3D1&lid=3D100,12,5392171,1850147&h=3D100= &date=3D2017-02-03&sln=3D15-16 = Webex link: = https://cisco.webex.com/ciscosales/j.php?MTID=3Dmcdbbe3a4e38d97d986b507ec1= 2a1f9b1 = Meeting number (access code): 203 224 694 Meeting password: sixtus (749887 from phones) Agenda Administrivia [2min] Approval agenda=20 Approval minutes last call Status of drafts [Chairs] [5min] News from 802.15.12 [Pat] [25min] Wrap up ML discussions on 6top [Thomas] [25min] AOB [3min] As usual, if you wish to add/change stuff please let us know; The chairs. =20 _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch = --Apple-Mail=_0F408F2F-565C-49CA-9ACB-4F86DC1D3741 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In preparation for the 802.15.12 portion of the call, here is = the link to the presentation document: https://mentor.ieee.org/802.15/dcn/17/15-17-0113-00-0012-802-15= -12-conceptual-overview.pptx.  Pascal could you please use this = document as part of the Webex?

Thanks, Pat


On = 1, Feb2017, at 7:28, Pascal Thubert (pthubert) <pthubert@cisco.com> = wrote:

Connection details

Agenda

  • Administrivia [2min]
    • Approval = agenda 
    • Approval minutes last call
  • Status of drafts [Chairs] [5min]
  • News from 802.15.12 [Pat] [25min]
  • Wrap up ML discussions on 6top [Thomas] [25min]
  • AOB [3min]
As usual, if you wish to add/change stuff please let us = know;
The = chairs.
 
_______________________________________________
6tisch mailing = list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
= --Apple-Mail=_0F408F2F-565C-49CA-9ACB-4F86DC1D3741-- From nobody Wed Feb 1 07:23:28 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819DF12947A for <6tisch@ietfa.amsl.com>; Wed, 1 Feb 2017 07:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.719 X-Spam-Level: X-Spam-Status: No, score=-17.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFflOTRn41Gn for <6tisch@ietfa.amsl.com>; Wed, 1 Feb 2017 07:23:25 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1791293F3 for <6tisch@ietf.org>; Wed, 1 Feb 2017 07:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20469; q=dns/txt; s=iport; t=1485962605; x=1487172205; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sbReWlCRtJqQRIqvnTL+f/BnutEC7GbTDKsw243eq3c=; b=esO8BLFGecg7dV6pIxDNuN4NNdULbhBnp6w+ekf2wxc+ruqJSvxC954S 68RnN6h2iKGUzRCrgvWNRj8t/glqw92TuFpSI4towoM08cus8qhigKAGC KNla2/eW9dJyOoZYvXLRcSn1VgowY1Ae/idPx2THXD+k4AmHe+LXu/JmO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQA5/JFY/4UNJK1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvZGGBCQeNWZIHlTWCDR8BDIUsSgKCNj8YAQIBAQEBAQEBYii?= =?us-ascii?q?EaQEBAQQBAStBCxACAQgRAwEBARkIBAMHJwsUCQgBAQQOBQgSiVgOLa5Tg1SHW?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GS4RvgTyBVIFdFhiCEoJrGgWPdoVPhhc?= =?us-ascii?q?BhmaLE4IChRWJb5MAAR84gUsVO4RDHIFhdQEBhw+BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,320,1477958400"; d="scan'208,217";a="379166472" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2017 15:23:24 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v11FNOEh027989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Feb 2017 15:23:24 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Feb 2017 09:23:23 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 1 Feb 2017 09:23:23 -0600 From: "Pascal Thubert (pthubert)" To: PWK Thread-Topic: [6tisch] Agenda, 03 February 2017 interim, 6TiSCH WG Thread-Index: AdJ8jsTf4QveUKMiTrGkHZvVighb/AAOT8mAAApOgLA= Date: Wed, 1 Feb 2017 15:23:10 +0000 Deferred-Delivery: Wed, 1 Feb 2017 15:22:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.14] Content-Type: multipart/alternative; boundary="_000_c2ede139f92d4874b1f8e515caebd0f3XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: 6tisch <6tisch@ietf.org> Subject: Re: [6tisch] Agenda, 03 February 2017 interim, 6TiSCH WG X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 15:23:27 -0000 --_000_c2ede139f92d4874b1f8e515caebd0f3XCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks a bunch Pat ! I added your slides in the repo https://bitbucket.org/6tisch/meetings/raw/m= aster/170203_webex/slides_170203_webex.ppt Take care, Pascal From: PWK [mailto:pat.kinney@kinneyconsultingllc.com] Sent: mercredi 1 f=E9vrier 2017 15:16 To: Pascal Thubert (pthubert) Cc: Palattella Maria Rita <6tisch@ietf.org>; 6tisch <6tisch@ietf.org> Subject: Re: [6tisch] Agenda, 03 February 2017 interim, 6TiSCH WG In preparation for the 802.15.12 portion of the call, here is the link to t= he presentation document: https://mentor.ieee.org/802.15/dcn/17/15-17-0113-= 00-0012-802-15-12-conceptual-overview.pptx. Pascal could you please use th= is document as part of the Webex? Thanks, Pat On 1, Feb2017, at 7:28, Pascal Thubert (pthubert) > wrote: Connection details =B7 Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=3D1&lid= =3D100,12,5392171,1850147&h=3D100&date=3D2017-02-03&sln=3D15-16 =B7 Webex link: https://cisco.webex.com/ciscosales/j.php?MTID=3Dmcd= bbe3a4e38d97d986b507ec12a1f9b1 o Meeting number (access code): 203 224 694 o Meeting password: sixtus (749887 from phones) Agenda =B7 Administrivia [2min] o Approval agenda o Approval minutes last call =B7 Status of drafts [Chairs] [5min] =B7 News from 802.15.12 [Pat] [25min] =B7 Wrap up ML discussions on 6top [Thomas] [25min] =B7 AOB [3min] As usual, if you wish to add/change stuff please let us know; The chairs. _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch --_000_c2ede139f92d4874b1f8e515caebd0f3XCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks a bunch Pat !<= /span>

 

I added your slides in the repo https://bitbucket.org/6tisch/meetings/raw/master/170203_webex/slides_170203= _webex.ppt

 

Take care,

 

Pascal

 

From: P= WK [mailto:pat.kinney@kinneyconsultingllc.com]
Sent: mercredi 1 f=E9vrier 2017 15:16
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: Palattella Maria Rita <6tisch@ietf.org>; 6tisch <6tisch= @ietf.org>
Subject: Re: [6tisch] Agenda, 03 February 2017 interim, 6TiSCH WG

 

In preparation for the = 802.15.12 portion of the call, here is the link to the presentation documen= t: https://mentor.ieee.org/802.15/dcn/17/= 15-17-0113-00-0012-802-15-12-conceptual-overview.pptx.  Pascal could you please use this document as part of the Webex?=

 

Thanks, Pat<= /p>

 

 

On 1, Feb2017, at 7:28,= Pascal Thubert (pthubert) <pthube= rt@cisco.com> wrote:

Connection details

=B7         Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=3D1&lid=3D100,12,5392171,1850147&= ;h=3D100&date=3D2017-02-03&sln=3D15-16

=B7         Webex link: https://cisco.webex.com/ciscosales/j.php?MTID= =3Dmcdbbe3a4e38d97d986b507ec12a1f9b1

o    Meeting number (access code): 2= 03 224 694

o    Meeting password: sixtus (749887 from phone= s)

Agenda<= /o:p>

=B7         Administrivia [2min]

o    Approval agenda 

o    Approval minutes last call

=B7         Status of drafts [Chairs] [5min]=

=B7         News from 802.15.12 [Pat] [25mi= n]

=B7         Wrap up ML discussions on 6top [Thomas] [25= min]

=B7         AOB [3min]

As usual, if you wish = to add/change stuff please let us know;

The chairs.=

 

____________________= ___________________________
6tisch mailing list
6tisch@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/6tisch

 

--_000_c2ede139f92d4874b1f8e515caebd0f3XCHRCD001ciscocom_-- From nobody Thu Feb 2 05:09:40 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD031293E9 for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 05:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69KGT2trT635 for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 05:09:36 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86791293DA for <6tisch@ietf.org>; Thu, 2 Feb 2017 05:09:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,324,1477954800"; d="scan'208,217";a="211794909" Received: from mail-qt0-f178.google.com ([209.85.216.178]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 02 Feb 2017 14:09:32 +0100 Received: by mail-qt0-f178.google.com with SMTP id v23so29284038qtb.0 for <6tisch@ietf.org>; Thu, 02 Feb 2017 05:09:32 -0800 (PST) X-Gm-Message-State: AMke39m8c55czuK8Mjxw4L2Bh1PxS4NC2Bh2IULKXxvpi1ELKtuIQWG36ltiCfCdpW75pjmLX4e6V/+b2lTEew== X-Received: by 10.55.23.78 with SMTP id i75mr7615629qkh.212.1486040971678; Thu, 02 Feb 2017 05:09:31 -0800 (PST) MIME-Version: 1.0 From: Remy Leone Date: Thu, 02 Feb 2017 13:09:20 +0000 X-Gmail-Original-Message-ID: Message-ID: To: 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=001a11479df03d1d4b05478be098 Archived-At: Subject: [6tisch] Comments/questions about 6P draft X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 13:09:38 -0000 --001a11479df03d1d4b05478be098 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I got a bunch of remarks about the 6P draft https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03 *4.1.1. 2-step 6top Transaction* *4.1.2. 3-step 6top Transaction* Maybe it would be nice to add at the end of the workflow that if the transaction was successful, the schedule generation is incremented to allow inconsistencies detection. *4.2.4. 6P Command Identifiers* CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard or both cells that are concerned. *4.2.6. 6P CellOptions* In Figure 11, is there is mix-up between line 2 & 3 TX=3D1, *RX=3D0*, S=3D0 | select the cells scheduled with A and marked as *= RX* *TX=3D0*, RX=3D1, S=3D0 | select the cells scheduled with A and marked as *= TX* and the line 6 & 7? *TX=3D1*, RX=3D0, S=3D1 | select the cells scheduled with A and marked as *= RX* and SHARED TX=3D0, *RX=3D1*, S=3D1 | select the cells scheduled with A and marked as *= TX* and SHARED TX and RX don't seem to match. Also, I think it would be useful to define what SHARED means, I fail to find the definition in this draft. *4.3.6. Clearing the Schedule* I think it would be a good idea to specify whether it's hard cells or soft cells (or both) that are concerned by this. *6. Implementation Status* Support for 6P in Wireshark was merged upstream https://github.com/wireshark/wireshark/commit/8b0e66f22c059533643195ba7571c= afe9f006f58 Therefore there is a need to update the text concerning the Wireshark dissector. Best regards R=C3=A9my --001a11479df03d1d4b05478be098 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I got a bunch of remarks about t= he 6P draft=C2=A0

4.1.1. 2-step 6to= p Transaction
4.1.2. 3-step 6top Transaction

Maybe it would be nice to add at the end of the workflow th= at if the transaction was successful, the schedule generation is incremente= d to allow inconsistencies detection.

4.2.4. 6P= Command Identifiers

CMD_CLEAR: Maybe it would= be a good idea to specify whether it soft, hard or both cells that are con= cerned.

4.2.6. 6P CellOptions

In F= igure 11, is there is mix-up between line 2 & 3
TX=3D1, RX=3D0, S=3D0 | select the cells scheduled with A and marked as RX
TX=3D0, RX=3D1, S=3D0 | select the cells scheduled with A and marked a= s TX

and the line 6 & 7?

TX=3D1, RX=3D0, = S=3D1 | select the cells scheduled with A and marked as RX and SHARE= D=C2=A0
TX=3D0, RX=3D1, S=3D1 | select the cells scheduled= with A and marked as TX and SHARED

TX and RX don't= seem to match.

Also, I think it would be useful t= o define what SHARED means, I fail to find the definition in this draft.

4.3.6. Clearing the Schedule

I think it would be a good idea to specify whether it's hard c= ells or soft cells (or both) that are concerned by this.

6. Implementation Status

Support for= 6P in Wireshark was merged upstream
Therefore there is a need to update the text conc= erning the Wireshark dissector.


Best regards

R=C3=A9my
--001a11479df03d1d4b05478be098-- From nobody Thu Feb 2 05:34:07 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B441E129439; Thu, 2 Feb 2017 05:34:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148604244173.29476.7003834767723400058.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 05:34:01 -0800 Archived-At: Cc: 6tisch@ietf.org Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-01.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 13:34:02 -0000 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 of the IETF. Title : Minimal Security Framework for 6TiSCH Authors : Malisa Vucinic Jonathan Simon Kris Pister Filename : draft-ietf-6tisch-minimal-security-01.txt Pages : 17 Date : 2017-02-02 Abstract: This draft describes the minimal mechanisms required to support secure initial configuration in a device being added to a 6TiSCH network. The goal of this configuration is to set link-layer keys, and to establish a secure session between each joining node and the JCE who may use that to further configure the joining device. Additional security behaviors and mechanisms may be added on top of this minimal framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 2 05:42:16 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CF712943A for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 05:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14oZu3IF9M8P for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 05:42:13 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AC5129417 for <6tisch@ietf.org>; Thu, 2 Feb 2017 05:42:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,324,1477954800"; d="scan'208";a="211799812" Received: from unknown (HELO [128.93.85.17]) ([128.93.85.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2017 14:42:11 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <148604244173.29476.7003834767723400058.idtracker@ietfa.amsl.com> Date: Thu, 2 Feb 2017 14:42:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5C48B942-1E87-45CB-9124-24524C041044@inria.fr> References: <148604244173.29476.7003834767723400058.idtracker@ietfa.amsl.com> To: 6tisch <6tisch@ietf.org> X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-01.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 13:42:15 -0000 All, Following the change to markdown, we submitted a version of the = minimal-security draft that has *no* content changes, only slight = editorial fixes. This was necessary in order to ensure that future = versions have a clean diff. A thanks goes to Michael for his help with = this transition. Within the security design team, we are working on the = -02 version that will include latest discussions on minimal security. Regards, Mali=C5=A1a > On 02 Feb 2017, at 14:34, internet-drafts@ietf.org wrote: >=20 >=20 > 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 of the IETF. >=20 > Title : Minimal Security Framework for 6TiSCH > Authors : Malisa Vucinic > Jonathan Simon > Kris Pister > Filename : draft-ietf-6tisch-minimal-security-01.txt > Pages : 17 > Date : 2017-02-02 >=20 > Abstract: > This draft describes the minimal mechanisms required to support > secure initial configuration in a device being added to a 6TiSCH > network. The goal of this configuration is to set link-layer keys, > and to establish a secure session between each joining node and the > JCE who may use that to further configure the joining device. > Additional security behaviors and mechanisms may be added on top of > this minimal framework. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-security-01 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch From nobody Thu Feb 2 07:39:01 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9517C129667 for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 07:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtOs2uiDPv2T for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 07:38:58 -0800 (PST) Received: from mo.tsb.2iij.net (mo1501.tsb.2iij.net [210.149.48.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18F0129673 for <6tisch@ietf.org>; Thu, 2 Feb 2017 07:38:57 -0800 (PST) Received: by mo.tsb.2iij.net (tsb-mo1501) id v12Fcsqi005745; Fri, 3 Feb 2017 00:38:54 +0900 Received: from unknown [172.27.153.184] (EHLO tsb-mr1500.hop.2iij.net) by mas1509.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id e8253985.0.48656.00-697.97323.mas1509.tsb.2iij.net (envelope-from ); Fri, 03 Feb 2017 00:38:54 +0900 (JST) X-MXL-Hash: 5893528e06f51a94-75c5b9deef1ddeab700a3e0c21fdfaa211ad43e2 Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.tsb.2iij.net (tsb-mr1500) with ESMTP id v12FcsOI019299 for <6tisch@ietf.org>; Fri, 3 Feb 2017 00:38:54 +0900 Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id v12Fcshv029637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch@ietf.org>; Fri, 3 Feb 2017 00:38:54 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v12FcsIX021711 for <6tisch@ietf.org>; Fri, 3 Feb 2017 00:38:54 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 717 for <6tisch@ietf.org>; Fri, 3 Feb 2017 00:38:54 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v12FcsYf021708 for <6tisch@ietf.org>; Fri, 3 Feb 2017 00:38:54 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id v12FcsSZ022878 for 6tisch@ietf.org; Fri, 3 Feb 2017 00:38:54 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id AAA22877; Fri, 3 Feb 2017 00:38:53 +0900 Received: from mx11.toshiba.co.jp (mx11.toshiba.co.jp [133.199.90.141]) by ovp11.toshiba.co.jp with ESMTP id v12Fcrd2026080 for <6tisch@ietf.org>; Fri, 3 Feb 2017 00:38:53 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id v12FcrSH024747; Fri, 3 Feb 2017 00:38:53 +0900 (JST) Received: from [133.196.17.211] (nm-pptp211.isl.rdc.toshiba.co.jp [133.196.17.211]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id C9A4EFF5A8; Fri, 3 Feb 2017 00:38:52 +0900 (JST) To: 6tisch@ietf.org References: From: Yasuyuki Tanaka Message-ID: Date: Thu, 2 Feb 2017 16:38:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp id v12FcsYf021708 X-MAIL-FROM: X-SOURCE-IP: [172.27.153.184] X-Spam: exempt Archived-At: Subject: Re: [6tisch] Comments/questions about 6P draft X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:39:00 -0000 Hi R=E9my, From my understanding, CMD_CLEAR won't have any impact on hard cells sin= ce hard cells are read-only for 6top. https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-3.= 1 draft> 3.1. Hard/Soft Cells draft> draft> 6top qualifies each cell in the schedule as either "hard" or "s= oft": draft> draft> o a soft cell can be read, added, deleted or updated by 6top. draft> o a hard cell is read-only for 6top. draft> In the context of this specification, all the cells used by 6to= p are draft> soft cells. > In Figure 11, is there is mix-up between line 2 & 3 ... > and the line 6 & 7? Oh, I didn't notice that!! https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-4.= 2.6 (row-2 in Figure 11) draft> +-------------+--------------------------------------------= ---+ draft> |TX=3D1,RX=3D0,S=3D0| select the cells scheduled with A = | draft> |^^ | and marked as RX = | draft> | | ^^ = | draft> +-------------+--------------------------------------------= ---+ > Also, I think it would be useful to define what SHARED means, I fail to= find > the definition in this draft. I agree; we'd need some text explaining the meaning of each bit listed in Figure 10. Actually, the idea come from Link Options defined in Section 7= .4.4.3 in IEEE Std 802.15.4(-2015). Best, Yatch On 2017/02/02 14:09, Remy Leone wrote: > Hello, > > I got a bunch of remarks about the 6P draft > https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03 > > _4.1.1. 2-step 6top Transaction_ > _4.1.2. 3-step 6top Transaction_ > > Maybe it would be nice to add at the end of the workflow that if the tr= ansaction was successful, the schedule generation is incremented to allow= inconsistencies detection. > > _4.2.4. 6P Command Identifiers_ > > CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, ha= rd or both cells that are concerned. > > _4.2.6. 6P CellOptions_ > > In Figure 11, is there is mix-up between line 2 & 3 > TX=3D1, *RX=3D0*, S=3D0 | select the cells scheduled with A and marked = as *RX* > *TX=3D0*, RX=3D1, S=3D0 | select the cells scheduled with A and marked = as *TX* > > and the line 6 & 7? > > *TX=3D1*, RX=3D0, S=3D1 | select the cells scheduled with A and marked = as *RX* and SHARED > TX=3D0, *RX=3D1*, S=3D1 | select the cells scheduled with A and marked = as *TX* and SHARED > > TX and RX don't seem to match. > > Also, I think it would be useful to define what SHARED means, I fail to= find the definition in this draft. > > _4.3.6. Clearing the Schedule_ > > I think it would be a good idea to specify whether it's hard cells or s= oft cells (or both) that are concerned by this. > > _6. Implementation Status_ > > Support for 6P in Wireshark was merged upstream > https://github.com/wireshark/wireshark/commit/8b0e66f22c059533643195ba7= 571cafe9f006f58 > Therefore there is a need to update the text concerning the Wireshark d= issector. > > > Best regards > > R=E9my > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > From nobody Thu Feb 2 08:30:30 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617CB129484 for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 08:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.054 X-Spam-Level: X-Spam-Status: No, score=-7.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8-pvxBHGZiU for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 08:30:27 -0800 (PST) Received: from nm17-vm1.bullet.mail.bf1.yahoo.com (nm17-vm1.bullet.mail.bf1.yahoo.com [98.139.213.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8187B1293FC for <6tisch@ietf.org>; Thu, 2 Feb 2017 08:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1486053026; bh=nTk7na009tHVDWilw5/xA8PG+rWSXvHxGFuNoBte7GE=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=npmiB0LGxTSv6le/YJuSlk8tB8iThrzk+Q+60dIzBUGKJZ4XPhR6P2nBK1dg1YCp5j8b/E4UxQXkWxJOWvs7IkErGSy2G7ygnHfHOvsc2F9jjRrgTk5H3OMqLHN8m/1L7sMSypnIq9yMXwI9W+OTTXpmEHIaI49vZAA4Ez7jG1+C6vfc17xeZ9j5Ab4la03E9TRiOajMu/A+zPF5rN4VlAm3Q19dcc4usUgi9deq4/fcZkj5SwH1e4As7N6YIajp4+drwc5SIb5ABC4s+p1hvl7+Z1aAF+BSezML1Fq5aO9j+NZwshXAxmGgw1IXzXr1kAjpgHjBuIa12oWNhHt4Kw== Received: from [98.139.170.180] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 02 Feb 2017 16:30:26 -0000 Received: from [98.139.212.250] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 02 Feb 2017 16:30:26 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 02 Feb 2017 16:30:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 628237.41955.bm@omp1059.mail.bf1.yahoo.com X-YMail-OSG: u_U.3REVM1lvRCWxelhomMu3mtVb0TJAa4jOlmDnJuz_1X6bVjrwso_86Qs..as Sw7m9ZfKC.yz0lgFJDMCQu0Wpaya1phzo75f1CDgypwnE8H2.n.W447Lh1odT2k_FmwGsNDGrSq4 Eg_ZJFoCLctkrPnvESNc9QFptrBACzgr.7brb6oGHsAnFuR7zya_rmEtIe1VqqsBJLydqeYKwVIe L9u818v5LL.UD_GmxICQOGq0J4hKGrCJDZwmj2VMN32H1G2tBxOsBN.24NRKWDWwveM11y5stajT m9k7QdHsAQIVVOOfK8BjT2pqXviAC7VoJb99rLVixhS9kri_6L5AOeVh7YCdFRXn0Wuk4RhZ_KWo d5B0z8ganBGbr7suwJ99nw3JK7dtSH5bf35uU.RuxNNSkk1yfQCMFQc040yQzN2I5EctRI6lFehU 5EG1dWgdZ2Wmse19OlkUcAhQ9GkSKAmOrG8YwNa6_XlYLG7t0ejfKkfWO2PQVuhFJUJCzQDTyPho .FUZZBzJxMnUH.VE1TPmWSoRgrdClnJW.lg-- Received: from jws400055.mail.bf2.yahoo.com by sendmailws164.mail.bf1.yahoo.com; Thu, 02 Feb 2017 16:30:26 +0000; 1486053026.256 Date: Thu, 2 Feb 2017 16:29:30 +0000 (UTC) From: Qin Wang To: Remy Leone , 6TiSCH mailing list <6tisch@ietf.org> Message-ID: <793671973.4410928.1486052970166@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4410927_1866036121.1486052970163" Archived-At: Subject: Re: [6tisch] Comments/questions about 6P draft X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Qin Wang List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:30:29 -0000 ------=_Part_4410927_1866036121.1486052970163 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Remy, Regarding to your question on=C2=A04.2.6. =C2=A06P CellOptions, the first c= olumn 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=20 On Thursday, February 2, 2017 8:09 AM, Remy Leone = wrote: =20 Hello, I got a bunch of remarks about the 6P draft=C2=A0https://tools.ietf.org/htm= l/draft-ietf-6tisch-6top-protocol-03=C2=A0 4.1.1. 2-step 6top Transaction4.1.2. 3-step 6top Transaction Maybe it would be nice to add at the end of the workflow that if the transa= ction was successful, the schedule generation is incremented to allow incon= sistencies detection. 4.2.4. 6P Command Identifiers CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard o= r both cells that are concerned. 4.2.6. 6P CellOptions In Figure 11, is there is mix-up between line 2 & 3 TX=3D1, RX=3D0, S=3D0 | select the cells scheduled with A and marked as RXT= X=3D0, RX=3D1, S=3D0 | select the cells scheduled with A and marked as TX= =20 and the line 6 & 7?=20 TX=3D1, RX=3D0, S=3D1 | select the cells scheduled with A and marked as RX = and SHARED=C2=A0TX=3D0, RX=3D1, S=3D1 | select the cells scheduled with A a= nd marked as TX and SHARED=20 TX and RX don't seem to match. Also, I think it would be useful to define what SHARED means, I fail to fin= d the definition in this draft. 4.3.6. Clearing the Schedule I think it would be a good idea to specify whether it's hard cells or soft = cells (or both) that are concerned by this. 6. Implementation Status Support for 6P in Wireshark was merged upstreamhttps://github.com/wireshark= /wireshark/commit/8b0e66f22c059533643195ba7571cafe9f006f58 Therefore there is a need to update the text concerning the Wireshark disse= ctor. Best regards R=C3=A9my _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch =20 ------=_Part_4410927_1866036121.1486052970163 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Remy,

Regarding = to your question on 4.2.6.  6P CellOptions, the first column is t= he cell's type from node A's point of view, and the second column is the ce= ll's type from node B's point of view. Does it make sense?

=
T= hanks
Qin


On Thursday, February 2, 2017 = 8:09 AM, Remy Leone <remy.leone@inria.fr> wrote:

Hello,

I got a bunch of remarks about the 6P draft=  

<= div>4.1.1. 2-step 6top Transaction
4.1.2. 3-step 6top T= ransaction

Maybe it would be nice to add at th= e end of the workflow that if the transaction was successful, the schedule = generation is incremented to allow inconsistencies detection.
4.2.4. 6P Command Identifiers

C= MD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard or= both cells that are concerned.

4.2.6. 6P CellO= ptions

In Figure 11, is there is mix-up between line 2 & 3=
TX=3D1, RX=3D0, S=3D0 | select the cells scheduled with A and ma= rked as RX
TX=3D0, RX=3D1, S=3D0 | select the cells sched= uled with A and marked as TX

and the line 6 & 7?
TX=3D1, RX=3D0, S=3D1 | select the cells scheduled with A and marke= d as RX and SHARED 
TX=3D0, RX=3D1, S=3D1 | se= lect the cells scheduled with A and marked as TX and SHARED

=
TX and RX don't seem to match.

Also, I think = it would be useful to define what SHARED means, I fail to find the definiti= on in this draft.

4.3.6. Clearing the Schedule<= /u>

I think it would be a good idea to specify whe= ther it's hard cells or soft cells (or both) that are concerned by this.

6. Implementation Status

=
Support for 6P in Wireshark was merged upstream
Therefore there is a need to update the text concerning the Wireshark dis= sector.


Best regards

R=C3=A9my

___________________________= ____________________
6tisch mailing list
6tisch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/6tisch


------=_Part_4410927_1866036121.1486052970163-- From nobody Thu Feb 2 08:39:00 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7CB129855 for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 08:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km-CkfdWPUKw for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 08:38:57 -0800 (PST) Received: from mo.tsb.2iij.net (mo1500.tsb.2iij.net [210.149.48.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABA2129857 for <6tisch@ietf.org>; Thu, 2 Feb 2017 08:38:56 -0800 (PST) Received: by mo.tsb.2iij.net (tsb-mo1500) id v12GcsAj013452; Fri, 3 Feb 2017 01:38:54 +0900 Received: from unknown [172.27.153.190] (EHLO tsb-mr1502.hop.2iij.net) by mas1509.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id e9063985.0.50144.00-686.100218.mas1509.tsb.2iij.net (envelope-from ); Fri, 03 Feb 2017 01:38:54 +0900 (JST) X-MXL-Hash: 5893609e3fbbe4be-c339d71733ca9af3ee5c85e26f4a55ccbdd8c952 Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.tsb.2iij.net (tsb-mr1502) with ESMTP id v12GcsAv014716 for <6tisch@ietf.org>; Fri, 3 Feb 2017 01:38:54 +0900 Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id v12Gcss9002551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch@ietf.org>; Fri, 3 Feb 2017 01:38:54 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v12Gcs5x007772 for <6tisch@ietf.org>; Fri, 3 Feb 2017 01:38:54 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 804 for <6tisch@ietf.org>; Fri, 3 Feb 2017 01:38:54 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v12GcsJx007769 for <6tisch@ietf.org>; Fri, 3 Feb 2017 01:38:54 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id v12GcsPN029929 for 6tisch@ietf.org; Fri, 3 Feb 2017 01:38:54 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id BAA29926; Fri, 3 Feb 2017 01:38:54 +0900 Received: from mx2.toshiba.co.jp (mx2 [133.199.192.142]) by ovp11.toshiba.co.jp with ESMTP id v12GcrS9029657 for <6tisch@ietf.org>; Fri, 3 Feb 2017 01:38:53 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id v12GcrRu013020; Fri, 3 Feb 2017 01:38:53 +0900 (JST) Received: from [133.196.17.230] (nm-pptp230.isl.rdc.toshiba.co.jp [133.196.17.230]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 7C957FF5A8; Fri, 3 Feb 2017 01:38:52 +0900 (JST) To: qinwang6top@yahoo.com References: From: Yasuyuki Tanaka Message-ID: <2fb31ba2-eaf8-72a8-fc24-9fb0dcd5a40a@toshiba.co.jp> Date: Thu, 2 Feb 2017 17:38:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp id v12GcsJx007769 X-MAIL-FROM: X-SOURCE-IP: [172.27.153.190] X-Spam: exempt Archived-At: Cc: 6tisch@ietf.org Subject: Re: [6tisch] Comments/questions about 6P draft X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:38:59 -0000 Hi Qin, >> In Figure 11, is there is mix-up between line 2 & 3 ... >> and the line 6 & 7? > > Oh, I didn't notice that!! Oops, you're right... Thank you! :-) draft> Figure 10: Format of the CellOptions field draft> draft> Note: assuming node A issues the 6P command to node B. draft> ^^^^^^^^^^^^^^^^^^^^^^ draft> +-------------+--------------------------------------------= ---+ draft> | CellOptions | B's action when receiving a 6P message from= A | draft> | Value | ^^^^^^^^^^ = | draft> +-------------+--------------------------------------------= ---+ draft> |TX=3D0,RX=3D0,S=3D0| select all cells scheduled with A = | draft> +-------------+--------------------------------------------= ---+ draft> |TX=3D1,RX=3D0,S=3D0| select the cells scheduled with A = | draft> | | and marked as RX = | draft> +-------------+--------------------------------------------= ---+ Best, Yatch On 2017/02/02 16:38, Yasuyuki Tanaka wrote: > Hi R=E9my, > > From my understanding, CMD_CLEAR won't have any impact on hard cells si= nce hard > cells are read-only for 6top. > > https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-= 3.1 > draft> 3.1. Hard/Soft Cells > draft> > draft> 6top qualifies each cell in the schedule as either "hard" or = "soft": > draft> > draft> o a soft cell can be read, added, deleted or updated by 6top. > draft> o a hard cell is read-only for 6top. > draft> In the context of this specification, all the cells used by 6= top are > draft> soft cells. > >> In Figure 11, is there is mix-up between line 2 & 3 ... >> and the line 6 & 7? > > Oh, I didn't notice that!! > > https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-= 4.2.6 > (row-2 in Figure 11) > draft> +-------------+------------------------------------------= -----+ > draft> |TX=3D1,RX=3D0,S=3D0| select the cells scheduled with A = | > draft> |^^ | and marked as RX = | > draft> | | ^^ = | > draft> +-------------+------------------------------------------= -----+ > >> Also, I think it would be useful to define what SHARED means, I fail t= o find >> the definition in this draft. > > I agree; we'd need some text explaining the meaning of each bit listed = in > Figure 10. Actually, the idea come from Link Options defined in Section= 7.4.4.3 > in IEEE Std 802.15.4(-2015). > > Best, > Yatch > > On 2017/02/02 14:09, Remy Leone wrote: >> Hello, >> >> I got a bunch of remarks about the 6P draft >> https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03 >> >> _4.1.1. 2-step 6top Transaction_ >> _4.1.2. 3-step 6top Transaction_ >> >> Maybe it would be nice to add at the end of the workflow that if the t= ransaction was successful, the schedule generation is incremented to allo= w inconsistencies detection. >> >> _4.2.4. 6P Command Identifiers_ >> >> CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, h= ard or both cells that are concerned. >> >> _4.2.6. 6P CellOptions_ >> >> In Figure 11, is there is mix-up between line 2 & 3 >> TX=3D1, *RX=3D0*, S=3D0 | select the cells scheduled with A and marked= as *RX* >> *TX=3D0*, RX=3D1, S=3D0 | select the cells scheduled with A and marked= as *TX* >> >> and the line 6 & 7? >> >> *TX=3D1*, RX=3D0, S=3D1 | select the cells scheduled with A and marked= as *RX* and SHARED >> TX=3D0, *RX=3D1*, S=3D1 | select the cells scheduled with A and marked= as *TX* and SHARED >> >> TX and RX don't seem to match. >> >> Also, I think it would be useful to define what SHARED means, I fail t= o find the definition in this draft. >> >> _4.3.6. Clearing the Schedule_ >> >> I think it would be a good idea to specify whether it's hard cells or = soft cells (or both) that are concerned by this. >> >> _6. Implementation Status_ >> >> Support for 6P in Wireshark was merged upstream >> https://github.com/wireshark/wireshark/commit/8b0e66f22c059533643195ba= 7571cafe9f006f58 >> Therefore there is a need to update the text concerning the Wireshark = dissector. >> >> >> Best regards >> >> R=E9my >> >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> From nobody Thu Feb 2 08:41:08 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E869128874 for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 08:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf3MQhntH_O9 for <6tisch@ietfa.amsl.com>; Thu, 2 Feb 2017 08:41:04 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFE51294BB for <6tisch@ietf.org>; Thu, 2 Feb 2017 08:41:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,325,1477954800"; d="scan'208,217";a="211829844" Received: from mail-qt0-f169.google.com ([209.85.216.169]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 02 Feb 2017 17:41:00 +0100 Received: by mail-qt0-f169.google.com with SMTP id w20so35645315qtb.1 for <6tisch@ietf.org>; Thu, 02 Feb 2017 08:41:00 -0800 (PST) X-Gm-Message-State: AMke39n++VwYzi5aiMwJZuOOFaIvHWkCf6Wm7Zz+l1NSOq2JtELOQ6rUDKuXz+NBoLKJtyj5ZgZcNRZAON6S/w== X-Received: by 10.55.23.78 with SMTP id i75mr8631601qkh.212.1486053659050; Thu, 02 Feb 2017 08:40:59 -0800 (PST) MIME-Version: 1.0 References: <793671973.4410928.1486052970166@mail.yahoo.com> In-Reply-To: <793671973.4410928.1486052970166@mail.yahoo.com> From: Remy Leone Date: Thu, 02 Feb 2017 16:40:48 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Qin Wang , 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=001a11479df0772feb05478ed46d Archived-At: Subject: Re: [6tisch] Comments/questions about 6P draft X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:41:06 -0000 --001a11479df0772feb05478ed46d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes it makes sense but I think it would be helpful to put a reminder such as: select the cells scheduled with A and marked as *RX *(therefore TX from B point of view). There is enough space for it and it won't hurt :-) Le jeu. 2 f=C3=A9vr. 2017 =C3=A0 17:30, Qin Wang a = =C3=A9crit : > 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? > > Thanks > Qin > > > On Thursday, February 2, 2017 8:09 AM, Remy Leone > wrote: > > > Hello, > > I got a bunch of remarks about the 6P draft > https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03 > > *4.1.1. 2-step 6top Transaction* > *4.1.2. 3-step 6top Transaction* > > Maybe it would be nice to add at the end of the workflow that if the > transaction was successful, the schedule generation is incremented to all= ow > inconsistencies detection. > > *4.2.4. 6P Command Identifiers* > > CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard > or both cells that are concerned. > > *4.2.6. 6P CellOptions* > > In Figure 11, is there is mix-up between line 2 & 3 > TX=3D1, *RX=3D0*, S=3D0 | select the cells scheduled with A and marked as= *RX* > *TX=3D0*, RX=3D1, S=3D0 | select the cells scheduled with A and marked as= *TX* > > and the line 6 & 7? > > *TX=3D1*, RX=3D0, S=3D1 | select the cells scheduled with A and marked as= *RX* > and SHARED > TX=3D0, *RX=3D1*, S=3D1 | select the cells scheduled with A and marked as= *TX* > and SHARED > > TX and RX don't seem to match. > > Also, I think it would be useful to define what SHARED means, I fail to > find the definition in this draft. > > *4.3.6. Clearing the Schedule* > > I think it would be a good idea to specify whether it's hard cells or sof= t > cells (or both) that are concerned by this. > > *6. Implementation Status* > > Support for 6P in Wireshark was merged upstream > > https://github.com/wireshark/wireshark/commit/8b0e66f22c059533643195ba757= 1cafe9f006f58 > Therefore there is a need to update the text concerning the Wireshark > dissector. > > > Best regards > > R=C3=A9my > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > --001a11479df0772feb05478ed46d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes it makes sense but I think it would be helpful to put = a reminder such as:

select= the cells scheduled with A and marked as=C2=A0RX (therefore TX from B point of view).

There is enough space for i= t and it won't hurt :-)

Le=C2=A0jeu. 2 f=C3=A9vr. 2017 =C3=A0=C2=A017:30, Qin Wa= ng <qinwang6top@yahoo.com&g= t; a =C3=A9crit=C2=A0:
Hi = Remy,

Regardin= g to your question on=C2=A04.2.6. =C2=A06P 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= ?

Thanks
Qin
=


On Thursday, February 2, 2017 8:09 AM, Remy Leone <remy.leone@i= nria.fr> wrote:


Hello,

I got a bunch of remarks about the 6P draft=C2= =A0

4.1.1.= 2-step 6top Transaction
4.1.2. 3-step 6top Transaction
Maybe it would be nice = to add at the end of the workflow that if the transaction was successful, t= he schedule generation is incremented to allow inconsistencies detection.

4.2.4. 6P Command Identifiers

CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard = or both cells that are concerned.

4.2.6.= 6P CellOptions

In Figure 11, is there is = mix-up between line 2 & 3
TX=3D1, RX=3D0, S=3D0 | select the cells scheduled with A and marked a= s RX
TX=3D0, RX=3D1, S=3D0 | select the cells scheduled with A and marke= d as TX

and the line 6 & 7?

TX=3D1, RX=3D0, S=3D1 | select the cells sc= heduled with A and marked as RX and SHARED=C2=A0=
TX=3D0, RX=3D1, S= =3D1 | select the cells scheduled with A and marked as TX and SHARED

TX and RX don't seem to match.

Also, I thi= nk it would be useful to define what SHARED means, I fail to find the defin= ition in this draft.

=
4.3.6. Clearing the S= chedule

I think it would be a good idea to specify whether it= 's hard cells or soft cells (or both) that are concerned by this.
=

6. Implementation Status

Support = for 6P in Wireshark was merged upstream
Theref= ore there is a need to update the text concerning the Wireshark dissector.<= /div>


Best= regards

R=C3=A9my

_____________________________________________= __
6tisch mailing list
6tisch@i= etf.org
https://www.ietf.org= /mailman/listinfo/6tisch


<= /div> --001a11479df0772feb05478ed46d-- From nobody Fri Feb 3 00:44:48 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6729B129614; Fri, 3 Feb 2017 00:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.709 X-Spam-Level: X-Spam-Status: No, score=-17.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd34m63J717p; Fri, 3 Feb 2017 00:44:44 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F8D129AE3; Fri, 3 Feb 2017 00:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21526; q=dns/txt; s=iport; t=1486111484; x=1487321084; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=P7Q4eE1vpg4cBl0g9uWD/jGcsaeF743Vl3IuhOOURW8=; b=artTkdhZmY5y++ZUEhl5L7FthzwoDxR1LxIFn78lO8p2I+c0/INC11C+ eq6A/Xwft/d4i0FRBM1rVj6vjvMtwkCS6mlI2cwsE1kaF74oPlxbogOCt u8LasmBYQyRUxvnAiDquqOkRG+bVxGPhcTmxm+YZ4sG6wotuJo2KTmUmX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAQBmQpRY/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9kYYEJB4NRigiSCpALhSuCDR8BDIUsSgIagj4/GAECAQEBAQE?= =?us-ascii?q?BAWIohGkBAQEDAQEBIQpBEAcEAgEIEQQBASgDAgICJQsUCQgCBAESCIlhCA6sc?= =?us-ascii?q?YIlizoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhkuEb4MQgQ8RAYMigl8FjziMKQG?= =?us-ascii?q?GZ4Meh3iCBFOERIlwkwgBHzh2VRUYI4REHYFhdYZzgSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,328,1477958400"; d="scan'208,217";a="202274953" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2017 08:44:43 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v138ihnb014925 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Feb 2017 08:44:43 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Feb 2017 02:44:42 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 3 Feb 2017 02:44:42 -0600 From: "Pascal Thubert (pthubert)" To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , 6tisch <6tisch@ietf.org>, "ietf-action@ietf.org" Thread-Topic: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-01.txt Thread-Index: AQHSfVouPNAC6RM+IkGRNELIvJ5gfqFW9rSQ Date: Fri, 3 Feb 2017 08:44:17 +0000 Deferred-Delivery: Fri, 3 Feb 2017 08:44:15 +0000 Message-ID: <5f688af6f901498789032b52843dd044@XCH-RCD-001.cisco.com> References: <148604244173.29476.7003834767723400058.idtracker@ietfa.amsl.com> <5C48B942-1E87-45CB-9124-24524C041044@inria.fr> In-Reply-To: <5C48B942-1E87-45CB-9124-24524C041044@inria.fr> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.14] Content-Type: multipart/alternative; boundary="_000_5f688af6f901498789032b52843dd044XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-01.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 08:44:46 -0000 --_000_5f688af6f901498789032b52843dd044XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTWFsacWhYToNCg0KDQoNCkkgbm90ZWQgdGhhdCBmb3Igc29tZSByZWFzb24sIHRoZSBh dXRvbWF0ZWQgSUVURiBiaWJ0ZXggZ2VuZXJhdGlvbiBkb2VzIG5vdCB3b3JrIHdlbGwgd2l0aCB5 b3VyIGRyYWZ0Lg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12dWNp bmljLTZ0aXNjaC1taW5pbWFsLXNlY3VyaXR5L2JpYnRleC8gaW4gdGhlIGxpbmUNCg0KYXV0aG9y ID0gICAgICAgICAgICAgICB7bWFsaXNhLnZ1Y2luaWNAc3QuY29tIGFuZCBKb25hdGhhbiBTaW1v biBhbmQgS3JpcyBQaXN0ZXJ9LA0KDQoNCg0KVGhpcyBwcm9ibGVtIHdhcyBwcmVzZW50IGluIHRo ZSAwMCwgc28gd2hhdGV2ZXIgbWFya2Rvd24gY2hhbmdlZCBkaWQgbm90IGZpeCBpdC4NCg0KVHJv dWJsZSBpcyB0aGF0IGFuIGVtYWlsIGFkZHJlc3MgYXBwZWFycyBpbnN0ZWFkIG9mIHlvdXIgbmFt ZSBhbmQgdGhhdCBlbWFpbCBhZGRyZXNzIGlzIG5vdCBldmVuIHRoZSBvbmUgaW4geW91ciBkcmFm dC4NCg0KDQoNCkxvb2tpbmcgYXQgdGhlIHBkZiBJIGNhbm5vdCBzZWUgYW55dGhpbmcgYWJzdXJk Lg0KDQoNCg0KQ2MnaW5nIGlldGYtYWN0aW9uLg0KDQoNCg0KVGFrZSBjYXJlLA0KDQoNCg0KUGFz Y2FsDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IDZ0aXNjaCBb bWFpbHRvOjZ0aXNjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFsacWhYSBWdWNp bmljDQpTZW50OiBqZXVkaSAyIGbDqXZyaWVyIDIwMTcgMTQ6NDINClRvOiA2dGlzY2ggPDZ0aXNj aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbNnRpc2NoXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LTZ0aXNjaC1taW5pbWFsLXNlY3VyaXR5LTAxLnR4dA0KDQoNCg0KQWxsLA0KDQoNCg0KRm9sbG93 aW5nIHRoZSBjaGFuZ2UgdG8gbWFya2Rvd24sIHdlIHN1Ym1pdHRlZCBhIHZlcnNpb24gb2YgdGhl IG1pbmltYWwtc2VjdXJpdHkgZHJhZnQgdGhhdCBoYXMgKm5vKiBjb250ZW50IGNoYW5nZXMsIG9u bHkgc2xpZ2h0IGVkaXRvcmlhbCBmaXhlcy4gVGhpcyB3YXMgbmVjZXNzYXJ5IGluIG9yZGVyIHRv IGVuc3VyZSB0aGF0IGZ1dHVyZSB2ZXJzaW9ucyBoYXZlIGEgY2xlYW4gZGlmZi4gQSB0aGFua3Mg Z29lcyB0byBNaWNoYWVsIGZvciBoaXMgaGVscCB3aXRoIHRoaXMgdHJhbnNpdGlvbi4gV2l0aGlu IHRoZSBzZWN1cml0eSBkZXNpZ24gdGVhbSwgd2UgYXJlIHdvcmtpbmcgb24gdGhlIC0wMiB2ZXJz aW9uIHRoYXQgd2lsbCBpbmNsdWRlIGxhdGVzdCBkaXNjdXNzaW9ucyBvbiBtaW5pbWFsIHNlY3Vy aXR5Lg0KDQoNCg0KUmVnYXJkcywNCg0KTWFsacWhYQ0KDQoNCg0KPiBPbiAwMiBGZWIgMjAxNywg YXQgMTQ6MzQsIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPiB3cm90ZToNCg0KPg0KDQo+DQoNCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0K DQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgb3ZlciB0aGUgVFNDSCBt b2RlIG9mIElFRUUgODAyLjE1LjRlIG9mIHRoZSBJRVRGLg0KDQo+DQoNCj4gICAgICAgIFRpdGxl ICAgICAgICAgICA6IE1pbmltYWwgU2VjdXJpdHkgRnJhbWV3b3JrIGZvciA2VGlTQ0gNCg0KPiAg ICAgICAgQXV0aG9ycyAgICAgICAgIDogTWFsaXNhIFZ1Y2luaWMNCg0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgSm9uYXRoYW4gU2ltb24NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg S3JpcyBQaXN0ZXINCg0KPiAgICAgICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LTZ0aXNjaC1taW5pbWFsLXNlY3VyaXR5LTAxLnR4dA0KDQo+ICAgICAgICAgICAgIFBhZ2VzICAg ICAgICAgICA6IDE3DQoNCj4gICAgICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNy0wMi0w Mg0KDQo+DQoNCj4gQWJzdHJhY3Q6DQoNCj4gICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyB0aGUgbWlu aW1hbCBtZWNoYW5pc21zIHJlcXVpcmVkIHRvIHN1cHBvcnQNCg0KPiAgIHNlY3VyZSBpbml0aWFs IGNvbmZpZ3VyYXRpb24gaW4gYSBkZXZpY2UgYmVpbmcgYWRkZWQgdG8gYSA2VGlTQ0gNCg0KPiAg IG5ldHdvcmsuICBUaGUgZ29hbCBvZiB0aGlzIGNvbmZpZ3VyYXRpb24gaXMgdG8gc2V0IGxpbmst bGF5ZXIga2V5cywNCg0KPiAgIGFuZCB0byBlc3RhYmxpc2ggYSBzZWN1cmUgc2Vzc2lvbiBiZXR3 ZWVuIGVhY2ggam9pbmluZyBub2RlIGFuZCB0aGUNCg0KPiAgIEpDRSB3aG8gbWF5IHVzZSB0aGF0 IHRvIGZ1cnRoZXIgY29uZmlndXJlIHRoZSBqb2luaW5nIGRldmljZS4NCg0KPiAgIEFkZGl0aW9u YWwgc2VjdXJpdHkgYmVoYXZpb3JzIGFuZCBtZWNoYW5pc21zIG1heSBiZSBhZGRlZCBvbiB0b3Ag b2YNCg0KPiAgIHRoaXMgbWluaW1hbCBmcmFtZXdvcmsuDQoNCj4NCg0KPg0KDQo+IFRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KDQo+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtc2VjdXJp dHkvDQoNCj4NCg0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDoNCg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02dGlzY2gtbWlu aW1hbC1zZWN1cml0eS0wMQ0KDQo+DQoNCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNp b24gaXMgYXZhaWxhYmxlIGF0Og0KDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLTZ0aXNjaC1taW5pbWFsLXNlY3VyaXR5LTANCg0KPiAxDQoNCj4NCg0KPg0K DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mDQoNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQo+DQoNCj4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KDQo+IGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCj4NCg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IDZ0aXNjaCBtYWlsaW5nIGxp c3QNCg0KPiA2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4NCg0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaA0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KNnRpc2NoIG1haWxpbmcg bGlzdA0KDQo2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZz4NCg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlzY2gNCg== --_000_5f688af6f901498789032b52843dd044XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZS Ij5IZWxsbyA8L3NwYW4+TWFsacWhYTxzcGFuIGxhbmc9IkZSIj46PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgbm90ZWQgdGhhdCBm b3Igc29tZSByZWFzb24sIHRoZSBhdXRvbWF0ZWQgSUVURiBiaWJ0ZXggZ2VuZXJhdGlvbiBkb2Vz IG5vdCB3b3JrIHdlbGwgd2l0aCB5b3VyIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtdnVjaW5pYy02dGlzY2gtbWluaW1hbC1zZWN1cml0eS9iaWJ0ZXgvIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12dWNpbmljLTZ0aXNjaC1taW5pbWFsLXNlY3Vy aXR5L2JpYnRleC88L2E+IGluIHRoZSBsaW5lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5hdXRob3IgPSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7PHNwYW4gc3R5 bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5tYWxpc2EudnVjaW5p Y0BzdC5jb208L3NwYW4+IGFuZCBKb25hdGhhbiBTaW1vbiBhbmQgS3JpcyBQaXN0ZXJ9LDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIHByb2JsZW0gd2FzIHByZXNlbnQgaW4gdGhl IDAwLCBzbyB3aGF0ZXZlciBtYXJrZG93biBjaGFuZ2VkIGRpZCBub3QgZml4IGl0LiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ucm91YmxlIGlzIHRo YXQgYW4gZW1haWwgYWRkcmVzcyBhcHBlYXJzIGluc3RlYWQgb2YgeW91ciBuYW1lIGFuZCB0aGF0 IGVtYWlsIGFkZHJlc3MgaXMgbm90IGV2ZW4gdGhlIG9uZSBpbiB5b3VyIGRyYWZ0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Mb29raW5nIGF0IHRoZSBwZGYgSSBjYW5ub3Qgc2VlIGFu eXRoaW5nIGFic3VyZC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNjJ2luZyBpZXRm LWFjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGFrZSBjYXJlLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QYXNjYWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDZ0aXNjaCBbbWFpbHRvOjZ0aXNjaC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFsacWhYSBWdWNpbmljPGJyPg0KU2VudDogamV1 ZGkgMiBmw6l2cmllciAyMDE3IDE0OjQyPGJyPg0KVG86IDZ0aXNjaCAmbHQ7NnRpc2NoQGlldGYu b3JnJmd0Ozxicj4NClN1YmplY3Q6IFJlOiBbNnRpc2NoXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LTZ0aXNjaC1taW5pbWFsLXNlY3VyaXR5LTAxLnR4dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+QWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+ Rm9sbG93aW5nIHRoZSBjaGFuZ2UgdG8gbWFya2Rvd24sIHdlIHN1Ym1pdHRlZCBhIHZlcnNpb24g b2YgdGhlIG1pbmltYWwtc2VjdXJpdHkgZHJhZnQgdGhhdCBoYXMgKm5vKiBjb250ZW50IGNoYW5n ZXMsIG9ubHkgc2xpZ2h0IGVkaXRvcmlhbCBmaXhlcy4gVGhpcyB3YXMgbmVjZXNzYXJ5IGluIG9y ZGVyIHRvIGVuc3VyZSB0aGF0IGZ1dHVyZSB2ZXJzaW9ucyBoYXZlIGEgY2xlYW4NCiBkaWZmLiBB IHRoYW5rcyBnb2VzIHRvIE1pY2hhZWwgZm9yIGhpcyBoZWxwIHdpdGggdGhpcyB0cmFuc2l0aW9u LiBXaXRoaW4gdGhlIHNlY3VyaXR5IGRlc2lnbiB0ZWFtLCB3ZSBhcmUgd29ya2luZyBvbiB0aGUg LTAyIHZlcnNpb24gdGhhdCB3aWxsIGluY2x1ZGUgbGF0ZXN0IGRpc2N1c3Npb25zIG9uIG1pbmlt YWwgc2VjdXJpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZSIj5NYWxpxaFhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkZSIj4mZ3Q7IE9uIDAyIEZlYiAyMDE3LCBhdCAxNDozNCwgPGEgaHJlZj0i bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9z cGFuPjwvYT4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsgPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsgQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkZSIj4mZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIElQdjYgb3ZlciB0aGUgVFNDSCBtb2RlIG9mIElFRUUgODAyLjE1LjRlIG9mIHRoZSBJRVRG LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkZSIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkZSIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogTWluaW1hbCBTZWN1cml0eSBGcmFtZXdvcmsgZm9yIDZUaVND SDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkZSIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1 dGhvcnMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBN YWxpc2EgVnVjaW5pYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkZSIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEpvbmF0aGFuIFNpbW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgS3JpcyBQaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBkcmFmdC1pZXRmLTZ0aXNjaC1t aW5pbWFsLXNlY3VyaXR5LTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZSIj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYWdlcyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDE3 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRlIiPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAyMDE3LTAyLTAyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZn dDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRlIiPiZndDsgQWJzdHJhY3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsmbmJzcDsmbmJzcDsgVGhpcyBkcmFm dCBkZXNjcmliZXMgdGhlIG1pbmltYWwgbWVjaGFuaXNtcyByZXF1aXJlZCB0byBzdXBwb3J0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RlIiPiZndDsmbmJzcDsmbmJzcDsgc2VjdXJlIGluaXRpYWwgY29uZmlndXJhdGlvbiBpbiBhIGRl dmljZSBiZWluZyBhZGRlZCB0byBhIDZUaVNDSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZSIj4mZ3Q7Jm5ic3A7Jm5ic3A7IG5ldHdv cmsuJm5ic3A7IFRoZSBnb2FsIG9mIHRoaXMgY29uZmlndXJhdGlvbiBpcyB0byBzZXQgbGluay1s YXllciBrZXlzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkZSIj4mZ3Q7Jm5ic3A7Jm5ic3A7IGFuZCB0byBlc3RhYmxpc2ggYSBzZWN1 cmUgc2Vzc2lvbiBiZXR3ZWVuIGVhY2ggam9pbmluZyBub2RlIGFuZCB0aGU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyZu YnNwOyZuYnNwOyBKQ0Ugd2hvIG1heSB1c2UgdGhhdCB0byBmdXJ0aGVyIGNvbmZpZ3VyZSB0aGUg am9pbmluZyBkZXZpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsmbmJzcDsmbmJzcDsgQWRkaXRpb25hbCBzZWN1cml0 eSBiZWhhdmlvcnMgYW5kIG1lY2hhbmlzbXMgbWF5IGJlIGFkZGVkIG9uIHRvcCBvZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZSIj4m Z3Q7Jm5ic3A7Jm5ic3A7IHRoaXMgbWluaW1hbCBmcmFtZXdvcmsuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsgPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIi PiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRlIiPiZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC1zZWN1cml0eS8iPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtc2VjdXJpdHkvPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJGUiI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2 ZXJzaW9uIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC1zZWN1cml0eS0wMSI+DQo8c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtc2VjdXJpdHktMDE8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkZSIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZSIj4mZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC1zZWN1cml0 eS0wIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02dGlzY2gtbWlu aW1hbC1zZWN1cml0eS0wPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyAxPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsgPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIi PiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRlIiPiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZSIj4mZ3Q7IHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJGUiI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRlIiPiZndDsgPGEgaHJlZj0iZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZSIj4mZ3Q7IDZ0aXNjaCBtYWlsaW5nIGxp c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJGUiI+Jmd0OyA8YSBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+NnRpc2NoQGlldGYub3Jn PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJGUiI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvLzZ0aXNjaCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82 dGlzY2g8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJGUiI+NnRpc2NoIG1haWxpbmcgbGlzdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkZS Ij48YSBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+NnRpc2NoQGlldGYub3JnPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJGUiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82dGlz Y2giPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaDwvc3Bhbj48L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5f688af6f901498789032b52843dd044XCHRCD001ciscocom_-- From nobody Fri Feb 3 01:12:56 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3811294E1; Fri, 3 Feb 2017 01:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.087 X-Spam-Level: X-Spam-Status: No, score=-10.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN83URu3HlL9; Fri, 3 Feb 2017 01:12:52 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B84D12940F; Fri, 3 Feb 2017 01:12:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,328,1477954800"; d="scan'208,217";a="211899781" Received: from unknown (HELO [128.93.85.17]) ([128.93.85.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Feb 2017 10:12:49 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_B1F53764-8D62-47DB-8393-80C150BB3CBC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <5f688af6f901498789032b52843dd044@XCH-RCD-001.cisco.com> Date: Fri, 3 Feb 2017 10:12:48 +0100 Message-Id: <2491DD34-FA41-41AA-807B-BD77731D3EA4@inria.fr> References: <148604244173.29476.7003834767723400058.idtracker@ietfa.amsl.com> <5C48B942-1E87-45CB-9124-24524C041044@inria.fr> <5f688af6f901498789032b52843dd044@XCH-RCD-001.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6tisch <6tisch@ietf.org>, "ietf-action@ietf.org" Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-01.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 09:12:54 -0000 --Apple-Mail=_B1F53764-8D62-47DB-8393-80C150BB3CBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Pascal, Yes, I noted that yesterday and created a ticket at = internet-drafts@ietf.org . I have no = idea how the tool picked up my former email address, especially because = during submission metadata was in order. Hopefully, they will be able to = help. Mali=C5=A1a > On 03 Feb 2017, at 09:44, Pascal Thubert (pthubert) = wrote: >=20 > Hello Mali=C5=A1a: > =20 > I noted that for some reason, the automated IETF bibtex generation = does not work well with your draft. > = https://datatracker.ietf.org/doc/draft-vucinic-6tisch-minimal-security/bib= tex/ = in the line > author =3D {malisa.vucinic@st.com = and Jonathan Simon and Kris Pister}, > =20 > This problem was present in the 00, so whatever markdown changed did = not fix it. =20 > Trouble is that an email address appears instead of your name and that = email address is not even the one in your draft. > =20 > Looking at the pdf I cannot see anything absurd.=20 > =20 > Cc'ing ietf-action. > =20 > Take care, > =20 > Pascal > =20 > =20 > -----Original Message----- > From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Mali=C5=A1a = Vucinic > Sent: jeudi 2 f=C3=A9vrier 2017 14:42 > To: 6tisch <6tisch@ietf.org> > Subject: Re: [6tisch] I-D Action: = draft-ietf-6tisch-minimal-security-01.txt > =20 > All, > =20 > Following the change to markdown, we submitted a version of the = minimal-security draft that has *no* content changes, only slight = editorial fixes. This was necessary in order to ensure that future = versions have a clean diff. A thanks goes to Michael for his help with = this transition. Within the security design team, we are working on the = -02 version that will include latest discussions on minimal security. > =20 > Regards, > Mali=C5=A1a > =20 > > On 02 Feb 2017, at 14:34, internet-drafts@ietf.org = wrote: > >=20 > >=20 > > 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 of the IETF. > >=20 > > Title : Minimal Security Framework for 6TiSCH > > Authors : Malisa Vucinic > > Jonathan Simon > > Kris Pister > > Filename : = draft-ietf-6tisch-minimal-security-01.txt > > Pages : 17 > > Date : 2017-02-02 > >=20 > > Abstract: > > This draft describes the minimal mechanisms required to support > > secure initial configuration in a device being added to a 6TiSCH > > network. The goal of this configuration is to set link-layer = keys, > > and to establish a secure session between each joining node and = the > > JCE who may use that to further configure the joining device. > > Additional security behaviors and mechanisms may be added on top = of > > this minimal framework. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ = > >=20 > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-01 = > >=20 > > A diff from the previous version is available at: > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-minimal-security-0 = = > > 1 > >=20 > >=20 > > 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. > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ = > >=20 > > _______________________________________________ > > 6tisch mailing list > > 6tisch@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch = > =20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch = --Apple-Mail=_B1F53764-8D62-47DB-8393-80C150BB3CBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Pascal,

Yes, I noted that yesterday and created a ticket at internet-drafts@ietf.org. I have no idea how the tool = picked up my former email address, especially because during submission = metadata was in order. Hopefully, they will be able to help.

Mali=C5=A1a

On 03 Feb 2017, at 09:44, Pascal Thubert (pthubert) <pthubert@cisco.com> = wrote:

Hello Mali=C5=A1a:
 
I= noted that for some reason, the automated IETF bibtex generation does = not work well with your draft.
author = =3D            = ;   {malisa.vucinic@st.com and Jonathan Simon and Kris = Pister},
 
This problem was present in the 00, so whatever markdown = changed did not fix = it.           
Trouble = is that an email address appears instead of your name and that email = address is not even the one in your draft.
 
Looking at the pdf I cannot see = anything absurd. 
 
Cc'ing = ietf-action.
 
Take care,
 
Pascal
 
 
-----Original Message-----
From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Mali=C5=A1a = Vucinic
Sent: jeudi 2 f=C3=A9vrier 2017 14:42
To: 6tisch <6tisch@ietf.org>
Subject: Re: [6tisch] = I-D Action: draft-ietf-6tisch-minimal-security-01.txt
 
All,
 
Following = the change to markdown, we submitted a version of the minimal-security = draft that has *no* content changes, only slight editorial fixes. This = was necessary in order to ensure that future versions have a clean diff. = A thanks goes to Michael for his help with this transition. Within the = security design team, we are working on the -02 version that will = include latest discussions on minimal security.
 
Regards,
Mali=C5=A1a
 
> On 02 Feb 2017, at = 14:34, internet-drafts@ietf.org wrote:
> 
> 
> 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 of the IETF.
> 
>        = Title           : = Minimal Security Framework for 6TiSCH
>        = Authors         : Malisa = Vucinic
>          = ;            &= nbsp;   Jonathan Simon
>          = ;            &= nbsp;   Kris Pister
> =             = Filename        : = draft-ietf-6tisch-minimal-security-01.txt
> =             = Pages           : = 17
> =             = Date            : = 2017-02-02
> 
> Abstract:
>   This draft describes the minimal = mechanisms required to support
>   secure initial configuration in a device = being added to a 6TiSCH
>   network.  The goal of this = configuration is to set link-layer keys,
>   and to establish a secure = session between each joining node and the
>   JCE who may use that to further = configure the joining device.
>   Additional security behaviors and mechanisms = may be added on top of
>   this minimal framework.
> 
> 
> The IETF datatracker status page for this = draft is:
> 
> There's also a htmlized version available = at:
> 
> A diff from the previous version is = available at:
> 1
> 
> 
> 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.
> 
> Internet-Drafts are also available by = anonymous FTP at:
> 
> = _______________________________________________
> 6tisch mailing list
 
_______________________________________________
6tisch mailing list

= --Apple-Mail=_B1F53764-8D62-47DB-8393-80C150BB3CBC-- From nobody Fri Feb 3 05:56:02 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA7E1293DA for <6tisch@ietfa.amsl.com>; Fri, 3 Feb 2017 05:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l4fooGBAjok for <6tisch@ietfa.amsl.com>; Fri, 3 Feb 2017 05:55:57 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2917C129D0C for <6tisch@ietf.org>; Fri, 3 Feb 2017 05:55:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,328,1477954800"; d="scan'208,217";a="258736515" Received: from mail-vk0-f49.google.com ([209.85.213.49]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 Feb 2017 14:55:55 +0100 Received: by mail-vk0-f49.google.com with SMTP id r136so13153871vke.1 for <6tisch@ietf.org>; Fri, 03 Feb 2017 05:55:55 -0800 (PST) X-Gm-Message-State: AIkVDXLPdguHQTItGbh4isinndq5w1bW+GAuNYquiPrTi/JK3V+29124GX+kGQvkWan0Zmf2ItozhSSyP55HGw== X-Received: by 10.31.128.78 with SMTP id b75mr6735225vkd.174.1486130154487; Fri, 03 Feb 2017 05:55:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.160.148 with HTTP; Fri, 3 Feb 2017 05:55:34 -0800 (PST) In-Reply-To: References: From: Thomas Watteyne Date: Fri, 3 Feb 2017 14:55:34 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001a1142a404f2ce240547a0a351 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] Agenda, 03 February 2017 interim, 6TiSCH WG X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 13:56:00 -0000 --001a1142a404f2ce240547a0a351 Content-Type: text/plain; charset=UTF-8 reminder, 6TiSCH interim in 65min. On Wed, Feb 1, 2017 at 2:28 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Connection details > > - Date: 7-8am Pacific: http://www.worldtimebuddy.com/ > ?qm=1&lid=100,12,5392171,1850147&h=100&date=2017-02-03&sln=15-16 > > - Webex link: https://cisco.webex.com/ciscosales/j.php?MTID= > mcdbbe3a4e38d97d986b507ec12a1f9b1 > > - Meeting number (access code): 203 224 694 > - Meeting password: sixtus (749887 from phones) > > Agenda > > - Administrivia [2min] > - Approval agenda > - Approval minutes last call > - Status of drafts [Chairs] [5min] > - News from 802.15.12 [Pat] [25min] > - Wrap up ML discussions on 6top [Thomas] [25min] > - AOB [3min] > > As usual, if you wish to add/change stuff please let us know; > > The chairs. > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a1142a404f2ce240547a0a351 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
reminder, 6TiSCH interim in 65min.

On Wed, Feb 1, 2017 at 2:28 PM, Pas= cal Thubert (pthubert) <pthubert@cisco.com> wrote:

Connection details

Agenda=

  • Administrivia [2min]
    • Approval agenda
    • Approval minutes last call
  • Status of drafts [Chairs] [5min]
  • News from 802.15.12 [Pat] [25min]
  • Wrap up ML discussions on 6top [Thomas] [25min]
  • AOB [3min]

As usual, if you wish to add/change stuff please let= us know;

The chairs.

=C2=A0


_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
=
_______________________________________

=
Thomas W= atteyne, PhD
Research Scientist & Innovator, Inria
Sr Networkin= g Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN

______________________= _________________
--001a1142a404f2ce240547a0a351-- From nobody Fri Feb 3 06:49:52 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76559129467 for <6tisch@ietfa.amsl.com>; Fri, 3 Feb 2017 06:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqQ_B3ffFzEB for <6tisch@ietfa.amsl.com>; Fri, 3 Feb 2017 06:49:48 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0FA129454 for <6tisch@ietf.org>; Fri, 3 Feb 2017 06:49:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,329,1477954800"; d="scan'208,217";a="258745408" Received: from mail-ua0-f178.google.com ([209.85.217.178]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 Feb 2017 15:48:37 +0100 Received: by mail-ua0-f178.google.com with SMTP id 96so15109769uaq.3 for <6tisch@ietf.org>; Fri, 03 Feb 2017 06:48:37 -0800 (PST) X-Gm-Message-State: AIkVDXJ/0JLTIzaLoC2EMZUGtclKCh/f9u6dOKkWQM7op76QEMfEkTpqapKedP3uIipWsS8RR3PpKlahVQFn0A== X-Received: by 10.176.85.158 with SMTP id v30mr7311391uaa.82.1486133316637; Fri, 03 Feb 2017 06:48:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.160.148 with HTTP; Fri, 3 Feb 2017 06:48:16 -0800 (PST) In-Reply-To: References: From: Thomas Watteyne Date: Fri, 3 Feb 2017 15:48:16 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Remy Leone Content-Type: multipart/alternative; boundary=f403045ddd066d61c50547a1608c Archived-At: Cc: 6TiSCH mailing list <6tisch@ietf.org> Subject: Re: [6tisch] Comments/questions about 6P draft X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 14:49:50 -0000 --f403045ddd066d61c50547a1608c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Remy, Some answers inline, which porobably overlap Yatch's and Qin's answers. On Thu, Feb 2, 2017 at 2:09 PM, Remy Leone wrote: > Hello, > > I got a bunch of remarks about the 6P draft > https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03 > > *4.1.1. 2-step 6top Transaction* > *4.1.2. 3-step 6top Transaction* > > Maybe it would be nice to add at the end of the workflow that if the > transaction was successful, the schedule generation is incremented to all= ow > inconsistencies detection. > sure, it's a simple fix. > > *4.2.4. 6P Command Identifiers* > > CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard > or both cells that are concerned. > only the cells scheduled by the SF targetted. By defnition soft cells, but that's not the main criteria/ > > *4.2.6. 6P CellOptions* > > In Figure 11, is there is mix-up between line 2 & 3 > TX=3D1, *RX=3D0*, S=3D0 | select the cells scheduled with A and marked as= *RX* > *TX=3D0*, RX=3D1, S=3D0 | select the cells scheduled with A and marked as= *TX* > > and the line 6 & 7? > > *TX=3D1*, RX=3D0, S=3D1 | select the cells scheduled with A and marked as= *RX* > and SHARED > TX=3D0, *RX=3D1*, S=3D1 | select the cells scheduled with A and marked as= *TX* > and SHARED > > TX and RX don't seem to match. > Not an error, Node A's TX cell is node B's RX cell. > > Also, I think it would be useful to define what SHARED means, I fail to > find the definition in this draft. > It's a 802.15.4 TSCH term, > > *4.3.6. Clearing the Schedule* > > I think it would be a good idea to specify whether it's hard cells or sof= t > cells (or both) that are concerned by this. > see above. > > *6. Implementation Status* > > Support for 6P in Wireshark was merged upstream > https://github.com/wireshark/wireshark/commit/ > 8b0e66f22c059533643195ba7571cafe9f006f58 > Therefore there is a need to update the text concerning the Wireshark > dissector. > yep, good point. > > > Best regards > > R=C3=A9my > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --f403045ddd066d61c50547a1608c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Remy,

Some answers inline, which poroba= bly overlap Yatch's and Qin's answers.

On Thu, Feb 2, 2017 at 2:09 PM, Remy Leo= ne <remy.leone@inria.fr> wrote:
Hello,

I got a bunch of remarks= about the 6P draft=C2=A0

4.1.1. 2-step 6top Transaction
4.1.2. 3= -step 6top Transaction

Maybe it would be nice = to add at the end of the workflow that if the transaction was successful, t= he schedule generation is incremented to allow inconsistencies detection.

sure, it's a simple fix.
=C2=A0
4.2.4. 6P Command Identifiers

C= MD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard or= both cells that are concerned.

only the cells scheduled by the SF targetted. By defnition soft cells, but= that's not the main criteria/
=C2=A0

4.2.6. 6P CellOptions=

In Figure 11, is there is mix-up between line 2 & 3
TX= =3D1, RX=3D0, S=3D0 | select the cells scheduled with A and marked a= s RX
TX=3D0, RX=3D1, S=3D0 | select the cells scheduled w= ith A and marked as TX

and the line 6 & 7?

TX= =3D1, RX=3D0, S=3D1 | select the cells scheduled with A and marked as <= b>RX and SHARED=C2=A0
TX=3D0, RX=3D1, S=3D1 | select t= he cells scheduled with A and marked as TX and SHARED

T= X and RX don't seem to match.

Not an error, Node A's TX cell is node B's RX cell.
<= div>=C2=A0
<= br>
Also, I think it would be useful to define what SHARED means,= I fail to find the definition in this draft.

It's a 802.15.4 TSCH term,
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

= 4.3.6. Clearing the Schedule

I think it would = be a good idea to specify whether it's hard cells or soft cells (or bot= h) that are concerned by this.

see above.
=C2=A0

6. Implementation Status
<= div>
Support for 6P in Wireshark was merged upstream
https://github.com/wireshark/wireshark/commit/8b0e66f22c059533643195ba7571cafe9f006f58<= br>
Therefore there is a need to update the text concerning the W= ireshark dissector.

yep, = good point.
=C2=A0


Best regards

R=C3=A9my

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
=
_______________________________________

=
Thomas W= atteyne, PhD
Research Scientist & Innovator, Inria
Sr Networkin= g Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN

______________________= _________________
--f403045ddd066d61c50547a1608c-- From nobody Fri Feb 3 08:52:37 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689EE129696 for <6tisch@ietfa.amsl.com>; Fri, 3 Feb 2017 08:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sEjMcM4Yt6M for <6tisch@ietfa.amsl.com>; Fri, 3 Feb 2017 08:52:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40570129692 for <6tisch@ietf.org>; Fri, 3 Feb 2017 08:52:34 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6280C200A5 for <6tisch@ietf.org>; Fri, 3 Feb 2017 12:13:21 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0C9F4636BB for <6tisch@ietf.org>; Fri, 3 Feb 2017 11:52:33 -0500 (EST) From: Michael Richardson To: 6tisch@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [6tisch] avoiding allocating cells for join traffic X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:52:35 -0000 --=-=-= Content-Type: text/plain Malisa and I, when editing the documents this week came across a concern that we had. It involves the traffic between the Join Proxy (JP), and the Join Registrar/Coordinator (JRC, formerly known as JCE). This is regular traffic, and is would flow through the mesh as would any other traffic. Only the JP and JRC would know it was join traffic, and if the JRC is not-within the LLN (beyond the DODAG root), then the DODAG root wouldn't be able to identify the join traffic. In a smarter-than-minimal network a specific track could be allocated for this traffic. The specific concern I have with minimal is that there could be surges in join traffic (from newly activated pledges, some of which could be malicious). That minimal might react by allocating new cells for the extra traffic, and this might be a bad thing. I can't say that I know what the right behaviour is. Clearly the network should not be allocating cells that it needs for more important things, and I think that 6p can do deny things appropriately. But the intermediate nodes might not recognize the traffic as join traffic, and might allocate anyway. Is there a way we can mark join traffic so that this doesn't happen? Either explicitely (DSCP perhaps?), or implicitely (this cell is join traffic). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAliUtVAACgkQgItw+93Q 3WWemQgAkWFT/WrebYqgevARcqfdlHAIQbiHSkirB4AA9tnCf6EXilo/8QqUtsZh dukM/l0DAmCR6Pqrn6+g/SlhhkT7SqH81w3SOVtDbGUgqn1Jji4lZQlV50qg8U/S Ogn62qK6CxlkeQXBC7uVSsIYvWGk005E31vC0yxiwdnUOSKl4wJh7GyGNDCWb300 I2v+TOnxs/T8UFcF6sm6XnbDNXbuuZfS0IPpO4rnNEHqRFCbRAF1NVGxOWd/9KpA hkSR6taOkdcgMNaOTFD8yJEB+Tf1iYSsuGR4++1abopvGJzFAfO+HmcdBB8SG4uE PwfR2O9kcPiBfO0YYE4AnXkNeEm2qw== =lcKV -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 3 09:50:52 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3F91294AC for <6tisch@ietfa.amsl.com>; Fri, 3 Feb 2017 09:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.719 X-Spam-Level: X-Spam-Status: No, score=-17.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIrd0ma_OKyi for <6tisch@ietfa.amsl.com>; Fri, 3 Feb 2017 09:50:49 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC05212948B for <6tisch@ietf.org>; Fri, 3 Feb 2017 09:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32128; q=dns/txt; s=iport; t=1486144248; x=1487353848; h=from:to:subject:date:message-id:mime-version; bh=fSTX0IQay3whDnNfuXsYd5y7Fkf5bwMEVxCowvZUe5E=; b=HBo6X5EI/fPL4Pd1rb2G8ydlv2J26Gj3Gc4KhrVAZDsbHEtMCMTXF/mb sZeIhriGm/4h6K7jnZQTJoSsbpVIzQ9BKQbd0k813xAlhmawJTqY00Yoh 47KHzJ1/q2Wkbda+1iSoxGZThkWmI8AWEKPQSFXVHbUC1exfj9gX8KPH8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQBnwpRY/5tdJa1DEAoaAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGCb2RhgQkHjVmSDJU7gg0shXaCYD8YAQIBAQEBAQEBYh0LhRcGPwo?= =?us-ascii?q?VARoCHAgBAzwXDwEEGxKJVw4tnXSRbDqDVIdfAQEBAQEBAQMBAQEBAQEBASCGS?= =?us-ascii?q?4YrgVSBFUgugX6DGQWbYwGGZ4sXkQuTCQEfOIFLFYR/HYFhdQEEiA+BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,329,1477958400"; d="scan'208,217";a="380950688" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2017 17:50:47 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v13HolIO014566 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Fri, 3 Feb 2017 17:50:47 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Feb 2017 11:50:46 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 3 Feb 2017 11:50:46 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Minutes, 03 February 2017 interim, 6TiSCH WG Thread-Index: AdJ+Ra+IRsP8BDilTOOGD2XQbQ1QAw== Date: Fri, 3 Feb 2017 17:50:33 +0000 Deferred-Delivery: Fri, 3 Feb 2017 17:50:21 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.226.157] Content-Type: multipart/alternative; boundary="_000_f24b3de742524090b19966410ed26c9cXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] Minutes, 03 February 2017 interim, 6TiSCH WG X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:50:51 -0000 --_000_f24b3de742524090b19966410ed26c9cXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note: timestamps in PDT. Meeting details ________________________________ * Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=3D1&lid=3D100,= 12,5392171,1850147&h=3D100&date=3D2017-02-03&sln=3D15-16 * Meeting Material: https://bitbucket.org/6tisch/meetings/raw/master/17= 0203_webex/slides_170203_webex.ppt * Meeting Recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D= 87775322ae0c4f60953eb2c4de5e6987 * Recording password: hP8duvqy Taking notes (using Etherpad) ________________________________ 1. Xavi Vilajosana Present (alphabetically) ________________________________ 1. Charles Perkins 2. Esteban Municio 3. Georgios Papadopoulos 4. Malisa Vucinic 5. Michael Richardson 6. Pascal Thubert 7. Pat Kinney 8. Qin Wang 9. Rashid Sangi 10. Renzo Navas 11. Sedat Gormus 12. Simon Duquennoy 13. S.V.R. Anand 14. Tero Kivinen 15. Tengfei Chang 16. Thomas Watteyne 17. Xavi Vilajosana 18. Yasuyuki Tanaka Action Items ________________________________ 1. Xavi to clarify the behaviour of the delete cell command Agenda ________________________________ * Administrivia [2min] * Approval agenda * Approval minutes last call * Status of drafts [Chairs] [5min] * News from 802.15.12 [Pat] [25min] * Wrap up ML discussions on 6top [Thomas] [25min] * AOB [3min] Minutes ________________________________ * Administrivia [2min] * Approval agenda Agenda is approved. No issues raised. * Approval minutes last call Last call minutes approved. No issues raised. * Status of drafts [Chairs] [5min] * minimal - to address some mails in the ML asking for K2 -> K1 issu= e. * Action XV: to answer in the ML. * Architecture draft and Tracks text submitted to the ML by Pascal. * 802.15.12 * Pat presents 15.12 * thought to work as an LLC. * High complexity in configuring 15.4 so this raised the need to abs= tract some of the functionalities through this LLC (15.12) * 28 parameters to configure 15.4. We want to allow simple primitive= s to work with the underlying 15.4 * From 802.3 and .11 we learn that using ethertypes or protocol disc= riminators are the way to go. We want to support anything on top of 15.4. * Also fragmentation (as supported by 6lowpan (current and new appro= ach being worked at 6TISCH) and then 15.9 approach * need for management, * Michael Richardson: what management meens in terms of IEEE. * PAT: we had managed objects with snmp, now we think this is also n= eeded and we want to provide objects to be managed * Michael Richardson: you refer to counters and other values that wi= ll be exposed to be consulted with protocols like snmp ... * PAT: yes * Using a multiplexor for L3 interface (PDE) supporting then differe= nt upper layers. * Pascal: How much of the information in the .12 part will be in the= frame? * To be seen after some slides. * The MMI is the multiplexing and fragmentation interface. A new IE = is introduced by 15.9 and this IE will also be used by 15.12 as well. * 6P and 6Lowpan will be a protocol module. * Pascal: we will need to define well the flow. * The architecture is very flexible to support 6P scheduling etc.. * 6lowpan will use the pass throug module unless is using 6P. * Support for ranging and locations. Mechanisms for passive gatherin= g of location as well as active gathering of location. * Devices IE capable vs non-IE capable. * Device discovery -> discover if the device is ULI capable or not. * using security mechanism as a discovery mechanism. If a highre lay= er protocol does not have an Identification mechanism in the first 1-2 octe= ts we can use a well known 802.15.12 start of the datagram. * ULI header in the MAC payload. Using 2B for ULI and 2B for etherty= pe (in examples.) then follows IPHC. * TW: we are putting an IE between the MAC and 6lowpan. THe ULI enab= les us to identify what follows. What do we gain? -PAT: we gain protocol di= scriminator. -Tero: even if you have your own implementation and you do not= want to run something else in your device, this ULI approch will enable us= to discriminate if other devices are using the same protocol or are implem= enting different versions. This will help your devices to filter out other = devices running different protocols with the same radio technology. * Also this puts this procotol inline with the IEEE architecture (wi= th protocol discriminator). * Wrap up ML discussions on 6top [Thomas] [25min] * Editors worked in the draft. * most of the issues addressed. * added section about relocation * clarify why numcells in delete. * Propose to reorder sections * status -> count * missing details about IANA. Reference to Tero's drafts as well. * * AOB [3min] * no AOB. --_000_f24b3de742524090b19966410ed26c9cXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Note: timestamps in PDT.

Meeting details


Taking notes (using Etherpad)


  1. Xavi Vilajosana

Present (alphabetically)


  1. Charles Perkins
  2. Esteban Municio
  3. Georgios Papadopoulos
  4. Malisa Vucinic
  5. Michael Richardson
  6. Pascal Thubert
  7. Pat Kinney
  8. Qin Wang
  9. Rashid Sangi
  10. Renzo Navas
  11. Sedat Gormus
  12. Simon Duquennoy
  13. S.V.R. Anand
  14. Tero Kivinen
  15. Tengfei Chang
  16. Thomas Watteyne
  17. Xavi Vilajosana
  18. Yasuyuki Tanaka

Action Items


  1. Xavi to clarify the behaviour of the delete cell command
  2. Agenda


    • Administrivia [2min]
      • Approval agenda
      • Approval minutes last call
    • Status of drafts [Chairs] [5min]
    • News from 802.15.12 [Pat] [25min]
    • Wrap up ML discussions on 6top [Thomas] [25min]
    • AOB [3min]

    Minutes


    • Administrivia [2min]
      • Approval agenda

    Agenda is approved. No issues raised.<= /o:p>

      • Approval minutes last call

    Last call minutes approved. No issues raise= d.

    • Status of drafts [Chairs] [5min]
      • minimal - to address some mails in the ML asking for K2 -> K1 issue.
        • Action XV: to answer in the ML.
      • Architecture draft and Tracks text submitted to the ML by Pascal.

    <= span style=3D"mso-list:Ignore">·         802.15.12

      • Pat presents 15.12
      • thought to work as an LLC.
      • 28 parameters to configure 15.4. We want to allow simple primitives to work= with the underlying 15.4
      • >From 802.3 and .11 we learn that using ethertypes or protocol discriminator= s are the way to go. We want to support anything on top of 15.4.
      • Also fragmentation (as supported by 6lowpan (current and new approach being= worked at 6TISCH) and then 15.9 approach
      • need for management,
      • Michael Richardson: what management meens in terms of IEEE.
      • =
      • PAT: we had managed objects with snmp, now we think this is also needed and= we want to provide objects to be managed
      • Michael Richardson: you refer to counters and other values that will be exp= osed to be consulted with protocols like snmp ...
      • PAT: yes
      • Using a multiplexor for L3 interface (PDE) supporting then different upper = layers.
      • Pascal: How much of the information in the .12 part will be in the frame? <= o:p>
      • To be seen after some slides.
      • The MMI is the multiplexing and fragmentation interface. A new IE is introd= uced by 15.9 and this IE will also be used by 15.12 as well.
      • 6P and 6Lowpan will be a protocol module.
      • Pascal: we will need to define well the flow.
      • The architecture is very flexible to support 6P scheduling etc..=
      • 6lowpan will use the pass throug module unless is using 6P.
      • =
      • Support for ranging and locations. Mechanisms for passive gathering of loca= tion as well as active gathering of location.
      • Devices IE capable vs non-IE capable. <= /li>
      • Device discovery -> discover if the device is ULI capable or not. <= /o:p>
      • using security mechanism as a discovery mechanism. If a highre layer protoc= ol does not have an Identification mechanism in the first 1-2 octets we can= use a well known 802.15.12 start of the datagram.
      • ULI header in the MAC payload. Using 2B for ULI and 2B for ethertype (in ex= amples.) then follows IPHC.
      • Also this puts this procotol inline with the IEEE architecture (with protoc= ol discriminator).

    <= span style=3D"mso-list:Ignore">·         Wrap up ML discussions on 6top [Thomas] [25m= in]

      • Editors worked in the draft.
      • most of the issues addressed.
      • added section about relocation
      • clarify why numcells in delete.
      • Propose to reorder sections
      • status -> count
      • missing details about IANA. Reference to Tero's drafts as well.<= /li>
      •  
    • AOB [3min]
      • no AOB.

     

--_000_f24b3de742524090b19966410ed26c9cXCHRCD001ciscocom_-- From nobody Sun Feb 5 23:57:39 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448E312949B for <6tisch@ietfa.amsl.com>; Sun, 5 Feb 2017 23:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w9CrrVsXRpG for <6tisch@ietfa.amsl.com>; Sun, 5 Feb 2017 23:57:34 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D282129565 for <6tisch@ietf.org>; Sun, 5 Feb 2017 23:57:33 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id l66so60017630ioi.1 for <6tisch@ietf.org>; Sun, 05 Feb 2017 23:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O52aVDRPgBBfVMT2kv6OoVbK0JSTIk8d2AV0WI1jISw=; b=S9WidvOi5/Q55yWH42VwmS+zqJp6wYcW027y9zw/X0d8lmv9NnbnUAzUhXfju8YMxB RZ1pKyl2TpFPLuAGdsHY9Y6AVCImWVTttrTjayNfqGeEIHk3ewtVRiEV9Hl/ACHwXM5b eNZsBDtyxegSzxEJIkTvUhVIKVYFW7FxX+aDw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O52aVDRPgBBfVMT2kv6OoVbK0JSTIk8d2AV0WI1jISw=; b=LtGxMG5W00EJU++1Y1NcVRlTiuH6dvgvr54oRc4veKa7Owzo762rCAwyWv/NHdUCsJ C9DWVgFr8s+vJraX5Vl0ysv9mur+u9RZTyeiRS/D83YIuRHXVSjnG4OqzXjIyTwqy158 t3l4KMUIaTlMgs8WqDN0ZOr+/jEZtrc+Q5mmVebEpu5HW+Hp4YHGZxfwOTAa8GhXnDJj oTRpIugVXbHzd5q+bmoZhddJ3RG9TFlXVqr9QaRy8Bmbfw3YcJm1s7/t7DXwaAazLM48 auSkWJ4fKZVGvCHw+6uL2rMVQ0+xjum0jsRSoY6D3QAkKrzH73PuRJMZ8f0g1HXDaYad Nqog== X-Gm-Message-State: AMke39lq5TIZyALnFAYuA+ko8S8ivovEVomCkS+h5VI7vLguba0eIe+FNLzVSd8ytJTwT6pSafz6EWFDYxr/Vn9s X-Received: by 10.107.1.3 with SMTP id 3mr5617059iob.12.1486367853166; Sun, 05 Feb 2017 23:57:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.46.13 with HTTP; Sun, 5 Feb 2017 23:57:32 -0800 (PST) In-Reply-To: <856404028.195497.1485371144981.JavaMail.root@canet.uoc.es> References: <249879994.875357.1485333434749.JavaMail.root@vilafranca.uoc.es> <856404028.195497.1485371144981.JavaMail.root@canet.uoc.es> From: Xavi Vilajosana Guillen Date: Mon, 6 Feb 2017 08:57:32 +0100 Message-ID: To: Qin Wang Content-Type: multipart/alternative; boundary=001a11394e2ce4d1190547d7fb58 Archived-At: Cc: tisch <6tisch@ietf.org> Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-19.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 07:57:37 -0000 --001a11394e2ce4d1190547d7fb58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Qin, thanks so much for your detailed review and sorry for the delay in our answer. Find inline our comments. 2017-01-25 20:04 GMT+01:00 Qin Wang : > 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 replace KL. > > As we discussed during the last interim meeting we mean K2 here. > (2) In section 8 there is a discussion about "the impact these fake EBs > can have, depending on what key(s) are pre-provisioned". I think that > case 1 (K1 and K2 are pre-provisioned) and case 2 (K1 is pre-provisioned) > have same problem with fake EBs as case 3 (neither K1 nor K2 is > pre-provisioned) in term of security. Attacker can make fake EBs with the > pre-provisioned K1, because K1 is very easy to get. But, if other network= s > instead of attackers are our concern, I will agree that a node has more > chance to join in correct network in case 1 and case 2. > > The assumption is that the attacker does not know the keys. I think the text is correct here as well. kind regards, Xavi > > On Wednesday, January 25, 2017 3:39 AM, Xavi Vilajosana Guillen < > xvilajosana@uoc.edu> wrote: > > > Dear all, > > we have submitted a new version of minimal addressing the last comments > received during the call last Friday. Main changes affect the security > section where Tero's comments have been taken into consideration. > > thanks everybody who contributed and kind regards, > Xavi > > > ---------- Forwarded message ---------- > From: > Date: 2017-01-25 9:36 GMT+01:00 > Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-19.txt > To: i-d-announce@ietf.org > Cc: 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.4= e > of the IETF. > > Title : Minimal 6TiSCH Configuration > Authors : Xavier Vilajosana > Kris Pister > Thomas Watteyne > Filename : draft-ietf-6tisch-minimal-19. txt > Pages : 26 > Date : 2017-01-25 > > Abstract: > This document describes a minimal mode of operation for a 6TiSCH > Network. A minimal mode of operation is a baseline set of protocols, > recommended configurations and modes of operation sufficient to > enable a 6TiSCH functional network. 6TiSCH provides IPv6 > connectivity over a Time Synchronized Channel Hopping (TSCH) mesh > composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a > collection of protocols with the respective configurations, including > the 6LoWPAN framework, enabling interoperable IPv6 connectivity over > IEEE Std 802.15.4 TSCH. This minimal configuration provides the > necessary bandwidth for network and security bootstrap, and defines > the proper link between the IETF protocols that interface to IEEE Std > 802.15.4 TSCH. This minimal mode of operation should be implemented > by all 6TiSCH compliant devices. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/ doc/draft-ietf-6tisch-minimal/ > > > There's also a htmlized version available at: > https://tools.ietf.org/html/ draft-ietf-6tisch-minimal-19 > > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff? url2=3Ddraft-ietf-6tisch- minimal-19 > > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet- drafts/ > > ______________________________ _________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/ listinfo/6tisch > > > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3)Professor* > (+34) 646 633 681 <+34%20646%2063%2036%2081> > xvilajosana@uoc.edu > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > 08860 Castelldefels (Barcelona). Catalonia. Spain > [image: Universitat Oberta de Catalunya] > =C2=AD > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --001a11394e2ce4d1190547d7fb58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Qin,

thanks so much for your detai= led review and sorry for the delay in our answer. Find inline our comments.=

2017-01-25 = 20:04 GMT+01:00 Qin Wang <qinwang6top@yahoo.com>:
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 replace KL.

As we discussed during the last interi= m meeting we mean K2 here.
=C2=A0
(2) In section 8 there is a = discussion about "the impact these fake EBs can= have, depending on what key(s) are pre-provisioned&= quot;. I think that case 1 (K1 and K2 are pre-provisioned) and case = 2 (K1 is pre-provisioned) have same problem with fake EBs as case 3 (neithe= r K1 nor K2 is pre-provisioned) in term of security. Attacker can make fake= EBs with the pre-provisioned K1, because K1 is very easy to get. But, if o= ther networks instead of attackers are our concern, I will agree that a nod= e has more chance to join in correct network in case 1 and case 2.

The assumption is that the attacker does not know the keys. I thi= nk the text is correct here as well.

kind= regards,
Xavi
=C2=A0
On Wednesday, January 25, 2017 3:39 AM, Xavi Vi= lajosana Guillen <xvilajosana@uoc.edu> wrote:


Dear all,

we have s= ubmitted a new version of minimal addressing the last comments received dur= ing the call last Friday. Main changes affect the security section where Te= ro's comments have been taken into consideration.

<= div>thanks everybody who contributed and kind regards,
Xavi
=


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2017-01= -25 9:36 GMT+01:00
Subject: [6tisch] I-D Action: draft-ietf-6tisch-minim= al-19.txt
To: i-d-announce@ietf.org
Cc: 6tisch@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e = of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Minimal 6TiSCH Configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Xavi= er Vilajosana
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kris Pister
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Thomas Watteyne
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6tisch-minimal-19. txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 26
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-25

Abstract:
=C2=A0 =C2=A0This document describes a minimal mode of operation for a 6TiS= CH
=C2=A0 =C2=A0Network.=C2=A0 A minimal mode of operation is a baseline set o= f protocols,
=C2=A0 =C2=A0recommended configurations and modes of operation sufficient t= o
=C2=A0 =C2=A0enable a 6TiSCH functional network.=C2=A0 6TiSCH provides IPv6=
=C2=A0 =C2=A0connectivity over a Time Synchronized Channel Hopping (TSCH) m= esh
=C2=A0 =C2=A0composed of IEEE Std 802.15.4 TSCH links.=C2=A0 This minimal m= ode uses a
=C2=A0 =C2=A0collection of protocols with the respective configurations, in= cluding
=C2=A0 =C2=A0the 6LoWPAN framework, enabling interoperable IPv6 connectivit= y over
=C2=A0 =C2=A0IEEE Std 802.15.4 TSCH.=C2=A0 This minimal configuration provi= des the
=C2=A0 =C2=A0necessary bandwidth for network and security bootstrap, and de= fines
=C2=A0 =C2=A0the proper link between the IETF protocols that interface to I= EEE Std
=C2=A0 =C2=A0802.15.4 TSCH.=C2=A0 This minimal mode of operation should be = implemented
=C2=A0 =C2=A0by all 6TiSCH compliant devices.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/ doc/draft-iet= f-6tisch-minimal/

There's also a htmlized version available at:
https://tools.ietf.org/html/ draft-ietf-6tisch= -minimal-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff? url2=3Dd= raft-ietf-6tisch- minimal-19


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet- drafts/

______________________________ _________________
6tisch mailing list
6tisc= h@ietf.org
https://www.ietf.org/mailman/ listinfo/6tisch



--
=
= Dr. Xavier Vilajosana
Wireless N= etworks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
xvilajosana@= uoc.edu
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la T= ecnologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelld= efels (Barcelona). Catalonia. Spain
3D"Universitat=C2=A0=C2=A0
=C2=AD

_______________________________________________<= br>6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisc= h



_= ______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
Dr. Xavier Vilajosana
Wireless Networks Lab
Intern= et Interdisciplinary Institute (IN3)
Professor

(+34) 646 633 681<= br>xvilajosana@uoc.edu
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia=C2=A0<= br>Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona= ). Catalonia. Spain
<= div dir=3D"ltr">3D"Universitat=C2=A0=C2=A0
<= /font>
=C2=AD
--001a11394e2ce4d1190547d7fb58-- From nobody Mon Feb 6 00:52:14 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6A2129CBA for <6tisch@ietfa.amsl.com>; Mon, 6 Feb 2017 00:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEdTCetlgx3Z for <6tisch@ietfa.amsl.com>; Mon, 6 Feb 2017 00:52:09 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868B6129CB9 for <6tisch@ietf.org>; Mon, 6 Feb 2017 00:52:09 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id r185so52607007ita.0 for <6tisch@ietf.org>; Mon, 06 Feb 2017 00:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K3V0Oa7CmLM2uTBdOYHTaiSoI18vvHs1v4eBg1SOU8k=; b=NBzfMwBoywqd3JgQCW7yG4KhsO2+Ot1DOiS2tXNMT2MDN7dOMSS8gP/fYakV4BKh2/ Ia07X5xEFu+qpAibbc0YhVWfqCvFw81BnYx6a39LDgTP6npgWTedUS6OjIbQqUsQM6YA qXPyNXNbMzfe/OlBFWnPZvlIk7Wb4exGDkF+o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K3V0Oa7CmLM2uTBdOYHTaiSoI18vvHs1v4eBg1SOU8k=; b=TzCg2ktIS7lHpYv670Yd1DRSN+k0lsUKrGB+hXUZ0C0PkmsEduiYNePPF40fFagSGn EXZQa21KPM1WvfYRe3pEPVFEJaaIjbde+gIb8wiutavwSY8Cdl68zcTVRwxpu5zOpq6J SYGZPkgvm4O3E+P2nNKOE6Okorq/yVm0YTqV2TbGQSV6MXvgLkA3Cuvaj0c/JdxF4OVv fo8mByQ2jJjfCNpM1MzsAlgA8g19oK7BhhJ6aMomXsFlyvGSDx7pNfmSrZmFc3Rl7lt5 7WhOUiCGDFxX1M5cr3gzmdnzwxmKU20RjkEc4GZId+0khV4yI/aySwn8D2K+fz4b5gxe 2DJg== X-Gm-Message-State: AIkVDXLB85nzsKvvZStSqk7G1EFI0Nylretj4KWYipMaQwoD0lWrIJvZCVnmT2si9bfm4J/oiB9CVSoZJyrI3XBD X-Received: by 10.36.225.195 with SMTP id n186mr6196045ith.35.1486371128699; Mon, 06 Feb 2017 00:52:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.46.13 with HTTP; Mon, 6 Feb 2017 00:52:08 -0800 (PST) In-Reply-To: <2001269132.160884.1486140796042.JavaMail.root@llavaneres.uoc.es> References: <2001269132.160884.1486140796042.JavaMail.root@llavaneres.uoc.es> From: Xavi Vilajosana Guillen Date: Mon, 6 Feb 2017 09:52:08 +0100 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=94eb2c19d67621abbf0547d8bf9b Archived-At: Cc: tisch <6tisch@ietf.org> Subject: Re: [6tisch] avoiding allocating cells for join traffic X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 08:52:13 -0000 --94eb2c19d67621abbf0547d8bf9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael, when you say minimal, do you refer to the minimal configuration or the minimal security? I understand it in the following way. 1) a mesh network is formed and all nodes that already joined the network run minimal + 6P + some SF (e.g SF0). This guarantees that any node already joined can relay traffic. Nodes react allocating more cells if they detect and increment of cell usage. 2) a joining node learns the minimal schedule from the EB and then starts the joining process through that minimal slot. Until it has not been allocated the security keys it cannot start 6P to allocate more cells. 3) Your point is that a malicious node can start to do join requests and cause 6P to allocate more cells in the schedule in the intermediate nodes in the network, introducing churn. Is this your concern? Could't we protect this from the JP? X 2017-02-03 17:52 GMT+01:00 Michael Richardson : > > Malisa and I, when editing the documents this week came across a concern > that we had. It involves the traffic between the Join Proxy (JP), and th= e > Join Registrar/Coordinator (JRC, formerly known as JCE). > > This is regular traffic, and is would flow through the mesh as would any > other traffic. Only the JP and JRC would know it was join traffic, and > if the JRC is not-within the LLN (beyond the DODAG root), then the DODAG > root wouldn't be able to identify the join traffic. In a > smarter-than-minimal network a specific track could be allocated for this > traffic. > > The specific concern I have with minimal is that there could be surges in > join traffic (from newly activated pledges, some of which could be > malicious). That minimal might react by allocating new cells for the ext= ra > traffic, and this might be a bad thing. > > I can't say that I know what the right behaviour is. Clearly the network > should not be allocating cells that it needs for more important things, > and I think that 6p can do deny things appropriately. But the intermedia= te > nodes might not recognize the traffic as join traffic, and might allocate > anyway. > Is there a way we can mark join traffic so that this doesn't happen? > Either explicitely (DSCP perhaps?), or implicitely (this cell is join > traffic). > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --94eb2c19d67621abbf0547d8bf9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,


when you say= minimal, do you refer to the minimal configuration or the minimal security= ?

I understand it in the following way.
<= div>
1) a mesh network is formed and all nodes that already j= oined the network run minimal + 6P + some SF (e.g SF0). This guarantees tha= t any node already joined can relay traffic.=C2=A0 Nodes react allocating m= ore cells if they detect and increment of cell usage.
2) a joinin= g node learns the minimal schedule from the EB and then starts the joining = process through that minimal slot. Until it has not been allocated the secu= rity keys it cannot start 6P to allocate more cells.=C2=A0
3) You= r point is that a malicious node can start to do join requests and cause 6P= to allocate more cells in the schedule in the intermediate nodes in the ne= twork, introducing churn. Is this your concern?

Co= uld't we protect this from the JP?=C2=A0
X


2017-02-0= 3 17:52 GMT+01:00 Michael Richardson <mcr+ietf@sandelman.ca>:

Malisa and I, when editing the documents this week came across a concern that we had.=C2=A0 It involves the traffic between the Join Proxy (JP), and= the
Join Registrar/Coordinator (JRC, formerly known as JCE).

This is regular traffic, and is would flow through the mesh as would any other traffic.=C2=A0 Only the JP and JRC would know it was join traffic, an= d
if the JRC is not-within the LLN (beyond the DODAG root), then the DODAG root wouldn't be able to identify the join traffic.=C2=A0 In a
smarter-than-minimal network a specific track could be allocated for this traffic.

The specific concern I have with minimal is that there could be surges in join traffic (from newly activated pledges, some of which could be
malicious).=C2=A0 That minimal might react by allocating new cells for the = extra
traffic, and this might be a bad thing.

I can't say that I know what the right behaviour is.=C2=A0 Clearly the = network
should not be allocating cells that it needs for more important things,
and I think that 6p can do deny things appropriately.=C2=A0 But the interme= diate
nodes might not recognize the traffic as join traffic, and might allocate anyway.
Is there a way we can mark join traffic so that this doesn't happen? Either explicitely (DSCP perhaps?), or implicitely (this cell is join traff= ic).

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
=
3D"Universitat=C2=A0=C2=A0=
=C2=AD
--94eb2c19d67621abbf0547d8bf9b-- From nobody Tue Feb 7 01:47:11 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A701295D1 for <6tisch@ietfa.amsl.com>; Tue, 7 Feb 2017 01:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FSL_HELO_BARE_IP_2=1.498, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA4DfKBsEoIH for <6tisch@ietfa.amsl.com>; Tue, 7 Feb 2017 01:47:08 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6412129451 for <6tisch@ietf.org>; Tue, 7 Feb 2017 01:47:08 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id 19so8952672pfo.3 for <6tisch@ietf.org>; Tue, 07 Feb 2017 01:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:references:to:cc:mime-version :content-transfer-encoding; bh=ejTnKzi3hXmca8l2X5lvC013VkHMeQ3spguToA9svpg=; b=qQuUWzgzVKqLJgLKCOKzw0BM4zDnvrggUYfvWUjZb3taS2m5zD67vEe4Hwa6n3H7Re nHnG4QUtL+5dk8gS3zwe8jt9LIa34Yed5XN4Becp+ZPgvq+ExmlnduKtnMTjVk2K5R4N hg+EqPnplq7etXqVVhy4TnaDDXVLp2O4pfzBv8nL/G/OY/0+trDSNpdxGelbJxwrOp55 nfzkKJWorOLOD+aK4egiuj+c2bAxWRb/P3d2q5uWhOKLgQo29pJyxqp3QUybekHULylf JzhFeg2k1fjK9LMeerBOkyqgEj2asKG2AYq+Pedozks9ROFNLv7PUnQwADc84mIPGmmi LGLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:references:to:cc :mime-version:content-transfer-encoding; bh=ejTnKzi3hXmca8l2X5lvC013VkHMeQ3spguToA9svpg=; b=P1PtJUNelu/4reVxSt8tKH6iXVf57xdAbF214/yTfRh8J+sj41Ko7IaOhLpW2h443N YA8pgbkQg37CWLVs+8OTpysq22k4hHPp6+P6o4vvDBgmr5jpGW2YJsfIUZj8rFIWkE/4 70YP00c8Ks91MkDJRWjvAwMU1KD0fbUqI9rTGXF1UT0IWwWbssgQZvtlSxWm63KWowUC rdj8rOghiJzBYUmRh6L5ZKqjwJ4O89QygUAhl7NMe/os4CkAmnvyUIv73XNNMXgimNns 3QfgSzjnfh8qs+CX5s0wt+2Dxh3EIfL7GT8/W3qcYjZ8d+3tIskJ+Q8A0Hjbd/GdU6lQ mJkw== X-Gm-Message-State: AIkVDXJptFtGsT4s8yX76zNEtxCfCt4HJrZGKXEyp27hnhZvqcQ6EQm35O1m/dVc9OPNRQ== X-Received: by 10.98.13.203 with SMTP id 72mr18584251pfn.64.1486460828299; Tue, 07 Feb 2017 01:47:08 -0800 (PST) Received: from 192.168.0.102 ([103.251.128.68]) by smtp.gmail.com with ESMTPSA id a1sm9620744pgc.14.2017.02.07.01.47.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 01:47:07 -0800 (PST) From: Jiliang Wang Message-ID: <067B6893-5591-4F16-A2FE-22D0590FF6A2@gmail.com> Date: Tue, 7 Feb 2017 17:47:05 +0800 References: <249879994.875357.1485333434749.JavaMail.root@vilafranca.uoc.es> To: Suresh Krishnan X-Mailer: NetEase iOS Mail 4.15.5.931 [iPhone 6 iOS10.2.1] MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tisch <6tisch@ietf.org>, Xavi Vilajosana Guillen Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-19.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 09:47:10 -0000
=20 =20
I also have several questions as listed below:

1. How to set the length (in time) of each cell. Thi= s should be related to the number of retransmissions, i.e., for a higher = number of retransmissions, the cell length should accordingly be set long= er=3F This may incur some efficiency issue=3F

2.= What is default channelslot offset of EB, on which a new node unjoined n= ode should listen=3F

3. If neither K1 nor K2 is = pre-provisioned, a joining node uses the secExempt mechanism (IEEE Std 80= 2.15.4, Section 9.2.4) to process all correctly-formatted EBs.
= Here I found no secExempt mechanism in Section 9.2.4 in IEEE Std 802.15.4=

4. =E2=80=9CMany mechanisms exist for discrimin= ation between networks, the details of which are out of scope.=E2=80=9D A= ccording to current field setting, it is difficult to differentiate diffe= rent networks. Does it mean EB contains other field that can be used for = this purpose=3F

Best,
Jiliang Wa= ng 
School of software, Tsinghua University 

On 01/26/2017 06:30, Suresh Krishnan wrote:
Hi Xavi,
 Thanks for addressing the reviews. I have placed this version = on the =46eb 16 2017 telechat so Tero, Ralph and Brian will have a chance= to chime in by then.

Regards
Suresh

On 1/25/17, 3:39 AM, =226tisch on behalf of Xavi Vilajosana Guillen=22= <6tisch-bounces=40ietf.org on behalf of xvilajosana=40uoc.edu> wro= te:

   Dear all,
   
   
   we have submitted a new version of minimal address= ing the last comments received during the call last =46riday. Main change= s affect the security section where Tero's comments have been taken into = consideration.
   
   
   thanks everybody who contributed and kind regards,=
   Xavi
   
   
   
   ---------- =46orwarded message ----------
   =46rom: <internet-drafts=40ietf.org>
   Date: 2017-01-25 9:36 GMT+01:00
   Subject: =5B6tisch=5D I-D Action: draft-ietf-6tisc= h-minimal-19.txt
   To: i-d-announce=40ietf.org
   Cc: 6tisch=40ietf.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 TSC= H mode of IEEE 802.15.4e of the IET=46.
   
           Ti= tle           : Minimal= 6TiSCH Configuration
           Au= thors         : Xavier Vilajosana=
           &n= bsp;           &nb= sp;     Kris Pister
           &n= bsp;           &nb= sp;     Thomas Watteyne
           =46= ilename        : draft-ietf-6tisch-min= imal-19.txt
           Pa= ges           : 26
           Da= te            : 20= 17-01-25
   
   Abstract:
      This document describes a minima= l mode of operation for a 6TiSCH
      Network.  A minimal mode of= operation is a baseline set of protocols,
      recommended configurations and m= odes of operation sufficient to
      enable a 6TiSCH functional netwo= rk.  6TiSCH provides IPv6
      connectivity over a Time Synchro= nized Channel Hopping (TSCH) mesh
      composed of IEEE Std 802.15.4 TS= CH links.  This minimal mode uses a
      collection of protocols with the= respective configurations, including
      the 6LoWPAN framework, enabling = interoperable IPv6 connectivity over
      IEEE Std 802.15.4 TSCH.  Th= is minimal configuration provides the
      necessary bandwidth for network = and security bootstrap, and defines
      the proper link between the IET=46= protocols that interface to IEEE Std
      802.15.4 TSCH.  This minima= l mode of operation should be implemented
      by all 6TiSCH compliant devices.=
   
   
   The IET=46 datatracker status page for this draft = is:
   https://datatracker.ietf.org/doc/draft-ietf-6tisch= -minimal/
   
   There's also a htmlized version available at:
   https://tools.ietf.org/html/draft-ietf-6tisch-mini= mal-19
   
   A diff from the previous version is available at:
   https://www.ietf.org/rfcdiff=3Furl2=3Ddraft-ietf-6= tisch-minimal-19
   
   
   Please note that it may take a couple of minutes f= rom the time of submission
   until the htmlized version and diff are available = at =20
   tools.ietf.org <http://tools.ietf.org>.
   
   Internet-Drafts are also available by anonymous =46= TP at:
   ftp://ftp.ietf.org/internet-drafts/
   
   =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F
   6tisch mailing list
   6tisch=40ietf.org
   https://www.ietf.org/mailman/listinfo/6tisch
   
   
   
   
   
   -- =20
   Dr. Xavier Vilajosana
   Wireless Networks Lab
   Internet Interdisciplinary Institute (IN3)
   Professor
   (+34) 646 633 681
   xvilajosana=40uoc.edu <mailto:usuari=40uoc.edu&= gt;
   http://xvilajosana.org
   http://wine.rdi.uoc.edu
   Parc Mediterrani de la Tecnologia =20
   Av Carl =46riedrich Gauss 5, B3 Building
   08860 Castelldefels (Barcelona). Catalonia. Spain
     
   
   
   
   =C2=AD
   
   
   
   
   
   
   
   
   
   
   

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
6tisch mailing list
6tisch=40ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
=20 =20 =20 From nobody Tue Feb 7 06:20:20 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B351129C5A for <6tisch@ietfa.amsl.com>; Tue, 7 Feb 2017 06:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvI7NV7PQbYE for <6tisch@ietfa.amsl.com>; Tue, 7 Feb 2017 06:20:17 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61DE129C57 for <6tisch@ietf.org>; Tue, 7 Feb 2017 06:20:15 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v17EK9tT013870 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Feb 2017 16:20:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v17EK8H3014195; Tue, 7 Feb 2017 16:20:08 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22681.55192.494061.861445@fireball.acr.fi> Date: Tue, 7 Feb 2017 16:20:08 +0200 From: Tero Kivinen To: Jiliang Wang In-Reply-To: <067B6893-5591-4F16-A2FE-22D0590FF6A2@gmail.com> References: <249879994.875357.1485333434749.JavaMail.root@vilafranca.uoc.es> <067B6893-5591-4F16-A2FE-22D0590FF6A2@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 14 min Archived-At: Cc: tisch <6tisch@ietf.org>, Suresh Krishnan , Xavi Vilajosana Guillen Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-19.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 14:20:20 -0000 Jiliang Wang writes: > I also have several questions as listed below: >=20 > 1. How to set the length (in time) of each cell. This should be relat= ed to the > number of retransmissions, i.e., for a higher number of retransmissio= ns, the > cell length should accordingly be set longer=3F This may incur some e= fficiency > issue=3F No. Each cell contains exactly on transmitted frame, and the ack related to it. If there is needs for retransmissions they will be done on the later cell, i.e., the transmitter delays sending until there is cell to the same recipient, and also if this is shared cell, it will also use backoff alcorithm so it will not use the next shared cell, but skip some of them etc. For if the next cell is dedicated link, then it will use it for retransmission. See section 6.2.5.3 TSCH CSMA-CA retransmission algorithm in 802.15.4-2015, especially figure 6-6 center part, which covers the TSCH retransmissions which are not priority access. There is step "Delay for random (2^BE - 1) shared links or until dedicated link" there which will cause the delay. The Timeslot length is set by sending EB with TSCH Timeslot IE having different value for macTsTimeslotLength. > 2. What is default channelslot offset of EB, on which a new node > unjoined node should listen=3F It is what is sent in the TSCH Slotframe and Link IE of the EB, and the section 4 recommends that slotOffset is set to 0x0000, and chOffset is set to 0x0000. > 3. If neither K1 nor K2 is pre-provisioned, a joining node uses the s= ecExempt > mechanism (IEEE Std 802.15.4, Section 9.2.4) to process all > correctly-formatted EBs. > Here I found no secExempt mechanism in Section 9.2.4 in IEEE Std 802.= 15.4 IEEE Std 802.15.4-2015 section 9.2.4 step f) will check for secExempt. Note, that this section has changed since 802.15.4-2011 and earlier versions of the 802.15.4, so you need to get the 802.15.4-2015 for the section numbers to match. The actual functionality was there in earlier versions also, but there were some mistakes in the state machine, and it was harder to read. Note, that 802.15.4-2015 is available for free from the IEEE Get program, i.e. go to the http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf to get it. > 4. =E2=80=9CMany mechanisms exist for discrimination between networks= , the details of > which are out of scope.=E2=80=9D According to current field setting, = it is difficult > to differentiate different networks. Does it mean EB contains other f= ield that > can be used for this purpose=3F There is ongoing work to allocate IE for IETF, and that IE could be used to provide for example the DAG root or something similar in the EB, which would allow finding the proper network during the joining process, especially if you have been part of the network before. --=20 kivinen@iki.fi From nobody Wed Feb 8 01:10:25 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0D412711D for <6tisch@ietfa.amsl.com>; Wed, 8 Feb 2017 01:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLVcKctR2V0u for <6tisch@ietfa.amsl.com>; Wed, 8 Feb 2017 01:10:23 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BA0126579 for <6tisch@ietf.org>; Wed, 8 Feb 2017 01:10:22 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:212]) by smtp-cloud3.xs4all.net with ESMTP id i9AL1u00H4SpUcq019ALiw; Wed, 08 Feb 2017 10:10:20 +0100 Received: from AMontpellier-654-1-170-76.w92-145.abo.wanadoo.fr ([92.145.37.76]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 08 Feb 2017 10:10:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 08 Feb 2017 10:10:20 +0100 From: peter van der Stok To: 6tisch <6tisch@ietf.org> Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <9376fa080ad8d67c8b44641c2d62a958@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [6tisch] secure join bootstrap X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 09:10:25 -0000 Hi 6tisch security, Having re-read RPLinfo and reading the secure-join draft, I do have a suggestion about the traffic from pledge to registrar. The draft already mentions the IP-in-IP encapsulation specified in RPLinfo draft. Why not rely on the RPLinfo draft for the pledge to Registrar communication completely? The pledge can be considered a non-RPL aware node, one hop away from a DODAG node. The pledge may receive (allocate itself) a "temporary" routable IPv6 address. When it sends requests to the Registrar the join-proxy (first 6lri in RPLinfo) will add the necessary IP-in-IP headers. Also for the message from Registrar to pledge the same RPLinfo specification will be used. The Registrar does not need to be part of the DODAG, because RPLinfo prescribes what to do. I don't think allocating a temporary routable address will make the network more vulnerable. Communication between pledge and assistant is still over an insecure link with a permission to allow traffic from this one routable address (instead of link-local address) to the registrar. Once the pledge is accepted and the link is secured, I assume that neighbour discovery takes place, prefixes are distributed, routable addresses are allocated, and the temporary address disappears. Using RPLinfo makes the protocol less ad-hoc and relies on other established (RPLinfo) specifications. Greetings, Peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Wed Feb 8 04:59:34 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCE7129A21 for <6tisch@ietfa.amsl.com>; Wed, 8 Feb 2017 04:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.472 X-Spam-Level: X-Spam-Status: No, score=0.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FSL_HELO_BARE_IP_2=1.498, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBNCoIywGK5q for <6tisch@ietfa.amsl.com>; Wed, 8 Feb 2017 04:59:32 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA57126DFB for <6tisch@ietf.org>; Wed, 8 Feb 2017 04:59:32 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 194so15157278pgd.0 for <6tisch@ietf.org>; Wed, 08 Feb 2017 04:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:references:in-reply-to:to:cc :mime-version:content-transfer-encoding; bh=O8yuhjOso4N2dtjOihhtbRlbd6vAbDjtgQ5y3arQgDU=; b=leMeiGGkJEui7eDqouTuflCSVZ4BcRDf2d26QDcwAtkMLa2U/NrOy66va4T8L+Rohz AqVO0qxlj32x7U6FFfK/CgCzeL7loxVXELGfFz8ybEUgDMjmSnTeOrhvCcLQP4e/sT3f x71Kgw97OtgyJfpmnMi2jP7/XsUgRsGsggssmb3Uk+ddZkUnZDDaWCre29RwChqioDe5 CjqffMm1f2hqP019+hqd9DEuS5Baiq7Y1g7QAl+vyAHQhPEy7peXAnP1ULFUsDuCVrW8 YyN3j66eB8H9w5nbv2RlyLg86U9i8sB9EtYzdMajHzKSc3vk6qCP/zHQr1+/riCQvRUs 0XVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:references :in-reply-to:to:cc:mime-version:content-transfer-encoding; bh=O8yuhjOso4N2dtjOihhtbRlbd6vAbDjtgQ5y3arQgDU=; b=Mu5Ut46fmIu5izGle0TCXbYuC96YWcQtoRsQh9DEl3aSYFK5I2DDf36+mgcNw+t/Jf I1dt24mpdmWugqWngA3pJxg0Pr5tbSF9111htIBt9cxfLqs9rqLX2+dDBLGD9wzoqXgc AWcgibdBjOu4wqcSw068tU9dFA4SF/MVgoRp6yQPTTcOLxDBAVlhj56umXtuiU5I9v0a ZnsyJzPKjEmmWQbQx+xSVLPU1V8XUa8dQaQdCHlpIdwCCmgWy8+kHdf1628RWLyV7bhM AmKjAHgVcFGqvef5GIMsmw74ueaXwBEXVkbS985QxrQo+aXuG+kxgkgcYcxersEVqqmK GrlA== X-Gm-Message-State: AIkVDXIGoAZHVUhcO2uYsOxM5HdyBoVhIWd8YYAT0qA41lmkiCMcUC4IIBTKClA9iLg+Gg== X-Received: by 10.84.211.137 with SMTP id c9mr33417226pli.8.1486558772008; Wed, 08 Feb 2017 04:59:32 -0800 (PST) Received: from 192.168.0.102 ([103.251.128.68]) by smtp.gmail.com with ESMTPSA id k78sm20213501pfb.93.2017.02.08.04.59.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 04:59:31 -0800 (PST) From: Jiliang Wang Message-ID: <3B9A6D9E-9E09-4C23-A04A-D546BC40AA56@gmail.com> Date: Wed, 8 Feb 2017 20:59:28 +0800 References: <249879994.875357.1485333434749.JavaMail.root@vilafranca.uoc.es> <067B6893-5591-4F16-A2FE-22D0590FF6A2@gmail.com> In-Reply-To: <22681.55192.494061.861445@fireball.acr.fi> To: Tero Kivinen X-Mailer: NetEase iOS Mail 4.15.5.931 [iPhone 6 iOS10.2.1] MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tisch <6tisch@ietf.org>, Suresh Krishnan , Xavi Vilajosana Guillen Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-19.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 12:59:33 -0000
thanks very much. There is one more question.  Plea= se see inclined. 

On 02/07/2017 22:20, Ter= o Kivinen wrote:
Jiliang Wang writes:
> I also have several questions as listed below:
> =20
> 1. How to set the length (in time) of each cell. This should be = related to the
> number of retransmissions, i.e., for a higher number of retransm= issions, the
> cell length should accordingly be set longer=3F This may incur s= ome efficiency
> issue=3F

No. Each cell contains exactly on transmitted frame, and the ack
related to it. If there is needs for retransmissions they will be don= e
on the later cell, i.e., the transmitter delays sending until there i= s
cell to the same recipient, and also if this is shared cell, it will
also use backoff alcorithm so it will not use the next shared cell,
but skip some of them etc. =46or if the next cell is dedicated link,
then it will use it for retransmission.

See section 6.2.5.3 TSCH CSMA-CA retransmission algorithm in
802.15.4-2015, especially figure 6-6 center part, which covers the
TSCH retransmissions which are not priority access.

There is step =22Delay for random (2=5EBE - 1) shared links or until
dedicated link=22 there which will cause the delay.

The Timeslot length is set by sending EB with TSCH Timeslot IE having=
different value for macTsTimeslotLength.

> 2. What is default channelslot offset of EB, on which a new node=
> unjoined node should listen=3F

It is what is sent in the TSCH Slotframe and Link IE of the EB, and
the section 4 recommends that slotOffset is set to 0x0000, and
chOffset is set to 0x0000. 


It is still requ= ired a initial channel to receive the very first EB=3F How to set this=3F=

> 3. If neither K1 nor K2 is pre-provisioned, a joining node uses = the secExempt
> mechanism (IEEE Std 802.15.4, Section 9.2.4) to process all
> correctly-formatted EBs.
> Here I found no secExempt mechanism in Section 9.2.4 in IEEE Std= 802.15.4

IEEE Std 802.15.4-2015 section 9.2.4 step f) will check for secExempt= .

Note, that this section has changed since 802.15.4-2011 and earlier
versions of the 802.15.4, so you need to get the 802.15.4-2015 for th= e
section numbers to match. The actual functionality was there in
earlier versions also, but there were some mistakes in the state
machine, and it was harder to read.

Note, that 802.15.4-2015 is available for free from the IEEE Get
program, i.e. go to the
http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf to ge= t
it.

> 4. =E2=80=9CMany mechanisms exist for discrimination between net= works, the details of
> which are out of scope.=E2=80=9D According to current field sett= ing, it is difficult
> to differentiate different networks. Does it mean EB contains ot= her field that
> can be used for this purpose=3F

There is ongoing work to allocate IE for IET=46, and that IE could be=
used to provide for example the DAG root or something similar in the
EB, which would allow finding the proper network during the joining
process, especially if you have been part of the network before.
-- =20
kivinen=40iki.fi
=20
From nobody Wed Feb 8 05:54:34 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F56129AA3 for <6tisch@ietfa.amsl.com>; Wed, 8 Feb 2017 05:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flmU_ny6N58V for <6tisch@ietfa.amsl.com>; Wed, 8 Feb 2017 05:54:32 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4D0129AA6 for <6tisch@ietf.org>; Wed, 8 Feb 2017 05:54:31 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v18DsRbG017161 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Feb 2017 15:54:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v18DsRxY018980; Wed, 8 Feb 2017 15:54:27 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22683.8979.408756.8936@fireball.acr.fi> Date: Wed, 8 Feb 2017 15:54:27 +0200 From: Tero Kivinen To: Jiliang Wang In-Reply-To: <3B9A6D9E-9E09-4C23-A04A-D546BC40AA56@gmail.com> References: <249879994.875357.1485333434749.JavaMail.root@vilafranca.uoc.es> <067B6893-5591-4F16-A2FE-22D0590FF6A2@gmail.com> <3B9A6D9E-9E09-4C23-A04A-D546BC40AA56@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 7 min Archived-At: Cc: tisch <6tisch@ietf.org>, Suresh Krishnan , Xavi Vilajosana Guillen Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-19.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 13:54:33 -0000 Jiliang Wang writes: > > > 2. What is default channelslot offset of EB, on which a new node > > > unjoined node should listen? > > > > It is what is sent in the TSCH Slotframe and Link IE of the EB, and > > the section 4 recommends that slotOffset is set to 0x0000, and > > chOffset is set to 0x0000. > > It is still required a initial channel to receive the very first EB? How > to set this? To find the initial EB you need to do passive scan to find out the networks which are available. That means you need to listen several channels for some time to see if you listen any EBs on any of then, and collect all of those EBs and then pick which network you want to join. See section 6.3 for scanning through channels and doing active and passive scans in general, and section 6.3.6 for TSCH. -- kivinen@iki.fi From nobody Wed Feb 8 11:32:59 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8609A129FC6; Wed, 8 Feb 2017 11:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGvvLvU9_R87; Wed, 8 Feb 2017 11:32:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BD8129418; Wed, 8 Feb 2017 11:32:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7CE3D203AE; Wed, 8 Feb 2017 14:53:57 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7EDE7636BB; Wed, 8 Feb 2017 14:32:51 -0500 (EST) From: Michael Richardson to: 6tisch@ietf.org In-Reply-To: <855.1482509287@obiwan.sandelman.ca> References: <14596.1479347046@dooku.sandelman.ca> <360614422818437292b671f00cb498d3@XCH-RCD-001.cisco.com> <855.1482509287@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 6tisch-security@ietf.org, 6lo@ietf.org Subject: [6tisch] 6lo-ra-in-ie becoming X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: 6tisch@ietf.org List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 19:32:54 -0000 --=-=-= Content-Type: text/plain {6lo is CC'ed to close this question up, but Reply-To: set to 6tisch, as there isn't anything that is not 6tisch specific left at this point} I have just posted: draft-richardson-6tisch-join-enhanced-beacon https://datatracker.ietf.org/doc/draft-richardson-6tisch-join-enhanced-beacon/ The diff isn't very interesting, as it's mostly a forklift upgrade. This is the result of ongoing discussion to make the zero-touch and one-touch join processes work together, and to achieve a level of interoperation such that a zero-touch capable device, which has received a one-touch, could actually recognize that it needs to do zero-touch. Further, we are trying to accomodate both one-touch and zero-touch bootstrap using both pledge initiated communications (the one-touch preference), and Join Registrar/Coordinator initiated communications. The network shall know which way it will operate, and the network will announce this in the proposed enhanced beacon. (ENHANCED. I hope I stamped out all the occurances of that other E-word, which I will not write here) This text could go into 6tisch-minimal-security, or it could be a seperate document. It would have been nice to put it into 6tisch-minimal; but I sure hope that ship has sailed. Maybe it should Update that? The R flag is for host-operation of nodes which would otherwise want to listen for a multicast Router-Advertisement, or initiate one with a multicast RS. It is hard for me to construct a scenario where the R bit would be zero, and yet the device is alive enough that it thinks it ought to send beacons. It could be that some networks do not wish to support attachment of leaf nodes to all routers though. {previous paragraph probably belongs in document?} The core is: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD-XXX |J|I|R| R E S V | network ID | +-+-+-+-+-+-+-+-+-+-+-+---------+ | | network ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | network ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ J : the Join Proxy flag is set if the sending node will operate as a Join Proxy according to {{I-D.ietf-6tisch-minimal-security}}. I : the Initiate Join flag is set if this network supports pledges initiating the join process themselves according to {{I-D.ietf-6tisch-minimal-security}}. If not set, then the pledge should do an NS DAD operation ({{RFC6775}} section 4.3, explained in {{I-D.ietf-6tisch-dtsecurity-secure-join}}) and then remain silent, to wait to be contacted. R : the Router Advertisement flag is set if the sending node will act as a Router for host-only nodes that need addressing via unicast Router Solicitation messages. network ID : this is an opaque 16-byte identifier that uniquely identifies this network, potentially among many networks that are operating in the same frequencies in overlapping physical space. In a 6tisch network, where RPL is used as the mesh routing protocol, the network ID SHOULD be constructed from a SHA256 hash of the DODAGID of the network. The result will be a 32-byte hash, and the lower 16-bytes should be used. {oh. I show only 8 bytes of network-ID in the picture. Oops. I will grow the diagram} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlibcmMACgkQgItw+93Q 3WWh6QgAoMRsUjWGNa1I9vl3PgpIufhSdBUO9sHqwUyj/DSmQuUi4kR2V0X+F/91 35efGp3A3aO9Xyqaz5vkOKCFSzAuPZSBeMINc+ZGE37g+N2CDJ2E9u6MU/srN5ox DfTt01lIXjcsxwyPAx7+/gMF2KUdPHGYetyBB4b+vbpcsQwEsaIVuR9YopflKwU1 GtpRbMv0/wOi/7soWWJRhiJwHFTL3RDL9iP45fiz3Rwf8AnJdzomWrTSFtlTRdCE y2SzK4t7yIz6nDqJTxfYj0uReVhcyng+2BAVDgdO/qGfnqE5UEWcuZNRIxRfOoNl GZomFidx1e5tI/okWrVbMFSDGDjECw== =CkxW -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 9 01:59:20 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB60512951D for <6tisch@ietfa.amsl.com>; Thu, 9 Feb 2017 01:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_bXXapxI3rT for <6tisch@ietfa.amsl.com>; Thu, 9 Feb 2017 01:59:13 -0800 (PST) Received: from mail.uantwerpen.be (ex02.uantwerpen.be [143.169.229.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18D91296D5 for <6tisch@ietf.org>; Thu, 9 Feb 2017 01:59:11 -0800 (PST) Received: from orion (143.169.229.21) by ex02.ad.ua.ac.be (143.169.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Thu, 9 Feb 2017 10:59:09 +0100 Message-ID: <1486634348.14367.14.camel@uantwerpen.be> From: Esteban Municio To: <6tisch@ietf.org> Date: Thu, 9 Feb 2017 10:59:08 +0100 Organization: UAntwerp Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-GWQhy87SellUbk+YTAge" X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-Originating-IP: [143.169.229.21] X-ClientProxiedBy: ex01.ad.ua.ac.be (143.169.229.22) To ex02.ad.ua.ac.be (143.169.229.23) Archived-At: Subject: [6tisch] Recommended configuration for Shared cells Backoff in Minimal X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 09:59:18 -0000 --=-GWQhy87SellUbk+YTAge Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I was wondering if there is any recommendation about how set up the Backoff mechanism in shared cells when no ACKs are expected.=20 According to the standard, macMaxBE and macMinBE are defined and the BE is increased at every attempt. However, if the node is not expecting any ACK (i.e sending DIOs or EBs), I guess the BE will be always the same. Is there any recommendation in Minimal about how to choose this value? Maybe a value related with the number of nodes or DIO/EB period? Kind regards, Esteban --=20 Esteban Municio IDLab - Dept. Mathematics and Computer Science=20 University of Antwerp - imec Middelheimlaan 1 , 2020 Antwerp, Belgium=20 Office M.G.325=20 --=-GWQhy87SellUbk+YTAge Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJYnD1tAAoJEIEjyYKR6zqcH38H/i1XovKUMXIP9Al54x8BLUtv z5kmMZuPMrL0eyG2RCvjWtOwc46XFHUU9BpAfJtXQ6s5X4jHN0yEYLwthjjQMfif iGNWjOLKEupiPOJtnAMyV+VWFJyPBw6ImUx9zg9N/ylv0NcptMEYuGwP1Us8tqVx S2Lt1KxcH5fqKyAOA7XObHkmT4ljvhcgj+w1RB6m+73J7mu5pUQwmOui3NrKlK1l jkqG0WvLSRzXKnYQIa9FD73DyLDQZL5Hck7Da0u53Btb7/4Uooi3kY86ebD4FlaT yYG7z0goGNCIK5tq2ib4u9kwroP/IYHlS+bj4drhMifLQI9hyLINd50OhiH6F4c= =2gtO -----END PGP SIGNATURE----- --=-GWQhy87SellUbk+YTAge-- From nobody Thu Feb 9 02:02:14 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1DD129810 for <6tisch@ietfa.amsl.com>; Thu, 9 Feb 2017 02:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.473 X-Spam-Level: X-Spam-Status: No, score=0.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FSL_HELO_BARE_IP_2=1.498, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyoXBxJmIzW9 for <6tisch@ietfa.amsl.com>; Thu, 9 Feb 2017 02:02:12 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2512912969D for <6tisch@ietf.org>; Thu, 9 Feb 2017 02:02:12 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id v184so17544469pgv.1 for <6tisch@ietf.org>; Thu, 09 Feb 2017 02:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:references:in-reply-to:to:cc :mime-version:content-transfer-encoding; bh=i/WoEaQ76ZFR8jtWUjttCk8kGlMu4Dij56TTk7MQupU=; b=K6Zl4OBKOMrNHZSo4NtibnQKP2zQw9MPp6if9HKbFjGYc1+WMvY51VoKxvUggc3ULT 7QOt/8py7FNTcCn2zKavw4ZmSniL3HiMoArb6VLdb8o5n5sSpwrugWz/hjjoqAC+e/Sk bo0X/81JL003mlGivAY4k+CpQ5dWBXfXBTnzgrVieOH8mm7u2MjYncGcP2gxGTk7Pcsc I6HLaqLcEpSN7AFBKSET7uRcNh6KLC8Xk8FMbZ5X84KFSevz9S77STah35+NQWbEDrbh WIxPG9wBtnxi1FEhNeOnRmE6w5eWJppvduQAHYh0bO9STYdc8xmRFklWuYe0OyfaBfSG W2RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:references :in-reply-to:to:cc:mime-version:content-transfer-encoding; bh=i/WoEaQ76ZFR8jtWUjttCk8kGlMu4Dij56TTk7MQupU=; b=FCmWZv8BXxxcCfUMz16BRKvM3ijqd/bh9vg9KKQ7t/Oi1DYHugRC5IY0g+k2UdEaOU z1vTmXjPD6ShQUKbxG6XJwLvrayimNuCYMMNQZ3q2gJouv5bupRQP9TcFPkut0y3y5Ph bNQnMpcOuXIw3sl7M/1RTd1iZQCA402uz0fuPY1uhDWgBKZXZDyGaBi4ejNlPwZAPpRJ rd8OWx0XhSN8eZKxv+KqRrmHtFJ9iTgvkUbnfOd8wrlWHR2YcojervUTgpwOKV2xSxs1 Lv94UcNbrEWJvqkFbg5OBQiwTeeuyK0oTculUtjIQFphoyGWl+9D0qrhPvBNZI7wNmXP sv6A== X-Gm-Message-State: AMke39n4wImPQFq/B7WIyikwnlN2h71FMpTcnZyLvRc7dFvyExg12KwfBVxoVo9ujoNhrw== X-Received: by 10.99.245.83 with SMTP id e19mr2945485pgk.113.1486634531735; Thu, 09 Feb 2017 02:02:11 -0800 (PST) Received: from 192.168.0.1 ([124.160.218.83]) by smtp.gmail.com with ESMTPSA id d29sm27259190pfk.83.2017.02.09.02.02.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 02:02:11 -0800 (PST) From: Jiliang Wang Message-ID: <23128571-836F-42A4-AC17-DEBE564EA73A@gmail.com> Date: Thu, 9 Feb 2017 18:02:06 +0800 References: <249879994.875357.1485333434749.JavaMail.root@vilafranca.uoc.es> <067B6893-5591-4F16-A2FE-22D0590FF6A2@gmail.com> <3B9A6D9E-9E09-4C23-A04A-D546BC40AA56@gmail.com> In-Reply-To: <22683.8979.408756.8936@fireball.acr.fi> To: Tero Kivinen X-Mailer: NetEase iOS Mail 4.15.5.931 [iPhone 6 iOS10.2.1] MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tisch <6tisch@ietf.org>, Suresh Krishnan , Xavi Vilajosana Guillen Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-19.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 10:02:13 -0000


On 02/08/2017 21:54, Ter= o Kivinen wrote:
Jiliang Wang writes:
> > > 2. What is default channelslot offset of EB, on which = a new node
> > > unjoined node should listen=3F
> >    
> >     It is what is sent in the TSCH Slot= frame and Link IE of the EB, and
> >     the section 4 recommends that slotO= ffset is set to 0x0000, and
> >     chOffset is set to 0x0000. =20
> =20
>     It is still required a initial channel t= o receive the very first EB=3F How
>     to set this=3F

To find the initial EB you need to do passive scan to find out the
networks which are available. That means you need to listen several
channels for some time to see if you listen any EBs on any of then,
and collect all of those EBs and then pick which network you want to
join. See section 6.3 for scanning through channels and doing active
and passive scans in general, and section 6.3.6 for TSCH. 
<= br>
Yes, there is channel scanning.  Actually I have a question = here. By current scanning mechanism, does it mean there is no guarantee f= or a scanning node and beaconing node to meet=3F Meanwhile, it may also t= ake a long time to for two nodes to meet.
-- =20
kivinen=40iki.fi
=20
From nobody Thu Feb 9 15:47:00 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEEA129507 for <6tisch@ietfa.amsl.com>; Thu, 9 Feb 2017 15:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4gMqUDfDsWv for <6tisch@ietfa.amsl.com>; Thu, 9 Feb 2017 15:46:57 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E266A129463 for <6tisch@ietf.org>; Thu, 9 Feb 2017 15:46:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,138,1484002800"; d="scan'208,217";a="259641336" Received: from mail-ua0-f182.google.com ([209.85.217.182]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 10 Feb 2017 00:46:54 +0100 Received: by mail-ua0-f182.google.com with SMTP id 96so15908516uaq.3 for <6tisch@ietf.org>; Thu, 09 Feb 2017 15:46:54 -0800 (PST) X-Gm-Message-State: AMke39krAgX0XoliLuJpgleCbzfSbi2xoAJi8Cmbbtk9weAj5nonhkTAT8vYGmBLZ9GBhPZXrKf0d0xsDvyAow== X-Received: by 10.159.33.4 with SMTP id 4mr3325840uab.156.1486684013666; Thu, 09 Feb 2017 15:46:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.114.70 with HTTP; Thu, 9 Feb 2017 15:46:31 -0800 (PST) In-Reply-To: <1486634348.14367.14.camel@uantwerpen.be> References: <1486634348.14367.14.camel@uantwerpen.be> From: Thomas Watteyne Date: Fri, 10 Feb 2017 00:46:31 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Esteban Municio Content-Type: multipart/alternative; boundary=94eb2c0b66e68725dd0548219875 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] Recommended configuration for Shared cells Backoff in Minimal X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 23:46:59 -0000 --94eb2c0b66e68725dd0548219875 Content-Type: text/plain; charset=UTF-8 Esteban, I believe this is fully specified in the 802.15.4 standard. In a nutshell, the back-off mechanism is triggered only when the cell is marked as "shared". When a mote sends a packet and doesn't get an ACK, the BE is changed. If you send a frame to link-layer destination 0xffff, you're not expecting an ACK, so BE will not change. I may be missing your point? Thomas On Thu, Feb 9, 2017 at 10:59 AM, Esteban Municio < esteban.municio@uantwerpen.be> wrote: > Hi all, > > I was wondering if there is any recommendation about how set up the > Backoff mechanism in shared cells when no ACKs are expected. > > According to the standard, macMaxBE and macMinBE are defined and the BE > is increased at every attempt. However, if the node is not expecting any > ACK (i.e sending DIOs or EBs), I guess the BE will be always the same. > Is there any recommendation in Minimal about how to choose this value? > > Maybe a value related with the number of nodes or DIO/EB period? > > Kind regards, > Esteban > > -- > Esteban Municio > IDLab - Dept. Mathematics and Computer Science > University of Antwerp - imec > Middelheimlaan 1 , 2020 Antwerp, Belgium > Office M.G.325 > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --94eb2c0b66e68725dd0548219875 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Esteban,

I believe this is fully specif= ied in the 802.15.4 standard. In a nutshell, the back-off mechanism is trig= gered only when the cell is marked as "shared". When a mote sends= a packet and doesn't get an ACK, the BE is changed. If you send a fram= e to link-layer destination 0xffff, you're not expecting an ACK, so BE = will not change.

I may be missing your point?

Thomas

On Thu, Feb 9, 2017 at 10:59 AM, Esteban Municio <esteban.municio@uantwerpen.be> wrote:
Hi all,

I was wondering if there is any recommendation about how set up the
Backoff mechanism in shared cells when no ACKs are expected.

According to the standard, macMaxBE and macMinBE are defined and the BE
is increased at every attempt. However, if the node is not expecting any ACK (i.e sending DIOs or EBs), I guess the BE will be always the same.
Is there any recommendation in Minimal about how to choose this value?

Maybe a value related with the number of nodes or DIO/EB period?

Kind regards,
Esteban

--
Esteban Municio
IDLab - Dept. Mathematics and Computer Science
University of Antwerp - imec
Middelheimlaan 1 , 2020 Antwerp, Belgium
Office M.G.325

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
=
_______________________________________

=
Thomas W= atteyne, PhD
Research Scientist & Innovator, Inria
Sr Networkin= g Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN

______________________= _________________
--94eb2c0b66e68725dd0548219875-- From nobody Fri Feb 10 03:21:27 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28574129588 for <6tisch@ietfa.amsl.com>; Fri, 10 Feb 2017 03:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpiF_YEeHMXd for <6tisch@ietfa.amsl.com>; Fri, 10 Feb 2017 03:21:25 -0800 (PST) Received: from mail.uantwerpen.be (ex01.uantwerpen.be [143.169.229.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32018129412 for <6tisch@ietf.org>; Fri, 10 Feb 2017 03:21:25 -0800 (PST) Received: from orion (143.169.229.21) by ex01.ad.ua.ac.be (143.169.229.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Fri, 10 Feb 2017 12:21:23 +0100 Message-ID: <1486725677.4483.19.camel@uantwerpen.be> From: Esteban Municio To: Thomas Watteyne Date: Fri, 10 Feb 2017 12:21:17 +0100 In-Reply-To: References: <1486634348.14367.14.camel@uantwerpen.be> Organization: UAntwerp Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-ERoexQLyZL+M8eyXJZos" X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-Originating-IP: [143.169.229.21] X-ClientProxiedBy: ex01.ad.ua.ac.be (143.169.229.22) To ex01.ad.ua.ac.be (143.169.229.22) Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] Recommended configuration for Shared cells Backoff in Minimal X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 11:21:27 -0000 --=-ERoexQLyZL+M8eyXJZos Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thomas, No, that's exactly what I ment. I was just thinking about how the network would behave when for example 20 o 30 nodes are switched on simultaneously in Minimal. If the initial value of BE is low (1 or 2), collisions are expected to be very frequent in the shared cell. And since the first messages for joining the network (EBs and DIOs) are broadcasted without expecting an ACK, the BE could remain unmodified and the joining process could last forever. Could this scenario happen? Or am I missing something important? But indeed maybe this is out of the scope of Minimal since is just matter of sizing the number of shared cells in the schedule and the topic is rather related with the 802.15.4 standard than with 6tisch. Kind regards, Esteban On Thu, 2017-02-09 at 23:46 +0000, Thomas Watteyne wrote: > Esteban,=20 >=20 >=20 > I believe this is fully specified in the 802.15.4 standard. In a > nutshell, the back-off mechanism is triggered only when the cell is > marked as "shared". When a mote sends a packet and doesn't get an ACK, > the BE is changed. If you send a frame to link-layer destination > 0xffff, you're not expecting an ACK, so BE will not change. >=20 >=20 > I may be missing your point? >=20 >=20 > Thomas >=20 > On Thu, Feb 9, 2017 at 10:59 AM, Esteban Municio > wrote: > Hi all, > =20 > I was wondering if there is any recommendation about how set > up the > Backoff mechanism in shared cells when no ACKs are expected. > =20 > According to the standard, macMaxBE and macMinBE are defined > and the BE > is increased at every attempt. However, if the node is not > expecting any > ACK (i.e sending DIOs or EBs), I guess the BE will be always > the same. > Is there any recommendation in Minimal about how to choose > this value? > =20 > Maybe a value related with the number of nodes or DIO/EB > period? > =20 > Kind regards, > Esteban > =20 > -- > Esteban Municio > IDLab - Dept. Mathematics and Computer Science > University of Antwerp - imec > Middelheimlaan 1 , 2020 Antwerp, Belgium > Office M.G.325 > =20 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > =20 >=20 >=20 >=20 >=20 --=20 Esteban Municio IDLab - Dept. Mathematics and Computer Science=20 University of Antwerp - imec Middelheimlaan 1 , 2020 Antwerp, Belgium=20 Office M.G.325=20 --=-ERoexQLyZL+M8eyXJZos Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJYnaItAAoJEIEjyYKR6zqc4O4IALyoToz3dPPKNde49gkoZmTE drmkJKMjZ1/9hDBtA3OW16jD0lzc3AUF6MUOmD97Pj0STD0q7optcGjTS2EN4Krz hIO+ViWECdr9ZRE9lOASOGygxjxWa7b7kN8iILZzBb/62Un0fn6rL84pOOEtsK7K q55Quk/zVlgXc8ORovPEY+LF7jomN1Xp+clY67Q6nw9UI0OAWgUlGRkfIFJiKrng +idFgEcArjd0Y6cakBS3Q+hNGhptisVvGZg1u8q51Cnd8ly1Fa/DQ0BMkfn0Rxn2 2hHN+lMgO1DUe6xJQnoKV6lPG1ovwCUWcsMFlonOIjOokC6w4FR2cUvtmJYkAsI= =63MS -----END PGP SIGNATURE----- --=-ERoexQLyZL+M8eyXJZos-- From nobody Fri Feb 10 03:46:16 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5688E12949B for <6tisch@ietfa.amsl.com>; Fri, 10 Feb 2017 03:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOkw3Er-anaW for <6tisch@ietfa.amsl.com>; Fri, 10 Feb 2017 03:46:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897E812945C for <6tisch@ietf.org>; Fri, 10 Feb 2017 03:46:14 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v1ABk7mV006164 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Feb 2017 13:46:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v1ABk6ui001446; Fri, 10 Feb 2017 13:46:06 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22685.43006.779732.175863@fireball.acr.fi> Date: Fri, 10 Feb 2017 13:46:06 +0200 From: Tero Kivinen To: Jiliang Wang In-Reply-To: <23128571-836F-42A4-AC17-DEBE564EA73A@gmail.com> References: <249879994.875357.1485333434749.JavaMail.root@vilafranca.uoc.es> <067B6893-5591-4F16-A2FE-22D0590FF6A2@gmail.com> <3B9A6D9E-9E09-4C23-A04A-D546BC40AA56@gmail.com> <23128571-836F-42A4-AC17-DEBE564EA73A@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Archived-At: Cc: tisch <6tisch@ietf.org>, Suresh Krishnan , Xavi Vilajosana Guillen Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-19.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 11:46:15 -0000 Jiliang Wang writes: > Yes, there is channel scanning. Actually I have a question here. By > current scanning mechanism, does it mean there is no guarantee for a > scanning node and beaconing node to meet? Meanwhile, it may also take a > long time to for two nodes to meet. Yes. If you do scanning do fast or incorrectly it is possible that you never hear EB. On the other hand if you do it so that you are sure to hear the EBs it might take tens of minutes... You can of course do all kind of implementation depending things to make this better. For example if you do energy detection on the channel first. If there is nobody ever on the channel for long time, that might mean that channel is not part of the schedule, and listening it might not be useful. On the other hand if there is too much energy on the channel, it might be because there is some other radio transmitter on the channel, and it might not be used for channel hopping because of that reason. If you hear any 802.15.4 TSCH frames on the channel, you can assume that this channel is in the current channel hopping sequence, and if network is set properly there should be EB on the channel at some point of time. On the other hand you might need to wait for it for EB_PERIOD * slotframe size * timeslot length * number of channels * n, where n depends how many dropped beacons you want to wait. I.e. with typical settings this might be few minutes. If you do not see EB during that time, you move to next channel and repeat... -- kivinen@iki.fi From nobody Fri Feb 10 04:23:07 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38B512962B for <6tisch@ietfa.amsl.com>; Fri, 10 Feb 2017 04:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEFlkbYwcyyL for <6tisch@ietfa.amsl.com>; Fri, 10 Feb 2017 04:23:04 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286161295D1 for <6tisch@ietf.org>; Fri, 10 Feb 2017 04:23:04 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DDABA2009E for <6tisch@ietf.org>; Fri, 10 Feb 2017 07:44:14 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0012D6381A for <6tisch@ietf.org>; Fri, 10 Feb 2017 07:23:02 -0500 (EST) To: 6tisch@ietf.org References: <9376fa080ad8d67c8b44641c2d62a958@xs4all.nl> From: Michael Richardson Message-ID: <7c735780-8a71-4100-a492-55fc9a77ac89@sandelman.ca> Date: Fri, 10 Feb 2017 07:23:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <9376fa080ad8d67c8b44641c2d62a958@xs4all.nl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cfl8r8ih4VRXtK05KVTqsqsKHU0OUQVxu" Archived-At: Subject: Re: [6tisch] secure join bootstrap X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 12:23:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cfl8r8ih4VRXtK05KVTqsqsKHU0OUQVxu Content-Type: multipart/mixed; boundary="5OWfb0nPNuMULoC5WFJW6V78h3wgeIaJt"; protected-headers="v1" From: Michael Richardson To: 6tisch@ietf.org Message-ID: <7c735780-8a71-4100-a492-55fc9a77ac89@sandelman.ca> Subject: Re: [6tisch] secure join bootstrap References: <9376fa080ad8d67c8b44641c2d62a958@xs4all.nl> In-Reply-To: <9376fa080ad8d67c8b44641c2d62a958@xs4all.nl> --5OWfb0nPNuMULoC5WFJW6V78h3wgeIaJt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable see inline. On 02/08/17 04:10, peter van der Stok wrote: > Hi 6tisch security, >=20 > Having re-read RPLinfo and reading the secure-join draft, I do have a > suggestion about the traffic from pledge to registrar. The draft alread= y > mentions the IP-in-IP encapsulation specified in RPLinfo draft. Why not= > rely on the RPLinfo draft for the pledge to Registrar communication > completely? This was always my intention: leverage the IPIP compression mechanism and source route forwarding... no new code! I'm glad you came up with the idea too, which means it must be a good one! I had a number of thoughts about how to do this. a) have the Join Proxy send a DAO about the pledge. This is simplest in many ways, and for non-storing networks, this has no impact on the mesh. For storing networks, this would be an issue, and I'd suggest having another non-storing instance for joining... (but, mixed mode) b) use another signal from Join Proxy to JRC/root. This is what I'm currently proposing, although I used GRASP which may demand TCP. The DAO mechanism has the downside of not providing any ACK. > The pledge can be considered a non-RPL aware node, one hop away from a > DODAG node. >=20 > The pledge may receive (allocate itself) a "temporary" routable IPv6 > address. I'm not convinced the pledge *needs* that routable address if all the traffic is IPIP encapsulated. I'm pretty sure that I'd rather not expose the prefix of the network to the unauthenticated pledge if we can avoid that. It also implies that the pledge needs to hear a RA. > When it sends requests to the Registrar the join-proxy (first 6lri in > RPLinfo) will add the necessary IP-in-IP headers. Also for the message > from Registrar to pledge the same RPLinfo specification will be used. > The Registrar does not need to be part of the DODAG, because RPLinfo > prescribes what to do. >=20 > I don't think allocating a temporary routable address will make the > network more vulnerable. > Communication between pledge and assistant is still over an insecure > link with a permission to allow traffic from this one routable address > (instead of link-local address) to the registrar. I agree with you: it can be made to work. Are you thinking that the temporary address would not be from the network's prefix, but entirely different? Why do we even need that, I wonder. Do you think there is any increased risk of one pledge attacking another one? --5OWfb0nPNuMULoC5WFJW6V78h3wgeIaJt-- --cfl8r8ih4VRXtK05KVTqsqsKHU0OUQVxu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlidsKYACgkQgItw+93Q 3WX6igf+LodtJOX/ZkF1eJSx795NzKTGcs+CSlJ62HEefkEZSg4xnR3vYvN17SWk 3LunEU6hN58CmSMx9i7z9UvdPJAKyPYne0EZgeXDA8q6+cSGXUIg4xn5f0erXWKK a0ZcTUr3U42CezsG4GxDSzJNg7Tin39hSvk73HOWj8O9trS7SXC4fJPLTejaxnDq 8zxg1LJB9vbmwdK05kU0ysQVz8kAmZegTc1TGxHznir4z3TFsbpskZB3QsYVPuAu LayB1WkdJHh4Mp0zEmvDM7DzyoB7MSFk5w3vq9IDKXkGqicGmJugIW46oFGO/uJm 20a6MxHVRNwjbXpHYjcw4fVix/ggCw== =F70Q -----END PGP SIGNATURE----- --cfl8r8ih4VRXtK05KVTqsqsKHU0OUQVxu-- From nobody Fri Feb 10 08:46:48 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF9C129A3C; Fri, 10 Feb 2017 08:46:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148674520416.29292.3678947805783745834.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 08:46:44 -0800 Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, pthubert@cisco.com, 6tisch-chairs@ietf.org, 6tisch@ietf.org Subject: [6tisch] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-6tisch-minimal-19=3A_=28with_COMMENT=29?= X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:46:44 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-6tisch-minimal-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of comments mostly on the use of normative language: 1) The following sentence contradict a little all other normative language in this document (basically making everything a SHOULD): "Any 6TiSCH compliant device SHOULD implement this mode of operation." Why is this a upper case SHOULD? Is this sentence needed at all? 2) Here the usage of normative language is also not clear to me: "The default values of the TSCH Timeslot template (defined in [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. A node MAY use different values by properly announcing them in its Enhanced Beacon." 3) Is it correct that these are SHOULDs? "EB Destination Address field SHOULD be set to 0xFFFF (short broadcast address). The EB Source Address field SHOULD be set as the node's short address if this is supported. Otherwise the long address SHOULD be used." 4) What the recommended value for EB_PERIOD?: "In a minimal TSCH configuration, a node SHOULD send an EB every EB_PERIOD." 5) This is also a weird SHOULD for me: "EBs SHOULD be used to obtain information about local networks, ..." What else should be used? Or you just don't obtain the information you need. I actually guess that you should simply use a lower case should in this sentence. Should it be?: "The default values of the TSCH Timeslot template (defined in [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. If a node uses different values, it MUST properly announcing them in its Enhanced Beacon." Or is this sentence just duplicating the SHOULD of the previous sentence slightly differently? 6) Maybe also name the recommended values for MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT in section 6.2 or give a forward reference to section 7.3? 7) "At any time, a node MUST maintain connectivity to at least one time source neighbor. " How can you ensure that you can maintain connectivity? I guess this must be a SHOULD... or what do you mean exactly by 'maintain connectivity'? 8) I think this sentence is confusing given the recommended value for NUM_UPPERLAYER_PACKETS is 1: "One entry in the queue is reserved at all times for frames of type BEACON." I guess what you want to say it that if a BEACON should be send and there is no space in the queue one frame should be drop and the BEACON should be queued instead? 9) I'm a little surprised to not see anything about 6LoWPAN in the body of the document (besides the intro in section 1). Shouldn't there also be some normative language on the use of 6LoWPAN? One editorial comment (from the abstract): I don't really understand this sentence "A minimal mode of operation is a baseline set of protocols, ..." I guess you want to say something like "This minimal mode of operation specifies the baseline set of protocols that need to be supported, .." From nobody Fri Feb 10 19:05:56 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF2612947C for <6tisch@ietfa.amsl.com>; Fri, 10 Feb 2017 19:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.473 X-Spam-Level: X-Spam-Status: No, score=0.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FSL_HELO_BARE_IP_2=1.498, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuxB-pMWVOwi for <6tisch@ietfa.amsl.com>; Fri, 10 Feb 2017 19:05:53 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B05B129474 for <6tisch@ietf.org>; Fri, 10 Feb 2017 19:05:53 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id 194so15590259pgd.2 for <6tisch@ietf.org>; Fri, 10 Feb 2017 19:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:references:to:cc:mime-version :content-transfer-encoding; bh=3SzP5Y+7d1/EXfubvmh6Q0O83piIJfdIPNdTubEMsnM=; b=f1I8vm2jOTUpttZXtSxUDfAYsIoXkTLo697ZtIqzNd2A39fkWHXcePNVz41bvEACEX Cx5qzDgUBNmdHVZaTkl72yamZoiVKmp5lYbfLaJm3bsQtN9aoCWXUUPEftCbeMJWvMM9 7Jq20NkUWy3SYCcWhoykvDCbFcbi+aWOllRIravc+eQoiHjyWSL1PV4CM57Kpjg0Uz0w S3gtzRwXk091gPwEyG+cLyWHanVI2GZnHYdGTqY39AU/j8xPq77wtbGtnrsUUoBXOYzl Q14VxzZ1jlRA1yBizcgbdge+HKddANtfru2PlW0ia/XvEL/ENEhSVRDhCHf0u8ANcLMT nkSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:references:to:cc :mime-version:content-transfer-encoding; bh=3SzP5Y+7d1/EXfubvmh6Q0O83piIJfdIPNdTubEMsnM=; b=c8dJcrhCuABRNOMjKKFdWpUxGz0IQjjq+qSy7LFmEo9dx7ntcujsa+OFlXSaDLyuVB RVO332VDTxCzvvzkd7HmqOtQG2+z7bmx8TlEjaOyFaF3gDL6FKwfsC/YfNBvglIzM1gd hdYVLYH3dmQ+NFmk+C1wJOW8yB3aO5NgMLTYOf5jz0Saj8gSgv2irBXgdPg1wew1ntWz kiGBzxr/nmjzkJ/j65FXX5vq03v6ADHwD2hXHLPV0ewujkD3OJ44QuMZclzkrobNKLRt SadjhGRywxGbhhui6zfG8dZIHqPrdcAvL38hG3rKWvcJvW2AhmBPyns2WJRx24pJ0KHn 88Vg== X-Gm-Message-State: AMke39lpTh1DR/Xt7yTtrXjkG/EWMH4DlCXVEL1uhL4W78IN5L6uil1Rz+FHQ3spAH5mJw== X-Received: by 10.84.128.33 with SMTP id 30mr15786988pla.128.1486782352748; Fri, 10 Feb 2017 19:05:52 -0800 (PST) Received: from 192.168.0.1 ([103.251.128.68]) by smtp.gmail.com with ESMTPSA id y82sm1652055pff.132.2017.02.10.19.05.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 19:05:52 -0800 (PST) From: Jiliang Wang Message-ID: <2B9773AA-9B99-43D3-BA32-F1A0999E33CF@gmail.com> Date: Sat, 11 Feb 2017 11:05:48 +0800 References: <249879994.875357.1485333434749.JavaMail.root@vilafranca.uoc.es> <067B6893-5591-4F16-A2FE-22D0590FF6A2@gmail.com> <3B9A6D9E-9E09-4C23-A04A-D546BC40AA56@gmail.com> <23128571-836F-42A4-AC17-DEBE564EA73A@gmail.com> To: Tero Kivinen X-Mailer: NetEase iOS Mail 4.15.5.931 [iPhone 6 iOS10.2.1] MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tisch <6tisch@ietf.org>, Suresh Krishnan , Xavi Vilajosana Guillen Subject: Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-minimal-19.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 03:05:54 -0000
=20 =20


On 02/10/2017 19:46, Ter= o Kivinen wrote:
Jiliang Wang writes:
>     Yes, there is channel scanning.  Ac= tually I have a question here. By
>     current scanning mechanism, does it mean= there is no guarantee for a
>     scanning node and beaconing node to meet= =3F Meanwhile, it may also take a
>     long time to for two nodes to meet.

Thanks for your explanation= .  I believe this is an important step in the entire protocol. The s= pecification should avoid the scenario that the meeting time is too = long or even unlimited (in any case) rather than depending on the impleme= ntation=3F

Yes. If you do scanning do fast or incorrectly i= t is possible that you
never hear EB. On the other hand if you do it so that you are sure to=
hear the EBs it might take tens of minutes...

You can of course do all kind of implementation depending things to
make this better. =46or example if you do energy detection on the
channel first. If there is nobody ever on the channel for long time,
that might mean that channel is not part of the schedule, and
listening it might not be useful. On the other hand if there is too
much energy on the channel, it might be because there is some other
radio transmitter on the channel, and it might not be used for channe= l
hopping because of that reason. If you hear any 802.15.4 TSCH frames
on the channel, you can assume that this channel is in the current
channel hopping sequence, and if network is set properly there should=
be EB on the channel at some point of time. On the other hand you
might need to wait for it for EB=5FPERIOD * slotframe size * timeslot=
length * number of channels * n, where n depends how many dropped
beacons you want to wait. I.e. with typical settings this might be fe= w
minutes. If you do not see EB during that time, you move to next
channel and repeat...
-- =20
kivinen=40iki.fi
=20
=20 =20
From nobody Mon Feb 13 05:33:59 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317F1129674; Mon, 13 Feb 2017 05:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgj49_Y98zet; Mon, 13 Feb 2017 05:33:56 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92D4129669; Mon, 13 Feb 2017 05:33:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,156,1484002800"; d="scan'208,217";a="213036841" Received: from mail-vk0-f42.google.com ([209.85.213.42]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 13 Feb 2017 14:33:28 +0100 Received: by mail-vk0-f42.google.com with SMTP id x75so60340562vke.2; Mon, 13 Feb 2017 05:33:28 -0800 (PST) X-Gm-Message-State: AMke39mSjT7wjJpybGNueL1kR8KNkJt0eoBXW2GE2PZ08BwzQqquIReNLQOYuejVurxfDZrlfOdiyWzbjDl1XA== X-Received: by 10.31.138.9 with SMTP id m9mr9506081vkd.110.1486992807879; Mon, 13 Feb 2017 05:33:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.160.148 with HTTP; Mon, 13 Feb 2017 05:33:07 -0800 (PST) From: Thomas Watteyne Date: Mon, 13 Feb 2017 14:33:07 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=001a1144fcc218eeec0548697eca Archived-At: Cc: iesg-secretary@ietf.org Subject: [6tisch] 17 Feb 2017 6TiSCH interim meeting CANCELLED X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 13:33:58 -0000 --001a1144fcc218eeec0548697eca Content-Type: text/plain; charset=UTF-8 All, Several key contributors would not be able to make it to the interim this Friday. Pascal and I have therefore decided to cancel this week's interim. Let's continue the discussions about the very last changes to minimal, and about 6P directly on the mailing list. Pascal & Thomas -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a1144fcc218eeec0548697eca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Several key contributors would not= be able to make it to the interim this Friday. Pascal and I have therefore= decided to cancel this week's interim.

Let= 9;s continue the discussions about the very last changes to minimal, and ab= out 6P directly on the mailing list.

Pascal & = Thomas

--
_______= ________________________________

Thomas Watteyne, PhD
Rese= arch Scientist & Innovator, Inria
Sr Networking Design Eng, Linear = Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6Ti= SCH

_______________________________________
--001a1144fcc218eeec0548697eca-- From nobody Mon Feb 13 05:59:32 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8826F1294E0 for <6tisch@ietfa.amsl.com>; Mon, 13 Feb 2017 05:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSo9q5zyiJOC for <6tisch@ietfa.amsl.com>; Mon, 13 Feb 2017 05:59:24 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20CE129582 for <6tisch@ietf.org>; Mon, 13 Feb 2017 05:59:21 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id c7so187046661itd.1 for <6tisch@ietf.org>; Mon, 13 Feb 2017 05:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zMT7GunrwpUwC7/lR6UfgucIrlR44MabIP5bsqu9b58=; b=UatGB72fZonftAd2+bZlEKbvZiZdLM56DVdS5gbWT2GKgx4Qe5cdpr9kUdHRom8Fxh imdECcGLaDt+rBS7kjQzUgtdWnLDoGCa52ZIgjkvn3gIUm9Og+hr8gC5PCtuN7TB9mKX HrO/QsnAttD2F5NdMmc+3NVx/Rg8z6A/Ehs2o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zMT7GunrwpUwC7/lR6UfgucIrlR44MabIP5bsqu9b58=; b=o4splDYUIrPTnml7AinKsk6/AKU10llSs/MdEsiD0WSbsnPr+r9kWjwowuWshl8aTT n2EqgVQFpHfhx8Hx1vY6hG0YfXTYIISK4LFGFcTzDbThurKQhbXIeZQF7aB+jsEomZrr YL75VI9dlQ9iAvJoWOW5PdBdYO9tz1RczlwWA9aFnm6aFwVLuioF5y8O2e0ADQXnKpuJ FP7YlTJ04unPVN/PRe9PkepmJP2H0xIbjdrLf1TXnUGrbiSZRCtS+PgyyAPpHrmoCsKK 3GLd87a8fTZe2buD3m2oqnpdGWydcJWkvwKos8O5XWdIN0a1s/9UkJ1NZupZxo1Iz8gQ 9vgQ== X-Gm-Message-State: AMke39mvc8Pco0SWt97KCKAdCPa2MHEZFyyl16vZ6pYUMtSLo1/8iXrx733Rqc/Rv1W0kc4LD2PdQaiDCgcqqDZo X-Received: by 10.36.6.199 with SMTP id 190mr20808427itv.79.1486994361041; Mon, 13 Feb 2017 05:59:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.46.13 with HTTP; Mon, 13 Feb 2017 05:59:20 -0800 (PST) In-Reply-To: <247631985.2094244.1486745732914.JavaMail.root@vilafranca.uoc.es> References: <247631985.2094244.1486745732914.JavaMail.root@vilafranca.uoc.es> From: Xavi Vilajosana Guillen Date: Mon, 13 Feb 2017 14:59:20 +0100 Message-ID: To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=001a113f77e4ac90a0054869da41 Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, tisch <6tisch@ietf.org>, Pascal Thubert , 6tisch-chairs@ietf.org, The IESG Subject: Re: [6tisch] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-6tisch-minimal-19=3A_=28with_COMMENT=29?= X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 13:59:26 -0000 --001a113f77e4ac90a0054869da41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Mirja, thanks so much for your review. We are integrating your comments to the next version of the draft. kind regards, Xavi 2017-02-10 17:46 GMT+01:00 Mirja Kuehlewind : > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-6tisch-minimal-19: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A couple of comments mostly on the use of normative language: > > 1) The following sentence contradict a little all other normative > language in this document (basically making everything a SHOULD): > "Any 6TiSCH compliant device SHOULD implement this mode of operation." > Why is this a upper case SHOULD? Is this sentence needed at all? > > 2) Here the usage of normative language is also not clear to me: > "The default values of the TSCH Timeslot template (defined in > [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence > (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. A > node > MAY use different values by properly announcing them in its Enhanced > Beacon." > > 3) Is it correct that these are SHOULDs? > "EB Destination Address field SHOULD be set to 0xFFFF (short broadcast > address). The EB Source Address field SHOULD be set as the node's > short address if this is supported. Otherwise the long address > SHOULD be used." > > 4) What the recommended value for EB_PERIOD?: > "In a minimal TSCH > configuration, a node SHOULD send an EB every EB_PERIOD." > > 5) This is also a weird SHOULD for me: > "EBs SHOULD be used to obtain information about local networks, ..." > What else should be used? Or you just don't obtain the information you > need. I actually guess that you should simply use a lower case should in > this sentence. > Should it be?: > "The default values of the TSCH Timeslot template (defined in > [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence > (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. If a > node > uses different values, it MUST properly announcing them in its > Enhanced > Beacon." > Or is this sentence just duplicating the SHOULD of the previous sentence > slightly differently? > > 6) Maybe also name the recommended values for MAX_EB_DELAY and > NUM_NEIGHBOURS_TO_WAIT in section 6.2 or give a forward reference to > section 7.3? > > 7) "At any time, a node MUST maintain connectivity to at least one time > source neighbor. " > How can you ensure that you can maintain connectivity? I guess this > must be a SHOULD... or what do you mean exactly by 'maintain > connectivity'? > > 8) I think this sentence is confusing given the recommended value for > NUM_UPPERLAYER_PACKETS is 1: > "One entry in the queue is reserved at all times for frames of type > BEACON." > I guess what you want to say it that if a BEACON should be send and there > is no space in the queue one frame should be drop and the BEACON should > be queued instead? > > 9) I'm a little surprised to not see anything about 6LoWPAN in the body > of the document (besides the intro in section 1). Shouldn't there also be > some normative language on the use of 6LoWPAN? > > One editorial comment (from the abstract): > I don't really understand this sentence > "A minimal mode of operation is a baseline set of protocols, ..." > I guess you want to say something like > "This minimal mode of operation specifies the baseline set of protocols > that need to be supported, .." > > > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --001a113f77e4ac90a0054869da41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Mirja,=C2=A0

thanks so much for yo= ur review. We are integrating your comments to the next version of the draf= t.

kind regards,
Xavi

2017-02-10 17:46 GMT+01:= 00 Mirja Kuehlewind <ietf@kuehlewind.net>:
Mirja K=C3=BChle= wind has entered the following ballot position for
draft-ietf-6tisch-minimal-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-6tisch-minimal/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

A couple of comments mostly on the use of normative language:

1) The following sentence contradict a little all other normative
language in this document (basically making everything a SHOULD):
"Any 6TiSCH compliant device SHOULD implement this mode of operation.&= quot;
Why is this a upper case SHOULD? Is this sentence needed at all?

2) Here the usage of normative language is also not clear to me:
"The default values of the TSCH Timeslot template (defined in
=C2=A0 =C2=A0[IEEE802154-2015]=C2=A0 section 8.4.2.2.3) and Channel Hopping= sequence
=C2=A0 =C2=A0(defined in [IEEE802154-2015] section 6.2.10) SHOULD be used.= =C2=A0 A
node
=C2=A0 =C2=A0MAY use different values by properly announcing them in its En= hanced
=C2=A0 =C2=A0Beacon."

3) Is it correct that these are SHOULDs?
"EB Destination Address field SHOULD be set to 0xFFFF (short broadcast=
=C2=A0 =C2=A0address).=C2=A0 The EB Source Address field SHOULD be set as t= he node's
=C2=A0 =C2=A0short address if this is supported.=C2=A0 Otherwise the long a= ddress
=C2=A0 =C2=A0SHOULD be used."

4) What the recommended value for EB_PERIOD?:
"In a minimal TSCH
=C2=A0 =C2=A0configuration, a node SHOULD send an EB every EB_PERIOD."=

5) This is also a weird SHOULD for me:
"EBs SHOULD be used to obtain information about local networks, ...&qu= ot;
What else should be used? Or you just don't obtain the information you<= br> need. I actually guess that you should simply use a lower case should in this sentence.
Should it be?:
"The default values of the TSCH Timeslot template (defined in
=C2=A0 =C2=A0[IEEE802154-2015]=C2=A0 section 8.4.2.2.3) and Channel Hopping= sequence
=C2=A0 =C2=A0(defined in [IEEE802154-2015] section 6.2.10) SHOULD be used.= =C2=A0 If a
node
=C2=A0 =C2=A0uses different values, it MUST properly announcing them in its=
Enhanced
=C2=A0 =C2=A0Beacon."
Or is this sentence just duplicating the SHOULD of the previous sentence slightly differently?

6) Maybe also name the recommended values for MAX_EB_DELAY and
NUM_NEIGHBOURS_TO_WAIT in section 6.2 or give a forward reference to
section 7.3?

7) "At any time, a node MUST maintain connectivity to at least one tim= e
=C2=A0 =C2=A0source neighbor. "
=C2=A0 How can you ensure that you can maintain connectivity? I guess this<= br> must be a SHOULD... or what do you mean exactly by 'maintain
connectivity'?

8) I think this sentence is confusing given the recommended value for
NUM_UPPERLAYER_PACKETS is 1:
"One entry in the queue is reserved at all times for frames of type BEACON."
I guess what you want to say it that if a BEACON should be send and there is no space in the queue one frame should be drop and the BEACON should
be queued instead?

9) I'm a little surprised to not see anything about 6LoWPAN in the body=
of the document (besides the intro in section 1). Shouldn't there also = be
some normative language on the use of 6LoWPAN?

One editorial comment (from the abstract):
I don't really understand this sentence
"A minimal mode of operation is a baseline set of protocols, ..."=
I guess you want to say something like
"This minimal mode of operation specifies the baseline set of protocol= s
that need to be supported, .."





--
=
Dr. Xavier VilajosanaWireless Networks Lab
Internet Interdisciplinary Institute (IN3)
= Professor

(+34) 646 633 681
xvilajosana@uoc.edu
http://xvilajosana.org=
http://wine.rdi.u= oc.edu
Parc = Mediterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Buildin= g
08860 Castelldefels (Barcelona). Catalonia. Spain
=
Dr. Xavier Vilajosan= a
Wireless Networks Lab
Internet Interdisciplinary Institut= e (IN3)
Professor

(+34) 646 633 681
xvilajosana@uoc.edu<= /a>
http://xvilajos= ana.org
http:/= /wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5,= B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
3D"Universitat=C2=A0=C2=A0
=C2=AD
--001a113f77e4ac90a0054869da41-- From nobody Mon Feb 13 07:52:55 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B864912966C; Mon, 13 Feb 2017 07:52:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148700117272.25009.9689541176199040975.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2017 07:52:52 -0800 Archived-At: Cc: 6tisch@ietf.org, 6tisch-chairs@ietf.org Subject: [6tisch] IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG Interim Meeting Cancelled (was 2017-02-17) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:52:53 -0000 The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) virtual interim meeting for 2017-02-17 from 07:00 to 08:00 America/Los_Angeles has been cancelled. From nobody Mon Feb 13 23:24:58 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCA51294A9 for <6tisch@ietfa.amsl.com>; Mon, 13 Feb 2017 23:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFEWcRJK7g-F for <6tisch@ietfa.amsl.com>; Mon, 13 Feb 2017 23:24:55 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A2F12947A for <6tisch@ietf.org>; Mon, 13 Feb 2017 23:24:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,160,1484002800"; d="scan'208,217";a="260323903" Received: from mail-ua0-f176.google.com ([209.85.217.176]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 14 Feb 2017 08:24:52 +0100 Received: by mail-ua0-f176.google.com with SMTP id 96so80655132uaq.3 for <6tisch@ietf.org>; Mon, 13 Feb 2017 23:24:52 -0800 (PST) X-Gm-Message-State: AMke39lHPyFeKcrcRgNN3+qrwHsKii1xqt/03kHu7pTi/M8lk6hIOVoSjl/q2/2mTosfqQTtUEEoXHcrYDR0Sw== X-Received: by 10.176.75.149 with SMTP id v21mr12977570uaf.94.1487057091675; Mon, 13 Feb 2017 23:24:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.160.148 with HTTP; Mon, 13 Feb 2017 23:24:31 -0800 (PST) In-Reply-To: <1486725677.4483.19.camel@uantwerpen.be> References: <1486634348.14367.14.camel@uantwerpen.be> <1486725677.4483.19.camel@uantwerpen.be> From: Thomas Watteyne Date: Tue, 14 Feb 2017 08:24:31 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Esteban Municio Content-Type: multipart/alternative; boundary=f40304361412b5d534054878758f Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] Recommended configuration for Shared cells Backoff in Minimal X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 07:24:57 -0000 --f40304361412b5d534054878758f Content-Type: text/plain; charset=UTF-8 Esteban, You are right, if a mote doesn't send anything else than EBs and DIOs (which are all sent to link-layer address 0xffff), it will not increase the BE value. It is only when the starts particpating in a join procedure, or exchanges application-level data that is will realize it doesn't receive an ACK and increase BE. I do believe that the duration after being switched on that a mote only sends EBs and DIOs is short. Thomas On Fri, Feb 10, 2017 at 12:21 PM, Esteban Municio < esteban.municio@uantwerpen.be> wrote: > Hi Thomas, > > No, that's exactly what I ment. > > I was just thinking about how the network would behave when for example > 20 o 30 nodes are switched on simultaneously in Minimal. If the initial > value of BE is low (1 or 2), collisions are expected to be very frequent > in the shared cell. And since the first messages for joining the network > (EBs and DIOs) are broadcasted without expecting an ACK, the BE could > remain unmodified and the joining process could last forever. > > Could this scenario happen? Or am I missing something important? > > But indeed maybe this is out of the scope of Minimal since is just > matter of sizing the number of shared cells in the schedule and the > topic is rather related with the 802.15.4 standard than with 6tisch. > > Kind regards, > Esteban > > > On Thu, 2017-02-09 at 23:46 +0000, Thomas Watteyne wrote: > > Esteban, > > > > > > I believe this is fully specified in the 802.15.4 standard. In a > > nutshell, the back-off mechanism is triggered only when the cell is > > marked as "shared". When a mote sends a packet and doesn't get an ACK, > > the BE is changed. If you send a frame to link-layer destination > > 0xffff, you're not expecting an ACK, so BE will not change. > > > > > > I may be missing your point? > > > > > > Thomas > > > > On Thu, Feb 9, 2017 at 10:59 AM, Esteban Municio > > wrote: > > Hi all, > > > > I was wondering if there is any recommendation about how set > > up the > > Backoff mechanism in shared cells when no ACKs are expected. > > > > According to the standard, macMaxBE and macMinBE are defined > > and the BE > > is increased at every attempt. However, if the node is not > > expecting any > > ACK (i.e sending DIOs or EBs), I guess the BE will be always > > the same. > > Is there any recommendation in Minimal about how to choose > > this value? > > > > Maybe a value related with the number of nodes or DIO/EB > > period? > > > > Kind regards, > > Esteban > > > > -- > > Esteban Municio > > IDLab - Dept. Mathematics and Computer Science > > University of Antwerp - imec > > Middelheimlaan 1 , 2020 Antwerp, Belgium > > Office M.G.325 > > > > _______________________________________________ > > 6tisch mailing list > > 6tisch@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > > -- > Esteban Municio > IDLab - Dept. Mathematics and Computer Science > University of Antwerp - imec > Middelheimlaan 1 , 2020 Antwerp, Belgium > Office M.G.325 > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --f40304361412b5d534054878758f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Esteban,

You are right, if a mote doesn= 't send anything else than EBs and DIOs (which are all sent to link-lay= er address 0xffff), it will not increase the BE value. It is only when the = starts particpating in a join procedure, or exchanges application-level dat= a that is will realize it doesn't receive an ACK and increase BE. I do = believe that the duration after being switched on that a mote only sends EB= s and DIOs is short.

Thomas

On Fri, Feb 10, 2017 at 12:= 21 PM, Esteban Municio <esteban.municio@uantwerpen.be><= /span> wrote:
Hi Thomas,

No, that's exactly what I ment.

I was just thinking about how the network would behave when for example
20 o 30 nodes are switched on simultaneously in Minimal. If the initial
value of BE is low (1 or 2), collisions are expected to be very frequent in the shared cell. And since the first messages for joining the network (EBs and DIOs) are broadcasted without expecting an ACK, the BE could
remain unmodified and the joining process could last forever.

Could this scenario happen? Or am I missing something important?

But indeed maybe this is out of the scope of Minimal since is just
matter of sizing the number of shared cells in the schedule and the
topic is rather related with the 802.15.4 standard than with 6tisch.

Kind regards,
Esteban


On Thu, 2017-02-09 at 23:46 +0000, Thomas Watteyne wrote:
> Esteban,
>
>
> I believe this is fully specified in the 802.15.4 standard. In a
> nutshell, the back-off mechanism is triggered only when the cell is > marked as "shared". When a mote sends a packet and doesn'= ;t get an ACK,
> the BE is changed. If you send a frame to link-layer destination
> 0xffff, you're not expecting an ACK, so BE will not change.
>
>
> I may be missing your point?
>
>
> Thomas
>
> On Thu, Feb 9, 2017 at 10:59 AM, Esteban Municio
> <esteban.municio@u= antwerpen.be> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Hi all,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I was wondering if there is any recom= mendation about how set
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0up the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Backoff mechanism in shared cells whe= n no ACKs are expected.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0According to the standard, macMaxBE a= nd macMinBE are defined
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the BE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is increased at every attempt. Howeve= r, if the node is not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0expecting any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACK (i.e sending DIOs or EBs), I gues= s the BE will be always
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the same.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is there any recommendation in Minima= l about how to choose
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this value?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Maybe a value related with the number= of nodes or DIO/EB
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0period?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kind regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Esteban
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Esteban Municio
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IDLab - Dept. Mathematics and Compute= r Science
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0University of Antwerp - imec
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Middelheimlaan 1 , 2020 Antwerp, Belg= ium
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Office M.G.325
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06tisch mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06t= isch@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.o= rg/mailman/listinfo/6tisch
>
>
>
>
>

--
Esteban Municio
IDLab - Dept. Mathematics and Computer Science
University of Antwerp - imec
Middelheimlaan 1 , 2020 Antwerp, Belgium
Office M.G.325



--
=
_______________________________________
=

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria<= /div>
Sr = Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley O= penWSN
Co-chair, IETF 6TiSCH

_____________= __________________________
--f40304361412b5d534054878758f-- From nobody Tue Feb 14 08:46:13 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3A51296BC; Tue, 14 Feb 2017 08:46:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148709076743.10094.4154261322690599569.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 08:46:07 -0800 Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, pthubert@cisco.com, 6tisch-chairs@ietf.org, 6tisch@ietf.org Subject: [6tisch] Kathleen Moriarty's Discuss on draft-ietf-6tisch-minimal-19: (with DISCUSS) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:46:07 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-6tisch-minimal-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for responding to the SecDir review, it looks like the updates needed are planned for the next version. There were a number of significant findings, so this placeholder is to make sure those happen (protocol and security). https://www.ietf.org/mail-archive/web/secdir/current/msg07162.html For some reason, the SecDir review isn't linked off of the document. From nobody Tue Feb 14 08:54:22 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B979A12968E for <6tisch@ietfa.amsl.com>; Tue, 14 Feb 2017 08:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTOrik2hdA3L for <6tisch@ietfa.amsl.com>; Tue, 14 Feb 2017 08:54:15 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F2D1296CF for <6tisch@ietf.org>; Tue, 14 Feb 2017 08:54:12 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id c7so39716464itd.1 for <6tisch@ietf.org>; Tue, 14 Feb 2017 08:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bjFHoARyq9xecVOZRSNJYn+6npqXz5RFAI0+YfdMB08=; b=HYCKR2ku9JcxvhErPnblbi63ySiCQHiu+wVozvZL3rtIGUX70avPqx9XCoKvxPnLXM ioBOZSR+Nu+VdevI1A0VcJpuJuX6NnahrygJyanjN7yxhe0p7lu8/WJYcXKA3UwtKdXA 9oGXxvdC5DWRq1RldSVBnmgN51mC/mYYhTsx4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bjFHoARyq9xecVOZRSNJYn+6npqXz5RFAI0+YfdMB08=; b=cc8vuMrle+sT6Ao/KxwW1ByMjmdAFFC3kEg8Ddyi26Js09jmLDETCRzzZPM/Zwdl2A Y2mfph4eFNbzeAbaYK8JinHAuktDlQ53gcn/655YV8iLiOaYRDg+KvXUn/g13f34NHdL WLi5AuW4DS0S003le67XoOIR1+71D5/0NDQXlVzY8GaHA+8a+dYsNSjl5bn9iOBXynBO 2KeEkK14tKHzkNbimcv3HdbK+m0B6matIvoUqcvN2BO3i6PHqil3AE8Bf83loOzbV4oX vmHUChx2pya2PVCnvOlEXoduWxA0qy7Qn93Y+/AYCjRrUc4S+c+HkAB7kVCf2HBLplUa hypw== X-Gm-Message-State: AMke39mDfitqQy1KY4SvH0fbvdmPaNAaNW56U6yNALulGkWvmzMq1GXjpFrtfb8x6CJSGvMlZ1fhmq0KQ1JZYBZ9 X-Received: by 10.107.204.8 with SMTP id c8mr30050516iog.160.1487091251244; Tue, 14 Feb 2017 08:54:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.30.200 with HTTP; Tue, 14 Feb 2017 08:54:10 -0800 (PST) In-Reply-To: <1757681415.308647.1486745246980.JavaMail.root@canet.uoc.es> References: <1757681415.308647.1486745246980.JavaMail.root@canet.uoc.es> From: Xavi Vilajosana Guillen Date: Tue, 14 Feb 2017 17:54:10 +0100 Message-ID: To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=94eb2c1bfb74c781630548806914 Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, tisch <6tisch@ietf.org>, Pascal Thubert , 6tisch-chairs@ietf.org, The IESG Subject: Re: [6tisch] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-6tisch-minimal-19=3A_=28with_COMMENT=29?= X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:54:17 -0000 --94eb2c1bfb74c781630548806914 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Mirja, thanks for your comments. Please find our answers inline. The version 20 of the draft will include the detailed changes. ---------------------------- Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-6tisch-minimal-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of comments mostly on the use of normative language: 1) The following sentence contradict a little all other normative language in this document (basically making everything a SHOULD): "Any 6TiSCH compliant device SHOULD implement this mode of operation." Why is this a upper case SHOULD? Is this sentence needed at all? -------------- ANSWER 1 The SHOULD will be lower cased as per other reviews received as well. -------------- 2) Here the usage of normative language is also not clear to me: "The default values of the TSCH Timeslot template (defined in [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. A node MAY use different values by properly announcing them in its Enhanced Beacon." -------------- ANSWER 2 Well, we recommend the use of default values with the SHOULD. If someone wants to use different values then those need to be announced in the EB. -------------- 3) Is it correct that these are SHOULDs? "EB Destination Address field SHOULD be set to 0xFFFF (short broadcast address). The EB Source Address field SHOULD be set as the node's short address if this is supported. Otherwise the long address SHOULD be used." -------------- ANSWER 3 As per another reviewer comment the second SHOULD has been turned into a MUST. -------------- 4) What the recommended value for EB_PERIOD?: "In a minimal TSCH configuration, a node SHOULD send an EB every EB_PERIOD." -------------- ANSWER 4 We discussed this in the ML and during WG calls multiple times. We cannot state a value as this depends on the particular network, slotframe size, energy consumption requirements, limitations in network formation time, etc... We say here that there is a period for sending EBs. -------------- 5) This is also a weird SHOULD for me: "EBs SHOULD be used to obtain information about local networks, ..." What else should be used? Or you just don't obtain the information you need. I actually guess that you should simply use a lower case should in this sentence. Should it be?: "The default values of the TSCH Timeslot template (defined in [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. If a node uses different values, it MUST properly announcing them in its Enhanced Beacon." Or is this sentence just duplicating the SHOULD of the previous sentence slightly differently? -------------- ANSWER 5 The EB is used to announce the network, distribute the initial configuration and provide a synchronization mechanism until the nodes have not been authenticated. The first SHOULD has been turned into lower cased as suggested. -------------- 6) Maybe also name the recommended values for MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT in section 6.2 or give a forward reference to section 7.3? -------------- ANSWER 6 Thanks this has been done. -------------- 7) "At any time, a node MUST maintain connectivity to at least one time source neighbor. " How can you ensure that you can maintain connectivity? I guess this must be a SHOULD... or what do you mean exactly by 'maintain connectivity'? -------------- ANSWER 7 We propose to change connectivity by synchronization. Losing synchronization means losing the possibility to communicate with the network and forces a node to join again. This will also be stated. -------------- 8) I think this sentence is confusing given the recommended value for NUM_UPPERLAYER_PACKETS is 1: "One entry in the queue is reserved at all times for frames of type BEACON." I guess what you want to say it that if a BEACON should be send and there is no space in the queue one frame should be drop and the BEACON should be queued instead? -------------- ANSWER 8 Thanks, this has been corrected as suggested by the reviewer. -------------- 9) I'm a little surprised to not see anything about 6LoWPAN in the body of the document (besides the intro in section 1). Shouldn't there also be some normative language on the use of 6LoWPAN? -------------- ANSWER 9 Minimal provides a configuration to bootstrap the network. 6LoWPAN framework is used unmodified. -------------- One editorial comment (from the abstract): I don't really understand this sentence "A minimal mode of operation is a baseline set of protocols, ..." I guess you want to say something like "This minimal mode of operation specifies the baseline set of protocols that need to be supported, .." -------------- ANSWER 10 Thanks, this has been also modified according to the comment. -------------- =C2=AD --94eb2c1bfb74c781630548806914 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Mirja,

thanks for y= our comments. Please find our answers inline. The version 20 of the draft w= ill include the detailed changes.
-------------------= ---------

Mirja K=C3=BChle= wind has entered the following ballot position for
dr= aft-ietf-6tisch-minimal-19: No Objection

When responding, please keep the subject line intact and rep= ly to all
email addresses included in the To and CC l= ines. (Feel free to cut this
introductory paragraph, = however.)


for more information about IESG DISCUSS and = COMMENT positions.


The document, along with other ballot positions, can be= found here:


<= /div>

--------------------------= --------------------------------------------
COMMENT:=
----------------------------------------------------= ------------------

A coupl= e of comments mostly on the use of normative language:

1) The following sentence contradict a little = all other normative
language in this document (basica= lly making everything a SHOULD):
"Any 6TiSCH com= pliant device SHOULD implement this mode of operation."
Why is this a upper case SHOULD? Is this sentence needed at all?= =C2=A0

--------------
ANSWER 1

The SHOULD will be lower cased as per other reviews received as well.=C2= =A0
--------------

2) Here the usage of normative language is also not clear to= me:
"The default values of the TSCH Timeslot te= mplate (defined in
=C2=A0 =C2=A0[IEEE802154-2015] =C2= =A0section 8.4.2.2.3) and Channel Hopping sequence
= =C2=A0 =C2=A0(defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. = =C2=A0A
node
=C2=A0 =C2=A0MAY u= se different values by properly announcing them in its Enhanced
=C2=A0 =C2=A0Beacon."

--------------
ANSWER 2

Well, we recommend the use of default value= s with the SHOULD. If someone wants to use different values then those need= to be announced in the EB.=C2=A0
--------------

3) Is it correct that these ar= e SHOULDs?
"EB Destination Address field SHOULD = be set to 0xFFFF (short broadcast
=C2=A0 =C2=A0addres= s).=C2=A0 The EB Source Address field SHOULD be set as the node's
=
=C2=A0 =C2=A0short address if this is supported.=C2=A0 Oth= erwise the long address
=C2=A0 =C2=A0SHOULD be used.&= quot;

--------------
=
ANSWER 3

= As per another reviewer comment the second SHOULD has been turned into a MU= ST.=C2=A0
--------------

4) What the recommended value for EB_PERIOD?:
"In a minimal TSCH
=C2=A0 =C2=A0co= nfiguration, a node SHOULD send an EB every EB_PERIOD."

--------------
AN= SWER 4

We discussed this i= n the ML and during WG calls multiple times. We cannot state a value as thi= s depends on the particular network, slotframe size, energy consumption req= uirements, limitations in network formation time, etc...=C2=A0 We say here = that there is a period for sending EBs.
-------------= -

5) This is also a weird = SHOULD for me:
"EBs SHOULD be used to obtain inf= ormation about local networks, ..."
What else sh= ould be used? Or you just don't obtain the information you
need. I actually guess that you should simply use a lower case sh= ould in
this sentence.
Should i= t be?:
"The default values of the TSCH Timeslot = template (defined in
=C2=A0 =C2=A0[IEEE802154-2015] = =C2=A0section 8.4.2.2.3) and Channel Hopping sequence
=C2=A0 =C2=A0(defined in [IEEE802154-2015] section 6.2.10) SHOULD be used.= =C2=A0 If a
node
=C2=A0 =C2=A0u= ses different values, it MUST properly announcing them in its
Enhanced
=C2=A0 =C2=A0Beacon."
Or is this sentence just duplicating the SHOULD of the previo= us sentence
slightly differently?

--------------
ANSWER 5=

The EB is used to announc= e the network, distribute the initial configuration and provide a synchroni= zation mechanism until the nodes have not been authenticated. The first SHO= ULD has been turned into lower cased as suggested.=C2=A0
--------------

6) Mayb= e also name the recommended values for MAX_EB_DELAY and
NUM_NEIGHBOURS_TO_WAIT in section 6.2 or give a forward reference to
section 7.3?

--------------
ANSWER 6
<= br>
Thanks this has been done.=C2=A0
--------------

7) &q= uot;At any time, a node MUST maintain connectivity to at least one time
=C2=A0 =C2=A0source neighbor. "
=C2=A0 How can you ensure that you can maintain connectivity? I guess th= is
must be a SHOULD... or what do you mean exactly by= 'maintain
connectivity'?

--------------
ANSWER 7=

We propose to change conn= ectivity by synchronization. Losing synchronization means losing the possib= ility to communicate with the network and forces a node to join again. This= will also be stated.=C2=A0
--------------

8) I think this sentence is confusin= g given the recommended value for
NUM_UPPERLAYER_PACK= ETS is 1:
"One entry in the queue is reserved at= all times for frames of type
BEACON."
I guess what you want to say it that if a BEACON should be sen= d and there
is no space in the queue one frame should= be drop and the BEACON should
be queued instead?

--------------
ANSWER 8

Thanks, = this has been corrected as suggested by the reviewer.
--------------

9) I'm= a little surprised to not see anything about 6LoWPAN in the body
of the document (besides the intro in section 1). Shouldn'= t there also be
some normative language on the use of= 6LoWPAN?

--------------
ANSWER 9

Minimal provides a configuration to bootstrap the network. 6LoWPAN fram= ework is used unmodified.
--------------

One editorial comment (from the abstra= ct):
I don't really understand this sentence
"A minimal mode of operation is a baseline set of pr= otocols, ..."
I guess you want to say something = like
"This minimal mode of operation specifies t= he baseline set of protocols
that need to be supporte= d, .."

--------------=
ANSWER 10

Thanks, this has been also modified according to the comment.
--------------
= =C2=AD
--94eb2c1bfb74c781630548806914-- From nobody Tue Feb 14 08:55:27 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C8112951B; Tue, 14 Feb 2017 08:55:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148709132568.9993.15468295547274729188.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2017 08:55:25 -0800 Archived-At: Cc: 6tisch@ietf.org Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-20.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:55:26 -0000 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 of the IETF. Title : Minimal 6TiSCH Configuration Authors : Xavier Vilajosana Kris Pister Thomas Watteyne Filename : draft-ietf-6tisch-minimal-20.txt Pages : 27 Date : 2017-02-14 Abstract: This document describes a minimal mode of operation for a 6TiSCH Network. This minimal mode of operation specifies the baseline set of protocols that need to be supported, recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time Synchronized Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the 6LoWPAN framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrap, and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH compliant devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6tisch-minimal-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-20 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 15 02:38:28 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99C21294E1 for <6tisch@ietfa.amsl.com>; Wed, 15 Feb 2017 02:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbQRo5WFxNut for <6tisch@ietfa.amsl.com>; Wed, 15 Feb 2017 02:38:24 -0800 (PST) Received: from mail.uantwerpen.be (ex02.uantwerpen.be [143.169.229.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A381294D8 for <6tisch@ietf.org>; Wed, 15 Feb 2017 02:38:22 -0800 (PST) Received: from EX04.ad.ua.ac.be (143.169.229.25) by ex02.ad.ua.ac.be (143.169.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Wed, 15 Feb 2017 11:38:18 +0100 Received: from orion (143.169.229.21) by EX04.ad.ua.ac.be (143.169.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Wed, 15 Feb 2017 11:38:18 +0100 Message-ID: <1487155096.29205.0.camel@uantwerpen.be> From: Esteban Municio To: Thomas Watteyne Date: Wed, 15 Feb 2017 11:38:16 +0100 In-Reply-To: <6d135c38bfa04190813cc72dcdd08251@CAS02.ad.ua.ac.be> References: <1486634348.14367.14.camel@uantwerpen.be> <1486725677.4483.19.camel@uantwerpen.be> <6d135c38bfa04190813cc72dcdd08251@CAS02.ad.ua.ac.be> Organization: UAntwerp Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-vos10yxYQDVBDJtGSlm6" X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-Originating-IP: [143.169.229.21] X-ClientProxiedBy: ex02.ad.ua.ac.be (143.169.229.23) To EX04.ad.ua.ac.be (143.169.229.25) Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] Recommended configuration for Shared cells Backoff in Minimal X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 10:38:27 -0000 --=-vos10yxYQDVBDJtGSlm6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,=20 Ok, I understand. Thanks and kind regards, Esteban On Tue, 2017-02-14 at 07:24 +0000, Thomas Watteyne wrote: > Esteban,=20 >=20 >=20 > You are right, if a mote doesn't send anything else than EBs and DIOs > (which are all sent to link-layer address 0xffff), it will not > increase the BE value. It is only when the starts particpating in a > join procedure, or exchanges application-level data that is will > realize it doesn't receive an ACK and increase BE. I do believe that > the duration after being switched on that a mote only sends EBs and > DIOs is short. >=20 >=20 > Thomas >=20 > On Fri, Feb 10, 2017 at 12:21 PM, Esteban Municio > wrote: > Hi Thomas, > =20 > No, that's exactly what I ment. > =20 > I was just thinking about how the network would behave when > for example > 20 o 30 nodes are switched on simultaneously in Minimal. If > the initial > value of BE is low (1 or 2), collisions are expected to be > very frequent > in the shared cell. And since the first messages for joining > the network > (EBs and DIOs) are broadcasted without expecting an ACK, the > BE could > remain unmodified and the joining process could last forever. > =20 > Could this scenario happen? Or am I missing something > important? > =20 > But indeed maybe this is out of the scope of Minimal since is > just > matter of sizing the number of shared cells in the schedule > and the > topic is rather related with the 802.15.4 standard than with > 6tisch. > =20 > Kind regards, > Esteban > =20 > =20 > On Thu, 2017-02-09 at 23:46 +0000, Thomas Watteyne wrote: > > Esteban, > > > > > > I believe this is fully specified in the 802.15.4 standard. > In a > > nutshell, the back-off mechanism is triggered only when the > cell is > > marked as "shared". When a mote sends a packet and doesn't > get an ACK, > > the BE is changed. If you send a frame to link-layer > destination > > 0xffff, you're not expecting an ACK, so BE will not change. > > > > > > I may be missing your point? > > > > > > Thomas > > > > On Thu, Feb 9, 2017 at 10:59 AM, Esteban Municio > > wrote: > > Hi all, > > > > I was wondering if there is any recommendation about > how set > > up the > > Backoff mechanism in shared cells when no ACKs are > expected. > > > > According to the standard, macMaxBE and macMinBE are > defined > > and the BE > > is increased at every attempt. However, if the node > is not > > expecting any > > ACK (i.e sending DIOs or EBs), I guess the BE will > be always > > the same. > > Is there any recommendation in Minimal about how to > choose > > this value? > > > > Maybe a value related with the number of nodes or > DIO/EB > > period? > > > > Kind regards, > > Esteban > > > > -- > > Esteban Municio > > IDLab - Dept. Mathematics and Computer Science > > University of Antwerp - imec > > Middelheimlaan 1 , 2020 Antwerp, Belgium > > Office M.G.325 > > > =20 > > _______________________________________________ > > 6tisch mailing list > > 6tisch@ietf.org > > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > =20 > -- > Esteban Municio > IDLab - Dept. Mathematics and Computer Science > University of Antwerp - imec > Middelheimlaan 1 , 2020 Antwerp, Belgium > Office M.G.325 > =20 >=20 >=20 >=20 >=20 --=20 Esteban Municio IDLab - Dept. Mathematics and Computer Science=20 University of Antwerp - imec Middelheimlaan 1 , 2020 Antwerp, Belgium=20 Office M.G.325=20 --=-vos10yxYQDVBDJtGSlm6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJYpC+YAAoJEIEjyYKR6zqcxp8IAJOvnuA9BtH6eSSqo2FdQjmi tlqdBGRKLyQj17mTsR3Pwwpqr1KXfoWigjB1SP9jR6jFKSpeSqKXxUg7UzhDaCVI Sl16zSgFQ+x+VNJMLOdj4leTQhDxP7LXqwuDMcx46PVZRCyc7tQs1+1CKx97fD4R ofKCQzmcTnSdoEPvKF3xQCASEAb0FHqIO/RBenhj0E3yxmh00A/R8eEpklzyFWtC zEM9TqtSlILRNEcG5dUhyRaJ6ZeDsgd45iZQRRoLTxU2K2ggjH7imz8sG3vXnWao /euEG/UO9EvVAZJwGQbrgKZL1d1nD8N0Fmmu6Nl40+60cp6/5k35qAPzJhrn+7o= =NXTy -----END PGP SIGNATURE----- --=-vos10yxYQDVBDJtGSlm6-- From nobody Wed Feb 15 19:08:11 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73341129C86; Wed, 15 Feb 2017 19:08:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148721448546.31610.16715182649387702192.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 19:08:05 -0800 Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, pthubert@cisco.com, 6tisch-chairs@ietf.org, 6tisch@ietf.org Subject: [6tisch] Ben Campbell's No Objection on draft-ietf-6tisch-minimal-20: (with COMMENT) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 03:08:05 -0000 Ben Campbell has entered the following ballot position for draft-ietf-6tisch-minimal-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Substantive Comments -- Section 4, 2nd paragraph, "A node MAY use different values": Is that intended to weaken the RECOMMENDED in the previous sentence? (If not, then is the MAY needed at all?) -- 4.5.1, first 3 paragraphs: Why are the SHOULDs not MUSTs? Can you articulate why it might be reasonable to make other choices? -- 4.5.2, 3rd paragraph, "It MAY be necessary..." That seems like a statement of fact. Please consider non-2119 language. --- 4th paragraph: It's not clear to me if the MUST in "MUST be sent as per the 802.15.4 specification..." is constraining options from that specification, or just referring to requirements that exists in that specification. If the latter, please consider descriptive rather than normative language. (e.g. "The 802.15.4 specification requires...." -- 6.1, 3rd paragraph: Why is the SHOULD not a MUST? When might it make sense not to follow those rules? - Editorial Comments -- Abstract: Please expand 6TICH on first mention From nobody Thu Feb 16 02:51:23 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFAC129482; Thu, 16 Feb 2017 02:51:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148724227757.15909.7624374351935108197.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 02:51:17 -0800 Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, pthubert@cisco.com, 6tisch-chairs@ietf.org, 6tisch@ietf.org Subject: [6tisch] Benoit Claise's No Objection on draft-ietf-6tisch-minimal-20: (with COMMENT) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 10:51:17 -0000 Benoit Claise has entered the following ballot position for draft-ietf-6tisch-minimal-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While reading, I frowned upon the same MAY & RPL issue as mentioned by Alvaro: The Introduction mentions that "RPL is specified to provide the framework for time synchronization in an 802.15.4 TSCH network.", but Section 5 (RPL Settings) makes it optional: "In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used." From nobody Mon Feb 20 02:08:58 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0051299AD for <6tisch@ietfa.amsl.com>; Mon, 20 Feb 2017 02:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh8d4oGwAaBB for <6tisch@ietfa.amsl.com>; Mon, 20 Feb 2017 02:08:54 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313341299A7 for <6tisch@ietf.org>; Mon, 20 Feb 2017 02:08:54 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id g18so23776077ioe.0 for <6tisch@ietf.org>; Mon, 20 Feb 2017 02:08:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vxwZJF8QEGEwMcaMv4xtrYnFqwk43VZwehUeSRNMWXU=; b=Lyb6ORZSsylmuPAih7OzD7f3um9cGjZepMT1yBXeaasZVISwVzlE240JCZiJiipqeC Fh08PX34n5ddK1Hdc9spZY9Tw+DFKRCnzioP9V01mBtGybIgk2ak27TAgOLRy5hXtDdi O76FOgl08HqPvS3YOLHb/wiQaEzvXwYnVJoqo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vxwZJF8QEGEwMcaMv4xtrYnFqwk43VZwehUeSRNMWXU=; b=DPj1oaJN+wIqSlWDxZaHKs07j+7YyGmXAtWEou3g2r6zS7w7/AZlcZ/vQ59B/UOHQ6 7C1NGRFek1H13TJYSWumiARvjMTWRL2im6pXA+U0OrHf58h8LskyW/pSYsYs6RIc47IZ 17OGq/xBRAtrAe//13y1uFEpOQzGVhA3mQlV/J3hN2aS7DYdHwFYfKsoqAQ90sI9+Fvp wLkvMfBXa55vgWk44D332De+9/BZf2BqmeIbOupwqL6CueCwNxs985XTmdvQIsKTUatB mjJY6xDMbBX7cvg+s0JglaO1hH94gBqBIzoJnKdnQTsymtTL0Orb9Or5IAlGsxvyjNlw mS7w== X-Gm-Message-State: AMke39l9mUCacfR6CurdrAPurxOcg1Rxte7izb1fh2el5TWNo1JxOUpcATTIVczuU8oVRMn0E+ROdkjcCv1KwzOo X-Received: by 10.107.204.8 with SMTP id c8mr17837280iog.160.1487585333387; Mon, 20 Feb 2017 02:08:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.30.200 with HTTP; Mon, 20 Feb 2017 02:08:52 -0800 (PST) In-Reply-To: <1525781201.1113262.1487214907423.JavaMail.root@vilafranca.uoc.es> References: <1525781201.1113262.1487214907423.JavaMail.root@vilafranca.uoc.es> From: Xavi Vilajosana Guillen Date: Mon, 20 Feb 2017 11:08:52 +0100 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c1bfb745eb97d0548f3738a Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, tisch <6tisch@ietf.org>, Pascal Thubert , 6tisch-chairs@ietf.org, The IESG Subject: Re: [6tisch] Ben Campbell's No Objection on draft-ietf-6tisch-minimal-20: (with COMMENT) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 10:08:56 -0000 --94eb2c1bfb745eb97d0548f3738a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Ben, I am preparing answers for your comments. I will respond asap. kind regards, Xavi 2017-02-16 4:08 GMT+01:00 Ben Campbell : > Ben Campbell has entered the following ballot position for > draft-ietf-6tisch-minimal-20: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - Substantive Comments > > -- Section 4, 2nd paragraph, "A node MAY use different values": Is that > intended to weaken the RECOMMENDED in the previous sentence? (If not, > then is the MAY needed at all?) > > -- 4.5.1, first 3 paragraphs: Why are the SHOULDs not MUSTs? Can you > articulate why it might be reasonable to make other choices? > > -- 4.5.2, 3rd paragraph, "It MAY be necessary..." > That seems like a statement of fact. Please consider non-2119 language. > > --- 4th paragraph: It's not clear to me if the MUST in "MUST be sent as > per the 802.15.4 specification..." is constraining options from that > specification, or just referring to requirements that exists in that > specification. If the latter, please consider descriptive rather than > normative language. (e.g. "The 802.15.4 specification requires...." > > -- 6.1, 3rd paragraph: Why is the SHOULD not a MUST? When might it make > sense not to follow those rules? > > > - Editorial Comments > > -- Abstract: Please expand 6TICH on first mention > > > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --94eb2c1bfb745eb97d0548f3738a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Ben,

I am preparing answers for yo= ur comments. I will respond asap.

kind regards,Xavi

= 2017-02-16 4:08 GMT+01:00 Ben Campbell <ben@nostrum.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Ben C= ampbell has entered the following ballot position for
draft-ietf-6tisch-minimal-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-6tisch-minimal/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

- Substantive Comments

-- Section 4, 2nd paragraph, "A node MAY use different values": I= s that
intended to weaken the RECOMMENDED in the previous sentence? (If not,
then is the MAY needed at all?)

-- 4.5.1, first 3 paragraphs: Why are the SHOULDs not MUSTs? Can you
articulate why it might be reasonable to make other choices?

-- 4.5.2, 3rd paragraph, "It MAY be necessary..."
That seems like a statement of fact. Please consider non-2119 language.

--- 4th paragraph: It's not clear to me if the MUST in "MUST be se= nt as
per the 802.15.4 specification..." is constraining options from that specification, or just referring to requirements that exists in that
specification. If the latter, please consider descriptive rather than
normative language. (e.g. "The 802.15.4 specification requires....&quo= t;

-- 6.1, 3rd paragraph: Why is the SHOULD not a MUST? When might it make
sense not to follow those rules?


- Editorial Comments

-- Abstract: Please expand 6TICH on first mention





--
=
=
Dr. Xavier Vilajosan= a
Wireless Networks Lab
Internet Interdisciplinary Institut= e (IN3)
Professor

(+34) 646 633 681
xvilajosana@uoc.edu<= /a>
http://xvilajos= ana.org
http:/= /wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5,= B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
3D"Universitat=C2=A0=C2=A0
=C2=AD
--94eb2c1bfb745eb97d0548f3738a-- From nobody Mon Feb 20 08:00:54 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589C91296B7 for <6tisch@ietfa.amsl.com>; Mon, 20 Feb 2017 08:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1cqZSWrlwZi for <6tisch@ietfa.amsl.com>; Mon, 20 Feb 2017 08:00:43 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09F71296C1 for <6tisch@ietf.org>; Mon, 20 Feb 2017 08:00:42 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id d9so25765822itc.0 for <6tisch@ietf.org>; Mon, 20 Feb 2017 08:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xKHfgx5iougeaPGUi9covwVFsLNIZzLi/cz5hSvSfeY=; b=BX0jtBOloHO3Grjjv6gA6aUezgrXqNY4NtyHFMk1IHhtaYt87yUFf4I8cOlFt1a3Vr Is7CfQSUg5AKsDdg43L4gPC095GbtUBC4FKPT85KrMY249bNaNbtCX0Hhge9IV/59xzy DsHaGba3GhwonjiXEEDjBxdK5YDXIbKaThYhM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xKHfgx5iougeaPGUi9covwVFsLNIZzLi/cz5hSvSfeY=; b=PVnE1JC+aydlckSz/ZSoylDAYHDwuK2+PCHt6UhiLTJeWBqHtNqcwKVmYX1MDoBWIg WwHobzKuc/JlVpT4oI0L3uY+gguCqVFz1hPr/ZGF1rpLhXER8gzIKRCNQQSzKckWVZQK r016ygyey3kU/JVshJ2GR+cZqDsiirfl/9VvzztV71Yuvr4rVR/RgAq6MILCJ92WtXHL 8qAzFt00E5n4NZI7jDKDslEH+LEAgbU5Hju2oqNnFuOJRiQNVd4xFu9xktgOKurqpAKG OJeB6Ajy9PtkoIA+RC12dAQVFH2LIkRJCiorrHlYDWCqoUNnfo6kDzwSwam70o5lTVYN 0iUA== X-Gm-Message-State: AMke39ktzvqjnX2YEGfqwH/hkeWLXCdgWbuXkk8gHy1299diIaDvHikhgwgylujWOFLJUs183/7+mrO2eIGmT43V X-Received: by 10.36.20.1 with SMTP id 1mr13076628itg.121.1487606441987; Mon, 20 Feb 2017 08:00:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.30.200 with HTTP; Mon, 20 Feb 2017 08:00:41 -0800 (PST) In-Reply-To: <2002882755.94962.1487585375593.JavaMail.root@llavaneres.uoc.es> References: <1525781201.1113262.1487214907423.JavaMail.root@vilafranca.uoc.es> <2002882755.94962.1487585375593.JavaMail.root@llavaneres.uoc.es> From: Xavi Vilajosana Guillen Date: Mon, 20 Feb 2017 17:00:41 +0100 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=001a1143e5208a78db0548f85da4 Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, tisch <6tisch@ietf.org>, Pascal Thubert , 6tisch-chairs@ietf.org, The IESG Subject: Re: [6tisch] Ben Campbell's No Objection on draft-ietf-6tisch-minimal-20: (with COMMENT) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 16:00:47 -0000 --001a1143e5208a78db0548f85da4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Ben, see inline the responses to your comments. Thanks so much for the review. We will post a new version with the responses to your comments later today. ---- Ben Campbell has entered the following ballot position for draft-ietf-6tisch-minimal-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Substantive Comments -- Section 4, 2nd paragraph, "A node MAY use different values": Is that intended to weaken the RECOMMENDED in the previous sentence? (If not, then is the MAY needed at all?) ---------------------------------------------------------------------- ANSWER: The sentence has been removed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- 4.5.1, first 3 paragraphs: Why are the SHOULDs not MUSTs? Can you articulate why it might be reasonable to make other choices? ---------------------------------------------------------------------- ANSWER: The 2 first SHOULD have been changed to MUST. The last SHOULD is kept as SHOULD as the PANID compression fields have different valid configurations that SHOULD be supported. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- 4.5.2, 3rd paragraph, "It MAY be necessary..." That seems like a statement of fact. Please consider non-2119 language. ---------------------------------------------------------------------- ANSWER: The sentence has been reworded as: "During the joining process, before secure connections to time parents have been created, a node MAY maintain synchronization using EBs." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- --- 4th paragraph: It's not clear to me if the MUST in "MUST be sent as per the 802.15.4 specification..." is constraining options from that specification, or just referring to requirements that exists in that specification. If the latter, please consider descriptive rather than normative language. (e.g. "The 802.15.4 specification requires...." ---------------------------------------------------------------------- ANSWER: The text has been rephrased: The IEEE Std 802.15.4 specification requires EBs to be send in order to enable nodes to join the network. The EBs SHOULD carry the Information Elements (IEs) listed below" ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- 6.1, 3rd paragraph: Why is the SHOULD not a MUST? When might it make sense not to follow those rules? ---------------------------------------------------------------------- ANSWER: SHOULD has been changed by a MUST. We though in supporting other mechanisms at some point. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Editorial Comments -- Abstract: Please expand 6TICH on first mention ---------------------------------------------------------------------- ANSWER: Thanks, this has been corrected. 2017-02-20 11:08 GMT+01:00 Xavi Vilajosana Guillen : > Dear Ben, > > I am preparing answers for your comments. I will respond asap. > > kind regards, > Xavi > > 2017-02-16 4:08 GMT+01:00 Ben Campbell : > >> Ben Campbell has entered the following ballot position for >> draft-ietf-6tisch-minimal-20: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> - Substantive Comments >> >> -- Section 4, 2nd paragraph, "A node MAY use different values": Is that >> intended to weaken the RECOMMENDED in the previous sentence? (If not, >> then is the MAY needed at all?) >> >> -- 4.5.1, first 3 paragraphs: Why are the SHOULDs not MUSTs? Can you >> articulate why it might be reasonable to make other choices? >> >> -- 4.5.2, 3rd paragraph, "It MAY be necessary..." >> That seems like a statement of fact. Please consider non-2119 language. >> >> --- 4th paragraph: It's not clear to me if the MUST in "MUST be sent as >> per the 802.15.4 specification..." is constraining options from that >> specification, or just referring to requirements that exists in that >> specification. If the latter, please consider descriptive rather than >> normative language. (e.g. "The 802.15.4 specification requires...." >> >> -- 6.1, 3rd paragraph: Why is the SHOULD not a MUST? When might it make >> sense not to follow those rules? >> >> >> - Editorial Comments >> >> -- Abstract: Please expand 6TICH on first mention >> >> >> > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3)Professor* > (+34) 646 633 681 <+34%20646%2063%2036%2081> > xvilajosana@uoc.edu > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > 08860 Castelldefels (Barcelona). Catalonia. Spain > [image: Universitat Oberta de Catalunya] > =C2=AD > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --001a1143e5208a78db0548f85da4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Ben,

see inline the responses to y= our comments. Thanks so much for the review. We will post a new version wit= h the responses to your comments later today.

----=
Ben Campbell has entered the following ballot position for<= /div>
draft-ietf-6tisch-minimal-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut = this
introductory paragraph, however.)

<= br>
for more information about IESG DISCUSS and COMMENT p= ositions.


The document, along with = other ballot positions, can be found here:

-----------= -----------------------------------------------------------
COMME= NT:
-------------------------------------------------------------= ---------

- Substantive Comments

-- Section 4, 2nd paragraph, "A node MAY use different values&= quot;: Is that
intended to weaken the RECOMMENDED in the previous= sentence? (If not,
then is the MAY needed at all?)
---------------------------------------------------------------= -------
ANSWER:
The sentence has been removed.

----------------------------------------------------------= ------------
COMMENT:
---------------------------------= -------------------------------------
-- 4.5.1, first 3 paragraph= s: Why are the SHOULDs not MUSTs? Can you
articulate why it might= be reasonable to make other choices?
---------------------------= -------------------------------------------
ANSWER:
The 2 first SHOULD have been changed to MUST. The last SHOULD i= s kept as SHOULD as the PANID compression fields have different valid confi= gurations that SHOULD be supported.

--------------= --------------------------------------------------------
COMMENT:=
----------------------------------------------------------------= ------
-- 4.5.2, 3rd paragraph, "It MAY be necessary..."= ;
That seems like a statement of fact. Please consider non-2119 l= anguage.
--------------------------------------------------------= --------------
ANSWER:

The sentence has = been reworded as:
"During the joining process, before secure= connections to time parents have been created, a node MAY maintain synchro= nization using EBs."

------------------------= ----------------------------------------------
COMMENT:
----------------------------------------------------------------------
--- 4th paragraph: It's not clear to me if the MUST in "MUS= T be sent as
per the 802.15.4 specification..." is constrain= ing options from that
specification, or just referring to require= ments that exists in that
specification. If the latter, please co= nsider descriptive rather than
normative language. (e.g. "Th= e 802.15.4 specification requires...."
---------------------= -------------------------------------------------
ANSWER:
The text has been rephrased:
The IEEE Std 802.15.4 specificati= on requires EBs to be send in order to enable nodes to join the network. Th= e EBs SHOULD carry the Information Elements (IEs) listed below"
<= div>
--------------------------------------------------------= --------------
COMMENT:
-------------------------------= ---------------------------------------
-- 6.1, 3rd paragraph: Wh= y is the SHOULD not a MUST? When might it make
sense not to follo= w those rules?
--------------------------------------------------= --------------------
ANSWER:

SHOULD has = been changed by a MUST. We though in supporting other mechanisms at some po= int.=C2=A0

---------------------------------------= -------------------------------
COMMENT:
--------------= --------------------------------------------------------
- Editor= ial Comments

-- Abstract: Please expand 6TICH on f= irst mention
----------------------------------------------------= ------------------
ANSWER:

Thanks, this = has been corrected.

2017-02-20 11:08 GMT+01:00 Xavi Vilajosana Guillen <= xvilajosana@uoc.edu>:
Dear Ben,

I am preparing an= swers for your comments. I will respond asap.

kind= regards,
Xavi

2017-02-16 4:08 GMT+01:00 Ben Campbell = <= ben@nostrum.com>:
Ben Campbell has entered the following ballot= position for
draft-ietf-6tisch-minimal-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-6tisch-minimal/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

- Substantive Comments

-- Section 4, 2nd paragraph, "A node MAY use different values": I= s that
intended to weaken the RECOMMENDED in the previous sentence? (If not,
then is the MAY needed at all?)

-- 4.5.1, first 3 paragraphs: Why are the SHOULDs not MUSTs? Can you
articulate why it might be reasonable to make other choices?

-- 4.5.2, 3rd paragraph, "It MAY be necessary..."
That seems like a statement of fact. Please consider non-2119 language.

--- 4th paragraph: It's not clear to me if the MUST in "MUST be se= nt as
per the 802.15.4 specification..." is constraining options from that specification, or just referring to requirements that exists in that
specification. If the latter, please consider descriptive rather than
normative language. (e.g. "The 802.15.4 specification requires....&quo= t;

-- 6.1, 3rd paragraph: Why is the SHOULD not a MUST? When might it make
sense not to follow those rules?


- Editorial Comments

-- Abstract: Please expand 6TICH on first mention





--
<= div>
3D"Universitat=C2=A0=C2=A0
=C2=AD
<= /div>


--
Dr. Xavier Vilajosana
Wireless Networ= ks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
xvilajosana@uoc.edu
http://xvilajosana.orghttp://wine.rdi.uoc.= edu
Parc Med= iterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Building08860 Castelldefels (Barcelona). Catalonia. Spain
3D"Universitat=C2=A0=C2=A0
=C2=AD
= --001a1143e5208a78db0548f85da4-- From nobody Mon Feb 20 08:04:29 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1758F1296B7 for <6tisch@ietfa.amsl.com>; Mon, 20 Feb 2017 08:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcnedK_5XnKH for <6tisch@ietfa.amsl.com>; Mon, 20 Feb 2017 08:04:21 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F0A1296CB for <6tisch@ietf.org>; Mon, 20 Feb 2017 08:04:19 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id 203so15962016ith.0 for <6tisch@ietf.org>; Mon, 20 Feb 2017 08:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2z3yKkenqtW0guVB6aeLdy3gPhIgVRzxhbVtPiHmxOc=; b=PRWovbx/pCwLmUMldbgXhHFdFG1lRzDw77qYzyWz6AT18L+CKh6Q8eCsBMPSCvhMpu WpC5f5EVoCQBRcijuLih8R6aBopJuaMxC3aVb3rOTXVsRXeNDfuY+NY0eI0FeV+ztxq6 CjVATwcGCN1L62YFdmjkf1X9B6ajG48XickpA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2z3yKkenqtW0guVB6aeLdy3gPhIgVRzxhbVtPiHmxOc=; b=QQjITLSo7UAoLOXh48LSHB/FTtuPDb0NWUll5EuANbLu/5vfKYaOEVZBdfAfVQWK7e KCfouxuP5qGH/SiErfkBqQnMyrqAyfh2F877hwICrNoJmKbsKvf2/ZS0vsiCYe0+0oPD WXOxeJ/IF7Oq6n/tryIXqozeeVz9jvoNzlO6clgTjYqxqOZQWk/9l3n+ovwHbV7fexkY Qhqj/45uW13dI7CDcz1/+KGWgPb/TUGlvOTR6JUj8KvG//ZT2FOm1ymUeerPm6D2HBHp nY/W3Ds4yZEhcvQ+BPyhDoGsJKN5/pSzyHAbs88QZtu1v4BJdYvuGdkC10UJx2lnD1ic hAgw== X-Gm-Message-State: AMke39n4lii0aBssE8rgFREpapqEQkxlnAJa52xBGV7sgWjsCnkAGcY8/Iv7n/n8+/qf+E+Kyv/QI6rjvz6WjMvL X-Received: by 10.36.175.67 with SMTP id l3mr6449291iti.79.1487606658796; Mon, 20 Feb 2017 08:04:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.30.200 with HTTP; Mon, 20 Feb 2017 08:04:18 -0800 (PST) In-Reply-To: <1909594021.314958.1487242852273.JavaMail.root@canet.uoc.es> References: <1909594021.314958.1487242852273.JavaMail.root@canet.uoc.es> From: Xavi Vilajosana Guillen Date: Mon, 20 Feb 2017 17:04:18 +0100 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=f403045db62c76a7150548f86ab0 Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, tisch <6tisch@ietf.org>, Pascal Thubert , 6tisch-chairs@ietf.org, The IESG Subject: Re: [6tisch] Benoit Claise's No Objection on draft-ietf-6tisch-minimal-20: (with COMMENT) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 16:04:23 -0000 --f403045db62c76a7150548f86ab0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Benoit, thanks for your comments. Please see inline our response. A new version of the draft will be published later today. regards, X --- Benoit Claise has entered the following ballot position for draft-ietf-6tisch-minimal-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While reading, I frowned upon the same MAY & RPL issue as mentioned by Alvaro: The Introduction mentions that "RPL is specified to provide the framework for time synchronization in an 802.15.4 TSCH network.", but Section 5 (RPL Settings) makes it optional: "In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used." ---------------------------------------------------------------------- ANSWER: ---------------------------------------------------------------------- The two sentences in the intro referring to RPL have been removed. We think now that entering this discussion in the intro is too early. Our goal is to support implementations that want to use RPL. In this sense, we indicate how to map the L3 topology with the L2 (and timing) topology when RPL is used. However we do not want to restrict other possible routing protocols. _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch 2017-02-16 11:51 GMT+01:00 Benoit Claise : > Benoit Claise has entered the following ballot position for > draft-ietf-6tisch-minimal-20: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > While reading, I frowned upon the same MAY & RPL issue as mentioned by > Alvaro: > The Introduction mentions that "RPL is specified to provide the framework > for time synchronization in an 802.15.4 TSCH network.", but Section 5 > (RPL Settings) makes it optional: "In a multi-hop topology, the RPL > routing protocol [RFC6550] MAY be used." > > > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --f403045db62c76a7150548f86ab0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Benoit, thanks for your comments. Please see inline o= ur response.=C2=A0 A new version of the draft will be published later today= .

regards,
X
---

=
Benoit Claise has entered the following ballot position for
= draft-ietf-6tisch-minimal-20: No Objection

When re= sponding, please keep the subject line intact and reply to all
em= ail addresses included in the To and CC lines. (Feel free to cut this
=
introductory paragraph, however.)


<= div>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.<= /div>


The document, along with other ball= ot positions, can be found here:



------------------------------------------------------------------= ----
COMMENT:
-----------------------------------------= -----------------------------

While reading, I fro= wned upon the same MAY & RPL issue as mentioned by
Alvaro:
The Introduction mentions that "RPL is specified to provide th= e framework
for time synchronization in an 802.15.4 TSCH network.= ", but Section 5
(RPL Settings) makes it optional: "In = a multi-hop topology, the RPL
routing protocol [RFC6550] MAY be u= sed."

---------------------------------------= -------------------------------

ANSWER:
= ----------------------------------------------------------------------
The two sentences in the intro referring to RPL have been removed. We= think now that entering this discussion in the intro is too early.
Our goal is to support implementations that want to use RPL. In this sen= se, we indicate how to map the L3 topology with the L2 (and timing) topolog= y when RPL is used. However we do not want to restrict other possible routi= ng protocols.

____________________________________= ___________
6tisch mailing list

2017-02-16 11:51 GMT+01:00 Benoit Claise <bclaise@cisco.com>:
Benoit Claise has entered the following ballot position for
draft-ietf-6tisch-minimal-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-6tisch-minimal/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

While reading, I frowned upon the same MAY & RPL issue as mentioned by<= br> Alvaro:
The Introduction mentions that "RPL is specified to provide the framew= ork
for time synchronization in an 802.15.4 TSCH network.", but Section 5<= br> (RPL Settings) makes it optional: "In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used."





--
=
Dr. Xavier Vilajosana
W= ireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Pr= ofessor

(+34) 646 633 681
xvilajosana@uoc.edu
http://xvilajosana.orghttp://wine.rdi.uoc= .edu
Parc Me= diterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Building<= br>08860 Castelldefels (Barcelona). Catalonia. Spain
=
Dr. Xavier Vilajosan= a
Wireless Networks Lab
Internet Interdisciplinary Institut= e (IN3)
Professor

(+34) 646 633 681
xvilajosana@uoc.edu<= /a>
http://xvilajos= ana.org
http:/= /wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5,= B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
3D"Universitat=C2=A0=C2=A0
=C2=AD
--f403045db62c76a7150548f86ab0-- From nobody Mon Feb 20 08:14:37 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DAF1296DC; Mon, 20 Feb 2017 08:14:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148760727661.26093.1102331441492618147.idtracker@ietfa.amsl.com> Date: Mon, 20 Feb 2017 08:14:36 -0800 Archived-At: Cc: 6tisch@ietf.org Subject: [6tisch] I-D Action: draft-ietf-6tisch-minimal-21.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 16:14:36 -0000 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 of the IETF. Title : Minimal 6TiSCH Configuration Authors : Xavier Vilajosana Kris Pister Thomas Watteyne Filename : draft-ietf-6tisch-minimal-21.txt Pages : 27 Date : 2017-02-20 Abstract: This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Network. This minimal mode of operation specifies the baseline set of protocols that need to be supported, recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time Synchronized Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the 6LoWPAN framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrap, and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH compliant devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6tisch-minimal-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-21 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 21 23:24:58 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369E9129480; Tue, 21 Feb 2017 23:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HwJz-dg1IGL; Tue, 21 Feb 2017 23:24:55 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A3B1293FB; Tue, 21 Feb 2017 23:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15387; q=dns/txt; s=iport; t=1487748294; x=1488957894; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Ilinig/V4sOhcsj/zxL4esNBlbl3TLbQEImonH//Ygk=; b=kvCWIPSB277EbwE2D54KMZIqHqFoHcrxG5NcYb+6iP2IHnJPNcbMruUK Cj7+y0xAALP+v7qLD3GBWwwNnDEd9YO4GR+cmq2tE15Ivw5fRUnqe/PCG kv6HxdkDoB3RSP1P+Vznsq0RY2ztvHmuy5qIF8ZcnHNpNbLj1IM3/J1wZ c=; X-IronPort-AV: E=Sophos;i="5.35,193,1484006400"; d="scan'208,217";a="650894471" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2017 07:24:52 +0000 Received: from [10.61.240.233] ([10.61.240.233]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1M7Onbq016370; Wed, 22 Feb 2017 07:24:50 GMT To: Xavi Vilajosana Guillen References: <1909594021.314958.1487242852273.JavaMail.root@canet.uoc.es> From: Benoit Claise Message-ID: Date: Wed, 22 Feb 2017 08:24:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4DC006AE026C5FCFD5E18E2C" Archived-At: Cc: draft-ietf-6tisch-minimal@ietf.org, tisch <6tisch@ietf.org>, Pascal Thubert , 6tisch-chairs@ietf.org, The IESG Subject: Re: [6tisch] Benoit Claise's No Objection on draft-ietf-6tisch-minimal-20: (with COMMENT) X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 07:24:57 -0000 This is a multi-part message in MIME format. --------------4DC006AE026C5FCFD5E18E2C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Xavi, Thank you. Regards, Benoit > Dear Benoit, thanks for your comments. Please see inline our > response. A new version of the draft will be published later today. > > regards, > X > --- > > Benoit Claise has entered the following ballot position for > draft-ietf-6tisch-minimal-20: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > While reading, I frowned upon the same MAY & RPL issue as mentioned by > Alvaro: > The Introduction mentions that "RPL is specified to provide the framework > for time synchronization in an 802.15.4 TSCH network.", but Section 5 > (RPL Settings) makes it optional: "In a multi-hop topology, the RPL > routing protocol [RFC6550] MAY be used." > > ---------------------------------------------------------------------- > > ANSWER: > ---------------------------------------------------------------------- > The two sentences in the intro referring to RPL have been removed. We > think now that entering this discussion in the intro is too early. > Our goal is to support implementations that want to use RPL. In this > sense, we indicate how to map the L3 topology with the L2 (and timing) > topology when RPL is used. However we do not want to restrict other > possible routing protocols. > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > 2017-02-16 11:51 GMT+01:00 Benoit Claise >: > > Benoit Claise has entered the following ballot position for > draft-ietf-6tisch-minimal-20: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > While reading, I frowned upon the same MAY & RPL issue as mentioned by > Alvaro: > The Introduction mentions that "RPL is specified to provide the > framework > for time synchronization in an 802.15.4 TSCH network.", but Section 5 > (RPL Settings) makes it optional: "In a multi-hop topology, the RPL > routing protocol [RFC6550] MAY be used." > > > > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > /Internet Interdisciplinary Institute (IN3) > Professor/ > (+34) 646 633 681 > xvilajosana@uoc.edu > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > 08860 Castelldefels (Barcelona). Catalonia. Spain > > Universitat Oberta de Catalunya > ­ --------------4DC006AE026C5FCFD5E18E2C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear Xavi,

Thank you.

Regards, Benoit
Dear Benoit, thanks for your comments. Please see inline our response.  A new version of the draft will be published later today.

regards,
X
---

Benoit Claise has entered the following ballot position for
draft-ietf-6tisch-minimal-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

While reading, I frowned upon the same MAY & RPL issue as mentioned by
Alvaro:
The Introduction mentions that "RPL is specified to provide the framework
for time synchronization in an 802.15.4 TSCH network.", but Section 5
(RPL Settings) makes it optional: "In a multi-hop topology, the RPL
routing protocol [RFC6550] MAY be used."

----------------------------------------------------------------------

ANSWER:
----------------------------------------------------------------------
The two sentences in the intro referring to RPL have been removed. We think now that entering this discussion in the intro is too early.
Our goal is to support implementations that want to use RPL. In this sense, we indicate how to map the L3 topology with the L2 (and timing) topology when RPL is used. However we do not want to restrict other possible routing protocols.

_______________________________________________
6tisch mailing list

2017-02-16 11:51 GMT+01:00 Benoit Claise <bclaise@cisco.com>:
Benoit Claise has entered the following ballot position for
draft-ietf-6tisch-minimal-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

While reading, I frowned upon the same MAY & RPL issue as mentioned by
Alvaro:
The Introduction mentions that "RPL is specified to provide the framework
for time synchronization in an 802.15.4 TSCH network.", but Section 5
(RPL Settings) makes it optional: "In a multi-hop topology, the RPL
routing protocol [RFC6550] MAY be used."





--
Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor

(+34) 646 633 681
xvilajosana@uoc.edu
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia 
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
Universitat Oberta de Catalunya  
­

--------------4DC006AE026C5FCFD5E18E2C-- From nobody Sat Feb 25 20:06:36 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E801912987F; Sat, 25 Feb 2017 20:06:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148808199494.921.10755107908050071870.idtracker@ietfa.amsl.com> Date: Sat, 25 Feb 2017 20:06:34 -0800 Archived-At: Cc: 6tisch@ietf.org Subject: [6tisch] I-D Action: draft-ietf-6tisch-dtsecurity-secure-join-01.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 04:06:35 -0000 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 of the IETF. Title : 6tisch Secure Join protocol Author : Michael Richardson Filename : draft-ietf-6tisch-dtsecurity-secure-join-01.txt Pages : 16 Date : 2017-02-25 Abstract: This document describes a zero-touch mechanism to enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch signaling mechanisms. The resulting device will obtain a domain specific credential that can be used with either 802.15.9 per-host pair keying protocols, or to obtain the network-wide key from a coordinator. The mechanism describe her is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-secure-join/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-secure-join-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-dtsecurity-secure-join-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 26 14:15:06 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7452F1294A0; Sun, 26 Feb 2017 14:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5MhSP0NIU0T; Sun, 26 Feb 2017 14:14:57 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DF71294A7; Sun, 26 Feb 2017 14:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v1QMElKL028890; Sun, 26 Feb 2017 23:14:47 +0100 (CET) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vWfK33grYzDHRb; Sun, 26 Feb 2017 23:14:47 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 509840086.855156-08f7fbcefca09b0e23a26350e9f274fe Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 26 Feb 2017 23:14:46 +0100 Message-Id: <74320B9C-EA99-48E5-9F5F-7BE7982EF945@tzi.org> To: 6lo@ietf.org, 6tisch@ietf.org, lp-wan , lwip@ietf.org, roll@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [6tisch] Constrained Node/Network Cluster @ IETF98: DRAFT AGENDA X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 22:15:04 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF98. Remember that there is still quite some potential for changes. ACE/HOMENET/DISPATCH is a bit of a triple whammy. WUGH on LWIG will pull many constrained networks people off the github discussion. I'm not seeing any other major issues, but please do alert the respective chairs when you see one. All times are CDT (UTC-0500) -- yes, the US will be on DST already for a couple of weeks, while Europe moves over right on Mar 26th. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SUNDAY, March 26, 2017 0900-1700 IRTF*** icnrg, with some t2trg-related items on the = agenda MONDAY, March 27, 2017 0900-1130 Morning Session I Zurich A ART dispatch Dispatch WG Zurich D INT homenet Home Networking WG Zurich C SEC *** ace Authentication and Authorization for = Constrained Environments WG 1300-1500 Afternoon Session I Zurich E/F IRTF*** t2trg Thing-to-Thing Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich B RTG bier Bit Indexed Explicit Replication WG Zurich G RTG detnet Deterministic Networking WG Vevey 1/2 TSV tsvarea Transport Area Open Meeting 1520-1650 Afternoon Session II Zurich A SEC tokbind Token Binding WG 1710-1810 Afternoon Session III Vevey 1/2 GEN wugh WGs Using GitHub BOF Zurich E/F INT *** lwig Light-Weight Implementation Guidance WG Montreux 3 SEC curdle CURves, Deprecating and a Little more = Encryption WG Zurich C SEC oauth Web Authorization Protocol WG Zurich G TSV tsvwg Transport Area Working Group WG TUESDAY, March 28, 2017 0900-1130 Morning Session I Zurich C INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Zurich D IRTF maprg Measurement and Analysis for Protocols Zurich E/F SEC tls Transport Layer Security WG 1300-1430 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG Zurich D INT intarea Internet Area Working Group WG Zurich A RTG babel Babel routing protocol WG 1450-1620 Afternoon Session II Zurich G ART uta Using TLS in Applications WG Zurich E/F SEC *** teep A Protocol for Dynamic Trusted Execution = Environment Enablement BOF 1640-1840 Afternoon Session III Zurich C INT dnssd Extensions for Scalable DNS Service = Discovery WG Zurich E/F TSV taps Transport Services WG WEDNESDAY, March 29, 2017 0900-1130 Morning Session I Zurich A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG 1300-1500 Afternoon Session I Zurich A INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Montreux 3 TSV tcpinc TCP Increased Security WG THURSDAY, March 30, 2017 0900-1130 Morning Session I Zurich D INT 6man IPv6 Maintenance WG Zurich C IRTF icnrg Information-Centric Networking Zurich E/F RTG rtgarea Routing Area Open Meeting Vevey 1/2 TSV quic QUIC WG 1300-1500 Afternoon Session I Zurich B ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Zurich G SEC acme Automated Certificate Management = Environment WG Zurich A TSV tsvwg Transport Area Working Group WG 1520-1720 Afternoon Session II Zurich A OPS v6ops IPv6 Operations WG Zurich D SEC saag Security Area Open Meeting 1740-1840 Afternoon Session III Zurich A RTG *** roll Routing Over Low power and Lossy = networks WG FRIDAY, March 31, 2017 0900-1130 Morning Session I Vevey 1/2 ART httpbis Hypertext Transfer Protocol WG Zurich E/F INT ipwave IP Wireless Access in Vehicular = Environments WG Zurich A OPS anima Autonomic Networking Integrated Model = and Approach WG Zurich C SEC oauth Web Authorization Protocol WG 1150-1320 Afternoon Session I Zurich C ART *** core Constrained RESTful Environments WG From nobody Tue Feb 28 07:49:21 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC671295C3 for <6tisch@ietfa.amsl.com>; Tue, 28 Feb 2017 07:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MczCR_tTyvxx for <6tisch@ietfa.amsl.com>; Tue, 28 Feb 2017 07:49:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2038712958A for <6tisch@ietf.org>; Tue, 28 Feb 2017 07:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11670; q=dns/txt; s=iport; t=1488296958; x=1489506558; h=from:to:subject:date:message-id:mime-version; bh=dNoPHlhIm+mQmlK77w4FzNc/wrwJslhDIaWa9ijGnak=; b=TkbEE3/iUntFraaUQbAMSJDVl2D8p+rDlIfF/DKJNBsQJ6Fc0ayG1nIE 0MCtOlQbfdl4NagER02Y3ETmG0Fcpa7ZmDZc9XPxih6h8v1Vm6oXE+5ST oF5UserFuRTy9Xg3Vjjkm8he38Dm7gWGaJZUyFpkaJSQbvfOWc+FITmlm I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAQDYmrVY/4YNJK1EGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuYmGBCQeNXKFshSyCDSyFdoItPxgBAgEBAQEBAQFiHQuFJF4?= =?us-ascii?q?BHBwMPCYBBBuJbw4toDySK4NUh14BAQEBAQEBAwEBAQEBAQEhhkyGK4FbgV0ug?= =?us-ascii?q?hKCaxoFnCMBhnOLL4IEjx2IPIp1AR84gQFUFYUNHYFhdQGIYoENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,220,1484006400"; d="scan'208,217";a="212295778" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Feb 2017 15:49:17 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1SFnHF1012004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Tue, 28 Feb 2017 15:49:17 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Feb 2017 09:49:16 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 28 Feb 2017 09:49:16 -0600 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Agenda, 03 March 2017 interim, 6TiSCH WG Thread-Index: AdKR2d4dTKxXDL8jRGWrO1dHV7RdEQ== Date: Tue, 28 Feb 2017 15:49:04 +0000 Deferred-Delivery: Tue, 28 Feb 2017 15:48:52 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_ee9f1a4faf6140298d15536d66b908c0XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] Agenda, 03 March 2017 interim, 6TiSCH WG X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 15:49:19 -0000 --_000_ee9f1a4faf6140298d15536d66b908c0XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Connection details * Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=3D1&lid=3D100,= 12,5392171,1850147&h=3D100&date=3D2017-03-03&sln=3D15-16 * Webex link: https://cisco.webex.com/ciscosales/j.php?MTID=3Dmcdbbe3a4= e38d97d986b507ec12a1f9b1 * Meeting number (access code): 203 224 694 * Meeting password: sixtus (749887 from phones) * Material link: https://bitbucket.org/6tisch/meetings/raw/master/17030= 3_webex/slides_170303_webex.ppt Agenda * Administrivia [2min] * Approval agenda * Approval minutes last call * Status of drafts [Pascal] [5min] * Update on security [Michael] [10min] * Update on 6P [Xavi] [10min] * Preparation for IETF 98 [Pascal] [QS] * AOB [3min] --_000_ee9f1a4faf6140298d15536d66b908c0XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Connection details

Agenda
  • Administrivia [2min]
    • Approval agenda
    • Approval minutes last call
  • Status of drafts [Pascal] [5min]
  • Update on security [Michael] [10min]
  • Update on 6P [Xavi] [10min]
  • Preparation for IETF 98 [Pascal] [QS]
  • AOB [3min]

--_000_ee9f1a4faf6140298d15536d66b908c0XCHRCD001ciscocom_--