Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB (non) use of beacons

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 02 February 2017 16:59 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FFB1294E2 for <its@ietfa.amsl.com>; Thu, 2 Feb 2017 08:59:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Level:
X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 F2J8kUSCis-X for <its@ietfa.amsl.com>; Thu, 2 Feb 2017 08:59:23 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BD61294CD for <its@ietf.org>; Thu, 2 Feb 2017 08:59:22 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v12GxHMa016509; Thu, 2 Feb 2017 17:59:17 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9DA6F20A1F3; Thu, 2 Feb 2017 17:59:17 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 90A1D2028C2; Thu, 2 Feb 2017 17:59:17 +0100 (CET)
Received: from [132.166.84.79] ([132.166.84.79]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v12GxHiF010710; Thu, 2 Feb 2017 17:59:17 +0100
To: Jerome Haerri <jerome.haerri@eurecom.fr>
References: <148052970170.9607.12043916621198119260.idtracker@ietfa.amsl.com> <222853d1-235d-cd4e-844b-4ea6091bfb2b@cea.fr> <009901d27c83$3bd599e0$b380cda0$@eurecom.fr> <ABE9BD89094E4DCBA199B459F8176F2E@SRA6> <687e75fd-7e89-211e-bce3-fea861d7baf0@gmail.com> <2B86CDDB-C9AA-4605-B9B6-3DA6F2ABBE7F@eurecom.fr>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <07e5f826-b99a-9308-8ede-9fb659a9c248@gmail.com>
Date: Thu, 02 Feb 2017 17:58:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <2B86CDDB-C9AA-4605-B9B6-3DA6F2ABBE7F@eurecom.fr>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/3DcDaSgXXP1OR7k0vZzqUIZpLbY>
Cc: dickroy@alum.mit.edu, its@ietf.org
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB (non) use of beacons
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2017 16:59:26 -0000

Dear Jérôme,

Le 02/02/2017 à 17:00, Jerome Haerri a écrit :
> Dear Alex,
>
> well, If I cross on red lights, we cannot then say that as I did,
> then crossing on red lights is allowed..

Except that here we are making the red lights too :-)

> if OCB implementations are sending beacons, then it is an
> implementation issue..it does not mean that beacons should be
> transmitted by the standards..

Or vice-versa: the stds may need to reflect what's happening in practice.

In my lab there are such beacons.  In other lab too.  It is for this
reason that I have the doubt.

I can not put in an Internet Draft (I-D) text that simply comes from
other standards.  I-D should contain text that is about running code.

And, of course, I need to put in this I-D what the WG thinks is good.
This is why I am asking.

> Would still suggest to keep the original version or cut-past the
> exact statement from 802.11-2016 about allowed messages in OCB mode.
>
> But just asking frankly: why do you want to keep this statement
> about beacons (allowing them to be sent) ? we spend too much time on
> useless details and not on other key issues..

Because I have no guarantee that if I put there "Beacons MUST NOT be
sent" implementers will do so.

I wonder whether there is a reason why Beacons are there in these OCB
implementations that send them.  Or maybe it's just because they are
forgotten there during migration from .11bgn driver to .11-OCB driver.

Alex

>
> Best Regards,
>
> Jérôme
>
> Envoyé de mon iPhone
>
>> Le 2 févr. 2017 à 16:20, Alexandre Petrescu
>> <alexandre.petrescu@gmail.com> a écrit :
>>
>> But some OCB implementations do send Beacons.
>>
>> In that sense, I propose to say the following.
>>
>>>> 4.  Aspects introduced by the OCB mode to 802.11
>>>>
>>>> In the IEEE 802.11 OCB mode, all nodes in the wireless range
>>>> can directly communicate with each other without
>>>> authentication/ association procedures.  Briefly, the IEEE
>>>> 802.11 OCB mode has the following properties:
>>>>
>>>> o  Wildcard BSSID (i.e., all bits are set to 1) used by each
>>>> node
>>
>> old:
>>>> o  No beacons transmitted
>>
>> new:
>>>> o  OCB implementations do not receive beacons and most OCB
>>>> implementations do not transmit Beacons.
>>
>> Alex
>>
>>
>>> Le 01/02/2017 à 20:20, Dick Roy a écrit : To reiterate, in OCB
>>> operation there are NO beacons and there are NO APs.
>>>
>>>
>>>
>>> RR
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
*From:*Jérôme Härri [mailto:jerome.haerri@eurecom.fr] *Sent:*
>>> Wednesday, February 1, 2017 4:04 AM *To:* 'Alexandre Petrescu';
>>> its@ietf.org *Subject:* Re: [ipwave]
>>> draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does use beacons
>>>
>>>
>>>
>>> Dear all,
>>>
>>>
>>>
>>> I do not agree and I would be happy to have the reference in the
>>>  IEEE 802.11-2016 stating otherwise.
>>>
>>>
>>>
>>> In the 802.11 standard, it clearly state the following line:
>>>
>>>
>>>
>>> When dot11OCBActivated is true in a STA:
>>>
>>> " The STA _may send management frames of subtype Action_ and, if
>>> the STA maintains a TSF Timer, subtype Timing Advertisement "
>>>
>>> " The STA may send _control frames_, _except_ those of _subtype
>>> PS-Poll, CF-End, and CF-End + CFAck_ "
>>>
>>> " The STA may send _data frames of subtype Data, Null, QoS Data,
>>> and QoS Null_. "
>>>
>>>
>>>
>>> A beacon is a management frame, but not of a class Action, so it
>>>  _cannot be transmitted when dot11OCBActivated_ is true in a
>>> STA. But I agree that it is ambiguous…nevertheless, I would then
>>> replace in the draft the mention of what OCB can do or can’t do
>>> (e.g. sending beacons) with the exact 802.11-2016 statements.
>>> This would avoid misunderstanding.
>>>
>>>
>>>
>>> But even if it could be possible, this does not make much sense.
>>> A beacon is transmitted on a channel you need to connect to get
>>> BSS information and also to get the right frequency. In case of
>>> OCB (outside context of a BSS), it is not required. But the real
>>> question is ‘why’ would we need beacon, assuming it could be
>>> transmitted?
>>>
>>>
>>>
>>> Best Regards,
>>>
>>>
>>>
>>> Jérôme
>>>
>>>
>>>
>>> -----Original Message----- From: its
>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
>>> Sent: Wednesday 01 February 2017 11:51 To: its@ietf.org Subject:
>>> [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does
>>> use beacons
>>>
>>>
>>>
>>> draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does use beacons
>>>
>>>
>>>
>>> Hello IPWAVErs,
>>>
>>>
>>>
>>> It was suggested in private that, contrary to what the draft
>>> says, the .11-OCB does use beacons.
>>>
>>>
>>>
>>> As such, the following line should disappear from the draft:
>>>
>>>
>>>
>>>> 4.  Aspects introduced by the OCB mode to 802.11
>>>
>>>>
>>>
>>>> In the IEEE 802.11 OCB mode, all nodes in the wireless range
>>>> can
>>>
>>>> directly communicate with each other without authentication/
>>>
>>>> association procedures.  Briefly, the IEEE 802.11 OCB mode has
>>>> the
>>>
>>>> following properties:
>>>
>>>>
>>>
>>>> o  Wildcard BSSID (i.e., all bits are set to 1) used by each
>>>> node
>>>
>>>>
>>>
>>>> o  [strike through] No beacons transmitted
>>>
>>>
>>>
>>> Yours,
>>>
>>>
>>>
>>> Alex
>>>
>>>
>>>
>
>