IETF Logo Mail Archive

Re: [Roll] New proposed charter

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 11 December 2015 21:23 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF071A8ADE for <roll@ietfa.amsl.com>; Fri, 11 Dec 2015 13:23:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ohrptj4vgByQ for <roll@ietfa.amsl.com>; Fri, 11 Dec 2015 13:23: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 4E4DB1A8AD7 for <roll@ietf.org>; Fri, 11 Dec 2015 13:23:52 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 05B3DE007; Fri, 11 Dec 2015 16:29:36 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8052F63795; Fri, 11 Dec 2015 16:23:51 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Randy Turner <rturner@amalfisystems.com>
In-Reply-To: <1676228924.7990.1449851481478.JavaMail.vpopmail@atl4oxapp102.mgt.hosting.qts.netsol.com>
References: <CAP+sJUfYLXN7z5b3UtXbs9a_JQjCfBpJGrihQru+k8wTFsOTbQ@mail.gmail.com> <1676228924.7990.1449851481478.JavaMail.vpopmail@atl4oxapp102.mgt.hosting.qts.netsol.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
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: Fri, 11 Dec 2015 16:23:51 -0500
Message-ID: <11866.1449869031@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/d2n8ZcchRodaAhn6ECn4L0XaTaU>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>
Subject: Re: [Roll] New proposed charter
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 11 Dec 2015 21:23:53 -0000

Randy Turner <rturner@amalfisystems.com> wrote:
    > We might want to consider rolling items from 6553, 6551, etc. back into
    > an overall “RPL Protocol” RFC – not everything, but items that we have
    > found in implementation to be a requirement for a workable RPL
    > implementation.

That's entirely doable if we have the editorial cycles, and it's included in:

    ines>     Over time, additional issues have come up, including issues in the
    ines> data plane of when to use IPinIP headers, and how to compress them, as
    ines> well as the standardization of a mixed storing/non-storing mechanism.

So, we'd be *updating* 6554,6553,6551, etc. in explaining how to compress
things.

    ines> aim of eventually revising and advancing RFC
    ines> 6550 to Internet Standard.

And this item includes the possibility that we could combine multiple
documents as we go to IS.
When it says "RFC6550" it should mean the entire RPL document set.
So perhaps that part should be more explicit?

    > Also, I would like to consider other options for routing besides
    > strictly storing and non-storing, or mixed storing/non-storing

Explicitely already mentioned: we didn't pick a solution in the charter
above:      **standardization of a mixed storing/non-storing mechanism**

    > Randy

So, are you in favour of this change, or can you suggest specific text?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

v2.23.0 | Report a Bug | By Email