IETF Logo Mail Archive

Re: [6tisch] Quick review on draft 15

Thomas Watteyne <thomas.watteyne@inria.fr> Fri, 26 February 2016 14:08 UTC

Return-Path: <thomas.watteyne@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526931B2C24 for <6tisch@ietfa.amsl.com>; Fri, 26 Feb 2016 06:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.933
X-Spam-Level:
X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham
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 mcdQ6w-u10MN for <6tisch@ietfa.amsl.com>; Fri, 26 Feb 2016 06:08: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 RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE161B2C28 for <6tisch@ietf.org>; Fri, 26 Feb 2016 06:08:35 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.22,498,1449529200"; d="scan'208,217";a="166089487"
Received: from mail-wm0-f51.google.com ([74.125.82.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 26 Feb 2016 15:08:19 +0100
Received: by mail-wm0-f51.google.com with SMTP id a4so71421625wme.1 for <6tisch@ietf.org>; Fri, 26 Feb 2016 06:08:19 -0800 (PST)
X-Gm-Message-State: AD7BkJJPT43FNEYI8tBcYPXmEPXr2vQ7XnZhlhgkJ/V27DIP+rMNWeeXEdY06JEYt9XbbDJmpOp61X6n5kXN2Q==
X-Received: by 10.28.224.84 with SMTP id x81mr3626541wmg.62.1456495699613; Fri, 26 Feb 2016 06:08:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.63.196 with HTTP; Fri, 26 Feb 2016 06:07:59 -0800 (PST)
In-Reply-To: <d3b5b1bd4d1b4b32bfa40a071ebe7cc9@XCH-RCD-001.cisco.com>
References: <d3b5b1bd4d1b4b32bfa40a071ebe7cc9@XCH-RCD-001.cisco.com>
From: Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Fri, 26 Feb 2016 15:07:59 +0100
X-Gmail-Original-Message-ID: <CADJ9OA90Jk3U09k_2orC7mCVD79+owyr2we3wPArbhmY-r=eCw@mail.gmail.com>
Message-ID: <CADJ9OA90Jk3U09k_2orC7mCVD79+owyr2we3wPArbhmY-r=eCw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary="001a114c1846cade14052cacd4a5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/5OJK4ZLcLK6-ZKcaUO57-1BQOco>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Xavi Vilajosana Guillén <xvilajosana@uoc.edu>
Subject: Re: [6tisch] Quick review on draft 15
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2016 14:08:39 -0000

Authors,
I went through the changes between v14 and v15 on the bitbucket repo and
agree with the changes made.
Thomas

On Fri, Feb 26, 2016 at 11:22 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Hello Xavi:
>
>
>
> I’m not asking for any change change but editorials. In particular I do
> not see a need to say that minimal could be disabled. Anything can be
> disabled, it’s always an admin decision to implement a protocol. The
> important thing is that minimal does not preclude the use of other TSCH
> traffic on other timeslots.
>
>
>
> As I reread the draft, I have some editorial suggestions, feel free to
> pick or not:
>
>
>
> “bitmap in the active cell indicate that a node” -> indicates?
>
> “This results in ‘’Slotted Aloha’’ behavior” -> This results in a behavior
> that is similar to that of ‘’Slotted Aloha’’.
>
> “acknowledgement” -> acknowledgment
>
> “neighbour” -> neighbor
>
> “EBs MUST NOT be used for time” -> EBs are not used for time
>
> “rank” -> Rank  (when talking about RPL’s Rank)
>
> “Routing extension headers such as RPI and SRH and inner
>
>    IP headers MUST be compressed according to [RFC6282],
>
>    [I-D.ietf-6lo-routing-dispatch] and [I-D.ietf-6lo-paging-dispatch].”
>
> ->
>
> “
>
> Routing extension headers such as RPI [RFC6550] and SRH [RFC6554], and
> outer
>
>    IP headers in case on encapsulation MUST be compressed according to
>
>    [I-D.ietf-6lo-routing-dispatch] and [I-D.ietf-6lo-paging-dispatch].
>
> “
>
>
>
> Also: [I-D.ietf-6lo-routing-dispatch] and [I-D.ietf-6lo-paging-dispatch]
> should be normative references. Should not delay minimal if we last call
> soon.
>
>
>
> Take care,
>
>
>
> Pascal
>
> _______________________________________________
> 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
_______________________________________

v2.23.0 | Report a Bug | By Email