Re: The "nomap" Network Identifier Suffix

Richard Barnes <rlb@ipv.sx> Wed, 27 November 2013 03:51 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881591AE10B for <ietf@ietfa.amsl.com>; Tue, 26 Nov 2013 19:51:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 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] 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 wj2M7P-13O-7 for <ietf@ietfa.amsl.com>; Tue, 26 Nov 2013 19:51:14 -0800 (PST)
Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 268471AE0AB for <ietf@ietf.org>; Tue, 26 Nov 2013 19:51:14 -0800 (PST)
Received: by mail-oa0-f50.google.com with SMTP id n16so7155671oag.9 for <ietf@ietf.org>; Tue, 26 Nov 2013 19:51:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UrDCz4OkapgrVcZMfa1EhGUmcxJ3FkaOD0Moa9XEWEM=; b=RLDvt1L7FRbX6va72Dj06iPft6QAAI9wW/0coBUL7Gtth3gOW3RC9dfgypnnRgIhFO mOcPBN/gbZBVbcajXifAdqI3a4Svszf5531q6O2eYuDVPRpq/CBPq9UL8vgOypzdlARq mNcb12SzxpC9cDRjmCFWDv7OuytV1Gbge6Nay944RsmCuv9itYjb4QYxNqs7nD8m8bs/ x7LpqNnXB9mmhu0ZqjYNcgECbyMx2nWFi9CRcWf6zvP1C6YH5E9fRUdzF0NagHD09BSK zhJa6hj8uV9mCApPcb1UqFfLC+IyZuwv+Q2aoQ+nehnudvtp8Xr8JTaMpYMZl154Q10q IVnQ==
X-Gm-Message-State: ALoCoQl9VgjceNVCemq9EwrgYRwioo1InCgyMwDTIWYfVdi4ScPb64JfEyQWldtoWVVy0xhgZiHi
MIME-Version: 1.0
X-Received: by 10.60.70.209 with SMTP id o17mr4161070oeu.65.1385524273410; Tue, 26 Nov 2013 19:51:13 -0800 (PST)
Received: by 10.60.31.74 with HTTP; Tue, 26 Nov 2013 19:51:13 -0800 (PST)
In-Reply-To: <B15E89D0-3C72-4A5C-9838-BBF305D92A59@mnot.net>
References: <i9n799hrr1vfp4bobt9tc55rn1aip73rts@hive.bjoern.hoehrmann.de> <3D4E298A-FE87-4FD1-BCC2-EF33E7BD4D99@cs.georgetown.edu> <B15E89D0-3C72-4A5C-9838-BBF305D92A59@mnot.net>
Date: Tue, 26 Nov 2013 22:51:13 -0500
Message-ID: <CAL02cgT2LPy37d4EdYtMzCAtT9Q458+ZEfsC1xshVS6j_tVJFg@mail.gmail.com>
Subject: Re: The "nomap" Network Identifier Suffix
From: Richard Barnes <rlb@ipv.sx>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/alternative; boundary="001a113335762509b804ec208266"
Cc: Eric Burger <eburger@cs.georgetown.edu>, Bjoern Hoehrmann <derhoermi@gmx.net>, IETF-Discussion Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2013 03:51:17 -0000

I think we mostly agree here, Mark, but just playing devil's advocate...

If we want things to deploy with any speed, we need the people who want to
deploy them to be able to.  The people who would deploy this sort of policy
mechanism cannot change the 802.11 protocols their WiFi chipsets use, but
they *can* change an SSID or parse an SSID.  If you wait IEEE to make a
standard, and vendors to build it, and ... well, I'll see you in a few
years.

Yes, it's a hack, but the Internet lives on hacks.  And people are using
it, so what's the harm in documenting it?  To make an analogy, how many
RFCs for v4/v6 transition schemes do we have that slam an IPv4 address into
an IPv6 address?

--Richard (who really doesn't have a dog in this fight, but generally likes
the fast path instead of the long, slow, painful, expensive path)






On Tue, Nov 26, 2013 at 5:27 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Separate from the issues surrounding enforcing declared policy, putting
> metadata into identifiers seems like a bad practice.
>
> Besides the issue of scalability — do we really want a SSID that looks
> like “mnot_nomap_guestsallowed_privacyguaranteed_prettyplease” — this
> proposal is squatting on ALL suffixes; someone who wants to define the
> “_guestsallowed” suffix, for example, now can’t do so because it’s in
> contention with _nomap.
>
> Never mind that it’s retroactively assigning semantics to potentially
> existing identifiers.
>
> These issues seem very similar to those raised in the
> draft-nottingham-uri-get-off-my-lawn. It’s very tempting for us as
> standards bodies to encroach upon user-visible identifier space, but doing
> so brings a number of concrete technical problems, as well as a higher
> concern; that these name spaces are explicitly defined to be under user (or
> administrator) control, and taking that control away retroactively
> shouldn’t be something we do.
>
> Cheers,
>
>
> On 26 Nov 2013, at 11:04 pm, Eric Burger <eburger@cs.georgetown.edu>
> wrote:
>
> > Tastes like the ‘evil’ bit, in reverse.
> >
> > On Nov 25, 2013, at 6:50 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> >
> >> Hi,
> >>
> >> My smartphone can turn into a Wifi access point so I can easily use
> >> its Internet connection from my netbook. Problem is that nearby devices
> >> I do not control might report my whereabouts to third parties that map
> >> network equipment to geographic locations. A naming convention for net-
> >> works has been proposed to address this, append "_nomap" to the network
> >> name and "good actors" will ignore it. I thought it would be a good idea
> >> to document this convention in a better place than a single vendor's
> >> blog post, so two years ago today I published
> >>
> >> http://tools.ietf.org/html/draft-hoehrmann-nomap-00
> >>
> >> I think this is a "better than nothing" mechanism and I am not the most
> >> qualified person to document it, and there was pretty much no interest
> >> in the document when I announced it. Still, especially considering more
> >> and more organisations are collecting such data, I think this needs good
> >> documentation. I am looking for volunteers, suggestions, whatever helps
> >> getting that done without a lot of effort on my part...
> >>
> >> Thanks!
> >> --
> >> Björn Höhrmann · mailto:bjoern@hoehrmann.de ·
> http://bjoern.hoehrmann.de
> >> Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
> http://www.bjoernsworld.de
> >> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>