Re: [gaia] draft-irtf-gaia-alternative-network-deployments. Mitar review, question #4. Classification

Mitar <mmitar@gmail.com> Thu, 14 April 2016 04:25 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 2B41912DEBA for <gaia@ietfa.amsl.com>; Wed, 13 Apr 2016 21:25:34 -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 DypiYaoy-u6c for <gaia@ietfa.amsl.com>; Wed, 13 Apr 2016 21:25:32 -0700 (PDT)
Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 29FA512DE8B for <gaia@irtf.org>; Wed, 13 Apr 2016 21:25:32 -0700 (PDT)
Received: by mail-io0-x241.google.com with SMTP id u185so9515087iod.2 for <gaia@irtf.org>; Wed, 13 Apr 2016 21:25:32 -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:content-transfer-encoding; bh=tDAi/LLzpfwiwNwt75/UXbCz64IqVG+ry7NBGVGyl6U=; b=KnHzFvP6WJsf6tuBE6OJ5mDl/rQopHJvb1lOYCBh95eyxYbnKuOJpNIo80aPwGj4hH /owh4mVZStNKDA5Cgpji0w/YqxEJzV+0qzjzFf82W1a5rk8SDhF3Mdb8n6T5rxEkR0vy 41N7w3j4Ri52S8qytFi+CRqFrlsRNbigr69Ulzho/X9qZi4wjaskxKBkC6jS8nht99w9 h9V3toOUNvjPW4LQHISsxRB5RsK2S7mlgq2Z2QrnYznVS1MlSUykSnXV3/sL3aGvr9Xx RBHFexujlmqGrMsbl0DjfQs4azldgwq0n0rw+X7tYDsLNZVWrjw26PvSBmGaf0kwrjk6 /e0w==
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-transfer-encoding; bh=tDAi/LLzpfwiwNwt75/UXbCz64IqVG+ry7NBGVGyl6U=; b=QrmpDucxiPQK3/iXWff59AQ+U9mQvDQ/Bgvmt/hMMJx19NklRa4eXJ/kRwAb/Etv5X mhsgHKb6MQ7/yBlkCTO4TcIrRfFP58DzK6Z9r5da8gbFdRsYXJcqeVUtz2w16WIZiTuu mwoswvMP0Ab/Pl83kzd8bpoZXRJgU/UTVsfo/8sz0563VmPY8fehk8f475VyOCmYXqu+ sRssYacoFk2vwGOwu7rNM0WQ5bvmi+BuqeuAml1zwt/sCKmyd9ij8dznqsj3iDj+NuBE MEetZP+L0IeNv/vHfE88kYpTTrIaTzu2ehmWKnUAQVZ76TFYZLpF6tF2aYB75FzjLoTa OEHw==
X-Gm-Message-State: AOPr4FV0scR3IsC2XlXMCpFdhwIfaQR1cdftTL8PRTF3vduDRQdDtYUoy0rZAXZ7zn4Zk9efnqpS3RxvILZsyw==
MIME-Version: 1.0
X-Received: by 10.107.173.69 with SMTP id w66mr15209029ioe.182.1460607931615; Wed, 13 Apr 2016 21:25:31 -0700 (PDT)
Received: by 10.107.13.76 with HTTP; Wed, 13 Apr 2016 21:25:31 -0700 (PDT)
In-Reply-To: <00c101d1959c$e3b5e300$ab21a900$@unizar.es>
References: <005c01d194c6$ad5c5540$0814ffc0$@unizar.es> <CAKLmikPMem_N3hZ-538x1x53wptaSUkbXvsHEnS3_hD5m9G74A@mail.gmail.com> <00c101d1959c$e3b5e300$ab21a900$@unizar.es>
Date: Wed, 13 Apr 2016 21:25:31 -0700
Message-ID: <CAKLmikOEWk6r3dZm3RH3TTpomwvHv3u15puc2JmPgkPhExD3qA@mail.gmail.com>
From: Mitar <mmitar@gmail.com>
To: Jose Saldana <jsaldana@unizar.es>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/gaia/4_590EgW_x1iHGqMeL515pwPyU4>
Cc: gaia <gaia@irtf.org>
Subject: Re: [gaia] draft-irtf-gaia-alternative-network-deployments. Mitar review, question #4. Classification
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:25:34 -0000

"Hi!

On Wed, Apr 13, 2016 at 8:55 AM, Jose Saldana <jsaldana@unizar.es> wrote:
> I think "ownership of equipment" can be seen as a part of the "commercial model / promoter". In fact, the text in "Commerical model / promoter" already talks about ownership: " A community that already *owns* some infrastructure shares it with an operator, which uses it for backhauling purposes."

Not sure if you are trying to combine these just so that there would
be not too much changes to the structure of the current draft, but you
should decide which direction you want to go. I think what Vesna also
mentioned in her feedback is the lack of clear ownership
categorization.

How I see it:

- or we see ownership something which is part of the commercial model
category, but then we need to add additional options to this category
to make it clear what are those possible ownership combinations
- or we see ownership something which is orthogonal dimension to the
commercial model and then we list possible options there

Personally, I think ownership is an orthogonal dimension to the
commercial model. But in any case I really think this should be listed
in the table at the beginning of each alternative network description.
The reason is that this is one of the core properties of community
networks (and some other alternative networks). This is in fact one of
main innovations in this space. We can hardly discuss alternative
networks if we do not tackle alternative models of ownership. This is
why I believe ownership should even be its own category. Because then
to the readers it will be much cleaner why are those networks
different:

- they have different business models
- they have different ownership models
- they have different organizational structures
- they exist in areas where traditional ISPs do not (rural areas)
- they use technologies in innovative ways

I think those are really important dimensions along which to describe networks.

I can understand that it is maybe hard to add one more category, but I
think it is really important.

> 4.1.  Commercial model / promoter

BTW, I think word "facilitator" is much better than word "promoter".
Networks are not only about PR. I suggest we replace "promoter" with
"facilitator.

>    The commercial model may have different implications regarding the
>    ownership of the network equipment.  In some cases, each of the users
>    of the community maintains the ownership over the equipment they have
>    contributed, whereas in others there is an entity who owns the
>    equipment, or at least a part of it.

As I wrote above, I think it should be one of categories so that we
categorize each alternative network based on that.

>> If we extend also goals and motivation with additional options, then I think this is
>> closer to be able to cover community networks.
>>
>> > The list of motivations has been expanded as you suggested.
>>
>> Then we should probably add them as used by community networks.
>
> I don't understand the previous sentence. What does "them" refer to? Sorry.

We expanded the category of motivations with new options. Now in the
table at the beginning of the "community networks" section we should
add those new options to the list of motivations people behind
community networks have. There is little use of expanding the list of
possible options if we then do not use them in tables for each type of
alternative networks. Probably also some other alternative networks
fall into one of those extra options.

>> https://wiki.freebsd.org/WifiTDMA
>
> Thanks. I would not include the freebsd link, as it is not working yet.

To my understanding it is working. Where have you seen that it is not?
There are no known issues and there is some future work planned.

>    o  Wi-Fi modified for long distances (WiLD), either with CSMA/CA or
>       with an alternative TDMA MAC [Simo_b].

Also use of non-standard ad-hoc is used in some community networks.
Non-standard because N protocol does not support it. Or non-standard
because beacons are for example disabled.


Mitar

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