Re: [Roll] [6tisch] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt

James Woodyatt <> Tue, 02 December 2014 20:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 86AB51A700A for <>; Tue, 2 Dec 2014 12:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Plo0C-7_4tm9 for <>; Tue, 2 Dec 2014 12:05:07 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CAA2E1A6FEB for <>; Tue, 2 Dec 2014 12:05:05 -0800 (PST)
Received: by with SMTP id im17so6059900vcb.32 for <>; Tue, 02 Dec 2014 12:05:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fUn5GlNqZDSEw64D+7+pSXDcb/IoncwoeSshK0z45/k=; b=D6KAJLH5heY7XjcM42V3GzfZJv3xLjg15whq9atILbrOfcaFNhckKI+riBN+DluSmk cFOewWCtHFI+RMeKhwVk/ax8JbeCYYgb6n6rTlAW6XK4zm3ffPsnkD8qglnvUSJFcuxv 8/rwDuldDGQBIn/8SzxQISldegrudIDg/me5/p465Nar2Rrf7d1OQ2Th6tjvNRY2wndY e0RD+8GFXgjgH5eteaScSmdfGDk23HKgomtlq+dgtkUbefGZybybd79jtwcmuJK0UX4Y k8xlIApGfBNR0xymeMk+WhKn7Ul1siatD21TPJrusWMUPelaQodxIC6GiPe2m6gBQiG8 9CQg==
X-Gm-Message-State: ALoCoQmwjoOgQYVB1VE0rt60faeHyFUGYR1118FiFG7FsUGXRHfAfuDOC/i/VWsf5/ATZRauZ6xQ
MIME-Version: 1.0
X-Received: by with SMTP id s4mr667169vdy.50.1417550703064; Tue, 02 Dec 2014 12:05:03 -0800 (PST)
Received: by with HTTP; Tue, 2 Dec 2014 12:05:02 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 2 Dec 2014 12:05:02 -0800
Message-ID: <>
From: James Woodyatt <>
To: "" <>
Content-Type: multipart/alternative; boundary=001a1136afd81b8cc10509413eeb
Cc: "" <>, Routing Over Low power and Lossy networks <>
Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Dec 2014 20:05:14 -0000

On Mon, Dec 1, 2014 at 9:41 PM, Carsten Bormann <> wrote:

> On 01 Dec 2014, at 20:20, James Woodyatt <> wrote:
> >
> > RFC 4944 is a Proposed Standard, which puts it into the same category as
> "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464],
> That argument would be more convincing if the situations were indeed
> comparable.
> RFC 2464 is the basis for widely deployed plug-and-play interoperability.
> *That* is what makes it mostly immutable, not the standards status.
> (Which probably should be upgraded to match reality.)
> With RFC 4944, we haven’t reached that level of interoperability yet.

Yes, well— I wasn't trying to make an argument that Proposed Standard
category implies the Expensive Mutability quality.  I was rebutting what
seemed to be Pascal's argument that Not Standard implies Inexpensive
Mutability by attempting to provide an existence proof in the form of RFC

In particular, there is *no* way to achieve out-of-the-box interoperability
> with the old mesh header — there is no defined way to use it, or even to
> find out that (and how) it should be used.
> So you already have to add configuration (as in, "use mesh forwarding
> mechanism X") to use it.
> Pascal’s proposal does not change this situation one iota: It doesn’t
> jeopardize interoperability where there was interoperability before.

Not quite true. We should be mindful of the possibility of existing
interoperability already obtained by conformance to external specifications
derived from RFC 4944. Because it's a Proposed Standard, I'm generally not
comfortable assuming that the Mesh Header is a sand castle that can be
safely demolished and rebuilt. Again, I think that's a value judgment about
existing deployments that we should be wary about making.

> (Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC
> 4944 and replaced them with RFC 6282.)
> Again, I believe we need to learn more about those reported usages of the
> old Mesh Header before we can meaningfully continue this argument.

I'm not sure that's a Need so much as a Desire, and a curious one at that.
I don't see the harm in proceeding to develop a coexistence strategy for
dealing with any existing implementations that may currently be using the
existing Mesh Header despite its rather fluid definition in the Proposed
Standard. Why is taking that precaution not a good idea?

james woodyatt <>
Nest Labs, Communications Engineering