Re: [Roll] Request for Comments for ROLL Charter

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 28 June 2016 12:47 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A5612DE90 for <roll@ietfa.amsl.com>; Tue, 28 Jun 2016 05:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level:
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 0euZXEbHi7P6 for <roll@ietfa.amsl.com>; Tue, 28 Jun 2016 05:47:17 -0700 (PDT)
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 0FD8612DE8B for <roll@ietf.org>; Tue, 28 Jun 2016 05:47:16 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A646E2009E; Tue, 28 Jun 2016 08:55:32 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A992E638BE; Tue, 28 Jun 2016 08:47:15 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <962ecd511f1b4629bcf329790509bb0c@XCH-RCD-001.cisco.com>
References: <CAP+sJUdRQHJhuszRLmMLoObVVELTGKAboPZpjHRV1M1t3T1BpA@mail.gmail.com> <962ecd511f1b4629bcf329790509bb0c@XCH-RCD-001.cisco.com>
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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 28 Jun 2016 08:47:15 -0400
Message-ID: <17987.1467118035@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/yTGVtFOgOmuoq-OJgyZsStoUnro>
Cc: peter van der Stok <stokcons@xs4all.nl>
Subject: Re: [Roll] Request for Comments for ROLL Charter
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2016 12:47:20 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com>; wrote:
    > Additional protocol elements to reduce source route headers in
    > non-storing mode and/or memory consumption in storing mode such as
    > route projection and BIER.

It sounds too prescriptive, as if we have limited ourselves in the charter
to those two methods.  I don't think that this is your intention.

If you wrote:

    > Additional protocol elements to reduce source route headers in
    > non-storing mode and/or memory consumption in storing mode.
    > These elements may leverage mechanisms such as route projection and BIER.

would be clearer that these are not the only two admissible methods.
I'm not sure that we need to say what the methods are *at all*

    > There is a wide scope of application areas for LLNs, including
    > industrial monitoring, building automation (HVAC, lighting, access
    > control, fire), connected homes, health care, environmental monitoring,
    > urban sensor networks (e.g. Smart Grid), asset tracking.  The Working
    > Group focuses on routing solutions for a subset of these: connected
    > home, building and urban sensor networks for which routing requirements
    > have been specified. These application-specific routing requirement
    > documents were used for protocol design.

    > The Working Group focuses on IPv6 routing architectural framework for
    > these application scenarios. The Framework will take into consideration
    > various aspects including high reliability in the presence of time
    > varying loss characteristics and connectivity while permitting
    > low-power operation with very modest memory and CPU pressure in
    > networks potentially comprising a very large number (several thousands)
    > of nodes.

I'd like these two paragraphs removed as being ancient motherhood text.

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