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

james woodyatt <> Thu, 09 July 2015 20:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3C611A017E for <>; Thu, 9 Jul 2015 13:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uoWB0WhO0QqX for <>; Thu, 9 Jul 2015 13:48:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D4A91A0092 for <>; Thu, 9 Jul 2015 13:48:26 -0700 (PDT)
Received: by igrv9 with SMTP id v9so202665606igr.1 for <>; Thu, 09 Jul 2015 13:48:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4HrcgDX6EV7kQJVOYVhCIk6ehzCOVMmNbebugxgJy2I=; b=E81m5rIFLHmh6Nv7n1uCH9EqClv6StiNy8CrHbm74Jj629nC5TaxjkYhO+HQRtYW+Z gaNp7/iq2IITi5W1jC/3gjCtd8fpOos+LtN6j4xIkJVfNFSprkHtSKD42pZ013RUzu17 xu0mm4MhmYkR4pQJ+lMufPtgXzTlCVrXjUlng=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4HrcgDX6EV7kQJVOYVhCIk6ehzCOVMmNbebugxgJy2I=; b=mLiw8oQFx7XSK+wH47dXXR4f0W5ol+s+d4fqesG+vv5Py9IOM2dlxxznlkflo70cRv CYGYXt2BZXM302COiYuivF3JLxURIspcTGtY6T4UQKKdUOo5x8P1jwifdxbYdc1NLx0r YCoC45H8pwOaTXsoFliTM8JduvIGl/BO2rNW6ax7C0Sk2H8hcbSVzA24V0eBf9uoDKEG bD0J2Rm4lrwRH0MQ8wTklSp/lJZvUwU/rk6CptsqvrhPxKnR+ELE4o+TigRABWkZoCfb z/NkoQksaOSR9J8/7vGZy6iFnymAPHNvJG/B25oR0hkX803rLBoiJgFjrdiN7DGHUj6h xktw==
X-Gm-Message-State: ALoCoQmj26kEmR2gvTl9sz6wNPDeRdUl7YFQDLJTNjbldVSBDDHM+d5OqN9qfyr2H1oc1TqQnkhY
X-Received: by with SMTP id l4mr101256027igx.48.1436474905530; Thu, 09 Jul 2015 13:48:25 -0700 (PDT)
Received: from ?IPv6:2620:15c:1:101:542e:718a:374e:a427? ([2620:15c:1:101:542e:718a:374e:a427]) by with ESMTPSA id kk9sm17328381igb.7.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jul 2015 13:48:24 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6180432A-0F04-4395-BC5B-04D00B5F6518"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: james woodyatt <>
In-Reply-To: <>
Date: Thu, 9 Jul 2015 13:48:29 -0700
Message-Id: <>
References: <> <> <> <>
To: "" <>
X-Mailer: Apple Mail (2.2102)
Archived-At: <>
Cc: Routing Over Low power and Lossy networks <>, "" <>
Subject: Re: [Roll] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-04.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: Thu, 09 Jul 2015 20:48:27 -0000

On Jul 9, 2015, at 02:33, Pascal Thubert (pthubert) <> wrote:
> If we get rid of the fantasy that there's a single 6LoWPAN network, and that all devices can plug into it, then we see that there will be multiple bodies like ZigBee IP defining profiles and ensuring connectivity of compliant implementations.

I don’t remember ever adopting this fantasy, yet I still have concerns about proceeding with this draft.

> A device would be designed for one such profile, where the use of either legacy mesh or option 1 would be enforced.

I can see this happening under the terms of the current draft. I think it’s important to consider what “device” likely means in this context. We’re talking about commodity implementation modules. When you design a finished product, you choose the commodity implementation module that implements the specific profile of 6LoWPAN for which it was certified to interoperate.

> Or a device could be compliant with multiple such profiles in which case there would be a need for configuration or discovery.

If am deeply skeptical that this assertion will be proven if we proceed with this draft. I expect it to be much more likely that one or two specific profiles will be implemented as commodity modules, and devices that use them will be forced in hardware to use exactly one profile at all times.