IETF Logo Mail Archive

Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 15 November 2013 15:26 UTC

Return-Path: <mcr@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 D895521F9D46; Fri, 15 Nov 2013 07:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.369
X-Spam-Level:
X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_20=-0.74]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSzCJIQ+ON6m; Fri, 15 Nov 2013 07:26:16 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC2121F9A43; Fri, 15 Nov 2013 07:26:14 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F58720049; Fri, 15 Nov 2013 11:38:27 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id C36E063B88; Fri, 15 Nov 2013 10:26:13 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B3D8463AEF; Fri, 15 Nov 2013 10:26:13 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Kerry Lynn <kerlyn@ieee.org>
In-Reply-To: <CABOxzu2s4d0dzyPBfQCs64VUa2zGiLzJtrN9zpw_M0abTqU1Vw@mail.gmail.com>
References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <E045AECD98228444A58C61C200AE1BD84158AE17@xmb-rcd-x01.cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <E045AECD98228444A58C61C200AE1BD841590CC4@xmb-rcd-x01.cisco.com> <5284CE9E.4060001@innovationslab.net> <E045AECD98228444A58C61C200AE1BD841597360@xmb-rcd-x01.cisco.com> <CABOxzu2s4d0dzyPBfQCs64VUa2zGiLzJtrN9zpw_M0abTqU1Vw@mail.gmail.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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: Fri, 15 Nov 2013 10:26:13 -0500
Message-ID: <8808.1384529173@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: "ipv6@ietf.org IPv6 List" <ipv6@ietf.org>, Routing Lossy networks Over Low power and <roll@ietf.org>, Brian Haberman <brian@innovationslab.net>, "Ralph Droms (rdroms)" <rdroms@cisco.com>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 15 Nov 2013 15:26:18 -0000

Kerry Lynn <kerlyn@ieee.org> wrote:
    > I mostly agree Brian;

    > It's a bit touchy because in 802.15.4 a PAN ID is configured
    > administratively and could lead to an 04 interpretation.


    > One could take that argument to the extreme and say that selecting SSID
    > (802.11) or plugging into a wall socket
    > (802.3) is an administrative act.  Let's not be too literal and instead say
    > that the "automatic" zone boundary
    > definition applies to an existing LAN.  If you think about a Link-Local

I offer this definition: an independant outside observer can determine the
boundaries of scope 3 (2, and 1) can be observed without knowledge of the
internal policies of a node.  That's why we can say that it is automatically
defined: there is no choice to make or policy to apply.

This is obvious with a wired network: you just follow the wires.
(The nodes/machines don't even need to be on.)
For a wireless network, you need to have a radio to sniff with, but given
that, you can mostly determine things.

scope 4 is the first scope where a policy *may* come into play.

The thing that broke up the log jam last week was the understanding that
policies may be administratively defined such that the device can make a
decision on it's own, but that this decision is not necessarily visible to an
external observer.

(insert reference to Heisenburg uncertainty principle, and Einstein's hidden
variables if you like)

(I need to follow up to Kerry's reply from last week. I'm not sure that
Pascal read it)

--
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