Re: [6tisch] removing the 'e'
Rene Struik <rstruik.ext@gmail.com> Mon, 30 March 2015 19:53 UTC
Return-Path: <rstruik.ext@gmail.com>
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 485D51A86FD
for <6tisch@ietfa.amsl.com>; Mon, 30 Mar 2015 12:53:40 -0700 (PDT)
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,
FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 Je7UjmiC64jK for <6tisch@ietfa.amsl.com>;
Mon, 30 Mar 2015 12:53:37 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com
[IPv6:2607:f8b0:4001:c05::22c])
(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 9F9551A8945
for <6tisch@ietf.org>; Mon, 30 Mar 2015 12:53:37 -0700 (PDT)
Received: by igbud6 with SMTP id ud6so85754145igb.1
for <6tisch@ietf.org>; Mon, 30 Mar 2015 12:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:date:from:user-agent:mime-version:to:cc:subject
:references:in-reply-to:content-type:content-transfer-encoding;
bh=ZE20g5yC0WmQFY5dUMsR5vgFFLsnkfwj2v/yZAk3STw=;
b=NoojH0jBBE60xul6rNRg4QDmH5H5588zCgGaaFC3zqIkf5VH+x38PPegOcxMq1W0e0
ky+wwWrnN9bwpa19WcsN1G1fWZVAzMyuqHVoZNajeFrUacNX2LauN/aGlHCjyHCE6cCN
uGDXiZRiY96gBwOBv/qhRigwUsuUB6vEID9KZ/5u2nW2uhpWm811UcKbLR34eAgqu1Aq
bytGT+Zm/zCFMS/AvzlV/KIWi/yfEmchUICApntrDQCtxc9KYJZxtfWRrem2CI5JBYd+
q5RYZrDNTzxWC8WASsMTmE1NFI4ALHa/ZRYMI9D4L5pPGYZZxTMER1nwvtvSTRdYPfXd
ccww==
X-Received: by 10.50.39.65 with SMTP id n1mr20075376igk.37.1427745217085;
Mon, 30 Mar 2015 12:53:37 -0700 (PDT)
Received: from [192.168.0.10]
(CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38])
by mx.google.com with ESMTPSA id w3sm8084676ioi.32.2015.03.30.12.53.36
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 30 Mar 2015 12:53:36 -0700 (PDT)
Message-ID: <5519A9BA.9070109@gmail.com>
Date: Mon, 30 Mar 2015 15:53:30 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Pat Kinney <pat.kinney@kinneyconsultingllc.com>,
"6tisch@ietf.org" <6tisch@ietf.org>
References: <E045AECD98228444A58C61C200AE1BD849D905A6@xmb-rcd-x01.cisco.com>
<55199457.3000504@gmail.com>
<CF0DF79F-14F7-4B32-AE15-CA2E44BE04D2@kinneyconsultingllc.com>
In-Reply-To: <CF0DF79F-14F7-4B32-AE15-CA2E44BE04D2@kinneyconsultingllc.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/J241hJbbI_8-52oysDck8xs4hs8>
Cc: Thubert Pascal <pthubert@cisco.com>
Subject: Re: [6tisch] removing the 'e'
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: <http://www.ietf.org/mail-archive/web/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: Mon, 30 Mar 2015 19:53:40 -0000
Hi Pat: I do not understand how one could possibly object against any suggestion that using blind, unverified trust (aka "blank cheque") as yardstick is imprudent: this should be self-evident. In fact, my simple suggestion that 6TiSCH do its own due diligence as to whether a specific specification should be preferred as baseline is not unlike what is suggested in the reference sections of most IEEE documents (where one either cross-references dated or undated specs). I Ironically, I was told that the latest 802.15.4 Revision draft (the one you had some slides on during IETF-92) does the same... (see below) [802.15.4-2006, Section 2 - Normative References] The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies. [draft 802.15.4 REVc - DF4] The following referenced documents are indispensable for the application of this document (i.e., they must be understood and used, so each referenced document is cited in text and its relationship to this document is explained). For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies. Best regards, Rene On 3/30/2015 3:06 PM, Pat Kinney wrote: > I disagree with both Kris' and Rene's objections. > > Addressing Kris' objections first: > - If the roll-up from 15.4e to 15.4-2015 were just corrections of real problems it would be a no-brainer. > <PK> the element here is "just corrections", indeed there are corrections, but many non-TSCH and security corrections have been made as well > - Unfortunately, there are numerous cases where IEEE members with "good ideas" have pushed for changes that have little or no practical value, but do require a re-write of existing code, and mandate non-interoperability between the existing 15.4e and the forthcoming 15.4-2015. > <PK> '"good ideas" with little or no practical value' is a personal opinion, to which I disagree whole heartedly.'Requiring a rewrite of existing code and mandating non-interoperability between existing 15.4e and forthcoming 15.4-2015' is unfounded, the changes we have implemented have been critiqued for backward compatibility, I am not aware of any change that would make the two versions of devices non-interoperable. I ask that Kris quantify his statement with evidence. > > Addressing Rene's objections: > - To me, it is not a given that the revision effort of 802.15.4 that is currently on its way will automatically satisfy requirements 6TiSCH has. > <PK> to what TSCH requirements does Rene refer? I ask that Rene to not critique without giving evidence > - I am wondering how we would know, since so far technical changes have never been discussed/socialized within 6TiSCH itself (see also http://www.ietf.org/mail-archive/web/6tisch/current/msg02853.html). Anecdotal evidence regarding extensive changes makes me somewhat pessimistic here. > <PK> the url provided by Rene merely restates his objections in the past, they absolutely have no evidence supporting them, e.g. "this does not necessarily mean they can speak for 6tisch's interests, at least not without consensus." I ask Rene again, what 6tisch interests with a consensus have been ignored or disregarded? Please stop referring to past innuendos but instead let's discuss specific technical questions > - So, I am not in favor of implicit, blind trust; only in favor of explicit, verified trust. Unfortunately, this means I think the recommendation you put forward below is imprudent. > <PK> I addressed the aspect of "the explicit verified trust" at the meeting in Dallas, the latest draft revision will be made publicly available at the start of the Sponsor Ballot which could start as early as 8 April 2015. Until then, I ask that anyone in the 6tisch group to address specific questions to this ML to which I can specifically reply. > > Pat > > Pat Kinney > Kinney Consulting LLC > IEEE 802.15 WG vice chair, TG chair > ISA100.11a WG chair > O: +1.847.960.3715 > pat.kinney@kinneyconsultingllc.com > > > > > > > On 30, Mar2015, at 13:22, Rene Struik <rstruik.ext@gmail.com> wrote: > > Hi Pascal: > > I think the proper approach is that one investigates whether an updated version of a cross-referenced specification is suitable and, if so, one can adopt this. > > To me, it is not a given that the revision effort of 802.15.4 that is currently on its way will automatically satisfy requirements 6TiSCH has. I am wondering how we would know, since so far technical changes have never been discussed/socialized within 6TiSCH itself (see also http://www.ietf.org/mail-archive/web/6tisch/current/msg02853.html). Anecdotal evidence regarding extensive changes makes me somewhat pessimistic here. > > We should use a "trust but verify" approach here. Anything else would be imprudent. I think this more or less reiterates Subir Das's point. > > So, I am not in favor of implicit, blind trust; only in favor of explicit, verified trust. Unfortunately, this means I think the recommendation you put forward below is imprudent. > > As a final note: > a) not sure why the 802.15.4e amendment would be incomplete. This seems to be in direct conflict with the note on page 1 of the 802.15.4e-2012 standard (NOTE—The editing instructions contained in this amendment define how to merge the material contained therein into the existing base standard and its amendments to form the comprehensive standard). > b) Not sure how one can already predict now when the current revision work will be end and result in a revised standard. Assuming that this will be in 2015 (with sponsor ballot not having started yet) seems somewhat premature. > > Rene > > On 3/30/2015 11:23 AM, Pascal Thubert (pthubert) wrote: >> Dear all: >> >> Pat presented at the WG on Thursday his recommendation to remove the 'e' after IEEE802.15.4 in our current charter and WG Documents (slides at the end of http://www.ietf.org/proceedings/92/slides/slides-92-6tisch-2.pdf ). >> >> The net effect would be that when a new version of the standard is published - 2015 should be available soon -, our normative references will implicitly pick that latest version and inherit the fixes that were made since then, as well as the additional PHYs on which 802.15.4 TSCH can operate. >> >> Pat indicated that this procedure is the expected one when referring to IEEE documents. Subir noted that at the IETF we normally have reference on particular versions, and a change in an RFC is a new RFC thus a new reference, and the IEEE form of reference may create an issue with IETF practice. The chairs will need to validate this before proceeding. >> >> On the question whether the change is desirable, Pat made the case that 15.4e is just an amendment, which is an incomplete reference, and that it yields some incorrectness that is now fixed in the upcoming 2015 version of 802.15.4. >> All in all the group agreed that the change is desirable. We are now coming to the list to confirm the consensus. If you have an issue with removing the 'e' please speak up now. >> >> Cheers, >> >> Pascal and Thomas >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
- [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Kris Pister
- Re: [6tisch] removing the 'e' Rene Struik
- Re: [6tisch] removing the 'e' Turner, Randy
- Re: [6tisch] removing the 'e' Pat Kinney
- Re: [6tisch] removing the 'e' Rene Struik
- Re: [6tisch] removing the 'e' Tom Phinney
- Re: [6tisch] removing the 'e' Robert Moskowitz
- Re: [6tisch] removing the 'e' Kris Pister
- Re: [6tisch] removing the 'e' Pat Kinney
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Turner, Randy
- Re: [6tisch] removing the 'e' Robert Cragie
- Re: [6tisch] removing the 'e' Brian Haberman
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Rene Struik
- Re: [6tisch] removing the 'e' Brett, Patricia (PA62)
- Re: [6tisch] removing the 'e' Rene Struik
- Re: [6tisch] removing the 'e' Tom Phinney
- Re: [6tisch] removing the 'e' Tom Phinney
- Re: [6tisch] removing the 'e' Jonathan Simon
- Re: [6tisch] removing the 'e' Pat Kinney
- Re: [6tisch] removing the 'e' Subir Das
- Re: [6tisch] removing the 'e' Brian Haberman
- Re: [6tisch] removing the 'e' Kris Pister
- Re: [6tisch] removing the 'e' Subir Das
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Rene Struik
- Re: [6tisch] removing the 'e' Rene Struik
- Re: [6tisch] removing the 'e' Rene Struik
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)
- Re: [6tisch] removing the 'e' Pat Kinney
- Re: [6tisch] removing the 'e' Rene Struik
- [6tisch] (on effectiveness of 6TiSCH liaison) Re:… Rene Struik
- Re: [6tisch] (on effectiveness of 6TiSCH liaison)… Pat Kinney
- Re: [6tisch] removing the 'e' Pascal Thubert (pthubert)