Re: [gaia] draft-irtf-gaia-alternative-network-deployments. Mitar review, question #5: Community Networks

Mitar <mmitar@gmail.com> Thu, 14 April 2016 04:33 UTC

Return-Path: <mmitar@gmail.com>
X-Original-To: gaia@ietfa.amsl.com
Delivered-To: gaia@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD5212DCE1 for <gaia@ietfa.amsl.com>; Wed, 13 Apr 2016 21:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6_JJHU93B5Cv for <gaia@ietfa.amsl.com>; Wed, 13 Apr 2016 21:33:39 -0700 (PDT)
Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0693312D5DB for <gaia@irtf.org>; Wed, 13 Apr 2016 21:33:39 -0700 (PDT)
Received: by mail-io0-x243.google.com with SMTP id z133so9489185iod.1 for <gaia@irtf.org>; Wed, 13 Apr 2016 21:33:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=zPwFMtotEaeT80zD3TDxti9nUzDyS1u1WEn95ZykV7M=; b=pMdJL2b7YzqHOy3s+Hqo1cSxP1LGQc4Mu3sty/Ej8yqE8pV14n7/knWfxUU9UipnQR osCw5Jyk7pharCKrokREvS81S9yKgxSuEXwbmxZkw+KyOAZ7h+8VcwHFo8seNkMt2J76 gQbtbWmqADYX2ke8ZlYLc6wE0vA7CZYwOzhsqvCgN/ilKSRVrzs0HAHaGoA0J3VHO563 jJdyfgXc9lU03EZpc1M4615szysukzbPFoM1j2GVCG3BS/x2crplge+JTDMcfUFE+IXX PhdfP9yKwd+aEBhWy2t9uOp6v64KF2rf7iTlNr4m3jP3SiI7bQUHiCGC5jjfTMGUpmLV MnUg==
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; bh=zPwFMtotEaeT80zD3TDxti9nUzDyS1u1WEn95ZykV7M=; b=HS+9pv3rTAmIUHmVziVhLl6j+qUHvU9q0S/iLm6b5iHcHi22yqjzNSH5JeZNomm9qF SGqZmUGWZmKUVbn59fURTiKjvCCFNEtZ+nAZlDyJR47QHVP0Y/E7gZlPFQsZLs36xKXy IbSbeQpce+Mh1GlnvWkYIiFyaIXE+9aUB0Ri/fn6R3I/DrG+8M8aBvVcT0ttkaUGaqg5 nwWmZ+g648vfRhF83uGCabt3EehH4JJClGLGpIJ4AfcX0l1hL7avQwKXFhRxLQG59r80 daZ32fi8AXWmpqMQeNfXBU43rn26OJETAP7Ng5piBJh+y/eanrice+JS665vsxUu8FAV oFCw==
X-Gm-Message-State: AOPr4FVGUXh6AwGjEhJPbfSp7Bi05Zj+xKcuaFVmWGYRMnrcxlCgkwWJzkLh7LrE8eFigtBW/EOfFAnT9e9/dQ==
MIME-Version: 1.0
X-Received: by 10.107.134.8 with SMTP id i8mr13414826iod.130.1460608418280; Wed, 13 Apr 2016 21:33:38 -0700 (PDT)
Received: by 10.107.13.76 with HTTP; Wed, 13 Apr 2016 21:33:38 -0700 (PDT)
In-Reply-To: <00cd01d195a0$2892cb70$79b86250$@unizar.es>
References: <006e01d194c9$063c0870$12b41950$@unizar.es> <CAKLmikNgrjXsqa7JuUzN=4v-iGNEUtXik2HrMp54SaR=-KHvug@mail.gmail.com> <00cd01d195a0$2892cb70$79b86250$@unizar.es>
Date: Wed, 13 Apr 2016 21:33:38 -0700
Message-ID: <CAKLmikOHX3kAYN4PNk0G5nMY6sSputHTuXb6Bx+XDKJKmfv99g@mail.gmail.com>
From: Mitar <mmitar@gmail.com>
To: Jose Saldana <jsaldana@unizar.es>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gaia/xx4w9APoK-vg26ln1kbkFNwyo_w>
Cc: gaia <gaia@irtf.org>
Subject: Re: [gaia] draft-irtf-gaia-alternative-network-deployments. Mitar review, question #5: Community Networks
X-BeenThere: gaia@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Global Access to the Internet for All <gaia.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/gaia>, <mailto:gaia-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gaia/>
List-Post: <mailto:gaia@irtf.org>
List-Help: <mailto:gaia-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/gaia>, <mailto:gaia-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2016 04:33:41 -0000

Hi!

On Wed, Apr 13, 2016 at 9:18 AM, Jose Saldana <jsaldana@unizar.es> wrote:
> What about this?
>
>    The fact of the users adding new infrastructure (i.e. extensibility)
>    can be used to formulate another definition: A Community Network is a
>    network in which any participant in the system may add link segments
>    to the network in such a way that the new segments can support
>    multiple nodes and adopt the same overall characteristics as those of
>    the joined network, including the capacity to further extend the
>    network.  Once these link segments are joined to the network, there
>    is no longer a meaningful distinction between the previous and the
>    new extent of the network.  The term "participant" refers to an
>    individual, who may become user, provider and manager of the network
>    at the same time.  The addition of a new link in a Community Network
>    does not imply any modification of the BGP [RFC4271] peering of the
>    Internet.

This is getting stranger and stranger. There is not really any reason
why community network would not operate so that when new node connects
it auto-reconfigures some of its BGP peerings.

Anyway, I think the original text was better than this now. Old text
was at least redundant from my perspective, this now is adding invalid
claims. :-) Let's just leave it as it was. It describes Internet,
which community networks anyway are (a new generation of it). :-)

>    +-----------------------+-------------------------------------------+
>    | Goals and motivation  | all the goals listed in Section 4.2 may   |
>    |                       | be present                                |
>    +-----------------------+-------------------------------------------+

I like it.

> What about this?
>
>    In Community Networks, profit can only be made by offering services
>    and not simply by supplying the infrastructure, because the
>    infrastructure is neutral, free, and open (mainstream Internet
>    Service Providers base their business on the control of the
>    infrastructure).  In Community Networks, everybody usually keeps the
>    ownership of what he/she has contributed, or leaves the stewardship
>    of the equipment to network as a whole, commons, even loosing track
>    of the ownership of a particular equipment itself, in favor of the
>    community.

I like it.

> PS: This would be the whole subsection:
>
> 5.1.  Community Networks
>
>    +-----------------------+-------------------------------------------+
>    | Commercial            | community                                 |
>    | model/promoter        |                                           |
>    +-----------------------+-------------------------------------------+
>    | Goals and motivation  | all the goals listed in Section 4.2 may   |
>    |                       | be present                                |
>    +-----------------------+-------------------------------------------+
>    | Administration        | non-centralized                           |
>    +-----------------------+-------------------------------------------+
>    | Technologies          | Wi-Fi [IEEE.802-11-2012], optical fiber   |

Maybe mentioning that it can be both standard and non-standard? So
community networks are probably the most open to hacking and changing
things to non-standard operations from all alternative networks. We
should convey that.

>    Hardware and software used in Community Networks can be very diverse,
>    even inside one network.

Diverse and customized?

Otherwise I like it (pending possible category of ownership).


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m