[6tisch] Stephen Farrell's No Objection on charter-ietf-6tisch-01-00: (with COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Thu, 21 January 2016 14:54 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 2072D1AC40B; Thu, 21 Jan 2016 06:54:36 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160121145436.3692.9217.idtracker@ietfa.amsl.com>
Date: Thu, 21 Jan 2016 06:54:36 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/4oPc30bdDt8mPneL2vLlxIovik8>
Cc: 6tisch@ietf.org, 6tisch-chairs@ietf.org
Subject: [6tisch] Stephen Farrell's No Objection on charter-ietf-6tisch-01-00: (with COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 21 Jan 2016 14:54:36 -0000

Stephen Farrell has entered the following ballot position for
charter-ietf-6tisch-01-00: 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.)

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


This talks about doing security work for bootstrap which is
great, and also about allowing scheduling information to 
be updated/distributed. Would I be correct in assuming that
it needs to be possible for the schedule updates to be as
secure as the bootstrap? I hope so, anyway.  Not sure if
this needs to be stated in the charter though. (Well, if
the answer is "no, updates never need security" then I
think the opposite should be stated in the charter:-)