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

Jerome Haerri <jerome.haerri@eurecom.fr> Thu, 02 February 2017 17:17 UTC

Return-Path: <jerome.haerri@eurecom.fr>
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 D5FA0129495 for <its@ietfa.amsl.com>; Thu, 2 Feb 2017 09:17:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.097
X-Spam-Level:
X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] 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 MSVqiCn82itp for <its@ietfa.amsl.com>; Thu, 2 Feb 2017 09:17:35 -0800 (PST)
Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1E761129494 for <its@ietf.org>; Thu, 2 Feb 2017 09:17:33 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.33,325,1477954800"; d="scan'208,217";a="5715664"
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago2i.eurecom.fr with ESMTP; 02 Feb 2017 18:17:33 +0100
Received: from [192.168.1.11] (LFbn-1-6946-250.w90-116.abo.wanadoo.fr [90.116.128.250]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id EED45DA6; Thu, 2 Feb 2017 18:17:31 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail-DD0B08D7-FC3F-4A3E-AFD3-80AB6270FE29"
Mime-Version: 1.0 (1.0)
From: Jerome Haerri <jerome.haerri@eurecom.fr>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <07e5f826-b99a-9308-8ede-9fb659a9c248@gmail.com>
Date: Thu, 02 Feb 2017 18:17:32 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <CD72343E-1358-4A29-AD98-CEFBD9DA4492@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> <07e5f826-b99a-9308-8ede-9fb659a9c248@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/z46seM_9xEjdOkRS-lnR61-VCQg>
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 17:17:37 -0000

Alex,

Look, I also have to read standards to understand them and sometimes, they are ambiguous...
But here, we have people who actually took part of the writting, of the 802.11p/OCB mode, and clearly and with absolutely no ambiguity stated that beacons are not sent in OCB...we should listen to them I think..

let's not create 'alternative facts' here...a 'trumpization' of the standard work process will get us nowhere..

Best Regards,

Jérôme

Envoyé de mon iPhone

> Le 2 févr. 2017 à 17:58, Alexandre Petrescu <alexandre.petrescu@gmail.com> a écrit :
> 
> 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
>>>> 
>>>> 
>>>> 
>> 
>>