Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 02 February 2018 14:29 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 2D06612D950 for <its@ietfa.amsl.com>; Fri, 2 Feb 2018 06:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 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_MED=-2.3, 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 Kbb-hQE7W7F2 for <its@ietfa.amsl.com>; Fri, 2 Feb 2018 06:29:48 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0851512D881 for <its@ietf.org>; Fri, 2 Feb 2018 06:29:47 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w12ETkC6024814; Fri, 2 Feb 2018 15:29:46 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2B2E9203DFA; Fri, 2 Feb 2018 15:29:46 +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 1D1C4203BA6; Fri, 2 Feb 2018 15:29:46 +0100 (CET)
Received: from [132.166.85.102] ([132.166.85.102]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w12ETj78014502; Fri, 2 Feb 2018 15:29:45 +0100
To: François Simon <fygsimon@gmail.com>
Cc: its@ietf.org
References: <1517217856.4315.32.camel@it.uc3m.es> <006601d39910$bdcf1cf0$396d56d0$@gmail.com> <d539c9e9-f9e4-b6c3-e8fc-c6273a7067ce@gmail.com> <000101d39c0f$e3b32f90$ab198eb0$@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <707c9f11-c10e-f1e3-f68d-ab98fc632ca7@gmail.com>
Date: Fri, 02 Feb 2018 15:29:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <000101d39c0f$e3b32f90$ab198eb0$@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/wVXn4pYYmdDe7-3ZbUoPIsf8cao>
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 02 Feb 2018 14:29:51 -0000


Le 02/02/2018 à 11:23, François Simon a écrit :
> Mr. Petrescu,
> 
> Let's try one more time to clarify the FCC DSRC (in US only) issue.
> 
> *FCC – DSRC*
> 
> *Background:***
> 
> **
> 
> -** The US Federal Communications Commission (FCC) Dedicated Short Range 
> Communication (DSRC) is defined in the Code of Federal Regulations (CFR) 
> 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010;
> 
> -This includes the ASTM E 2213-03 standard: “Standard Specification for 
> Telecommunications and Information Exchange Between Roadside and Vehicle 
> Systems — 5 GHz Band Dedicated Short Range Communications (DSRC) Medium 
> Access Control (MAC) and Physical Layer (PHY) Specifications”; approved 
> July 10, 2003. The standard is derived from IEEE 802.11a and, in most 
> part, is equivalent to IEEE 802.11 OCB. To date, the DSRC CFRs do not 
> specify IEEE 802.11 OCB.
> 
> -The related CFRs state that DSRC shall comply with the ASTM E 2213-03.
> 
> *Overview of DSRC functions:***
> 
> **
> 
> The functions listed in DSRC related CFRs are, in general, specified in 
> the ASTM E 2213-03 and IEEE 802.11 OCB:
> 
> -MAC service definition, frame format, and procedures;
> 
> -PHY Orthogonal frequency division multiplexing (OFDM);
> 
> -PHY Service Data Unit format and modulations (data rates):
> 
> -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum mask;
> 
> -Individual Channel use: Safety applications, non-safety applications, 
> and priorities.
> 
> *Protocols***
> 
> **
> 
> DSRC being uniquely a MAC and PHY communications service, there here no 
> restriction on Transport and Network protocols that can be used (except 
> for the LCC specified by reference in IEEE 802.11 OCB). In the US, the 
> WAVE standards (IEEE 1609 series) specify these protocols when using 
> DSRC as the communication service.
> 
> *OBU / RSU***
> 
> **
> 
> The CFR (FCC) definitions are:
> 
> /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver that is 
> mounted along a road or pedestrian passageway. An RSU may also be 
> mounted on a vehicle or is hand carried, but it may only operate when 
> the vehicle or hand- carried unit is stationary. Furthermore, an RSU 
> operating under this part is restricted to the location where it is 
> licensed to operate. However, portable or hand-held RSUs are permitted 
> to operate where they do not interfere with a site-licensed operation. A 
> RSU broadcasts data to OBUs or exchanges data with OBUs in its 
> communications zone. An RSU also provides channel assignments and 
> operating instructions to OBUs in its communications zone, when 
> required./- [CFR 90.7 - Definitions] - Revised as October 2010.
> 
> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is 
> normally mounted in or on a vehicle, or which in some instances may be a 
> portable unit. An OBU can be operational while a vehicle or person is 
> either mobile or stationary. The OBUs receive and contend for time to 
> transmit on one or more radio frequency (RF) channels. Except where 
> specifically excluded, OBU operation is permitted wherever vehicle 
> operation or human passage is permitted. The OBUs mounted in vehicles 
> are licensed by rule under part 95 of this chapter and communicate with 
> Roadside Units (RSUs) and other OBUs. Portable OBUs are also licensed by 
> rule under part 95 of this chapter. OBU operations in the Unlicensed 
> National Information Infrastructure (UNII) Bands follow the rules in 
> those bands./- [CFR 90.7 - Definitions] - October 2010
> 
> *IPWAVE Issue***
> 
> **
> 
> /“The problem with the FCC definition of OBU is that it has no 
> relationship to IP.  Worse, that FCC definition has no indication that 
> it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do 
> you see what I mean?”///
> 
> //
> 
> Correct; the OBU has no relationship with IP and is not intended to. IP 
> is a network protocol.  If an On-Board Unit (OBU) device is required to 
> exchange IP, it needs to be dealt in protocol(s) and/or Management in 
> higher layers similar to WAVE within the On-Board Equipment (OBE) .
> 
> /“Do you think FCC will mind if we use the term OBU in this draft to 
> mean something else?  I, and a colleague, think that FCC would not mind.”///
> 
> //
> 
> Depending of the reader. If one is familiar with DSRC, OBU and RSU as 
> defined by FCC will come in mind. As far as I know, “OBU” and “RSU” are 
> not registered and could be used for other definitions (something like 
> “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My 
> suggestion to the IPWAVE team is to use “OBE and RSE”.
> 
> This is my personal view as I donot represent any involved interest.  If 
> any one has questions, let me know.

If we want to go with OBE instead of OBU then we must be ready to defend 
it in our respective contexts.  Are we ready to?

(I already have a hard time with telling people "802.11p" no longer 
exists, especially to those who are afraid I want to use LTE to 'kill' 
802.11p; and now to tell them to use "OBE" instead of "OBU" just in 
order to use IP seems like an additional effort).

All the OBUs I use do run IP.

Can FCC change their definition to include a reference to this IP draft?

Alex

> 
> Francois Simon
> 
> Lojik Technologies
> 
> -----Original Message-----
> 
> From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandre Petrescu
> 
> Sent: Monday, January 29, 2018 10:08 AM
> 
> To: its@ietf.org
> 
> Subject: Re: [ipwave] Shepherd review of 
> draft-ietf-ipwave-ipv6-over-80211ocb-12
> 
> 
> 
> Le 29/01/2018 à 15:52, François Simon a écrit :
> 
>> My comments arewithin the text*[Fygs.......]*.
> 
> [...]
> 
>> In the terminology section, the OBU term is mentioned to be defined 
> 
>> outside the IETF. This is fine, but we have to provide a reference.
> 
>> And even with that, it would not harm to include some short definition 
> 
>> to provide context. The RSU term is also defined outside the IETF and 
> 
>> there is quite a lot of text provided (I think the relevant part is 
> 
>> the last sentence, the one starting with "The difference between..."). 
> 
>> Both terms should be handled in the same way.
> 
>> 
> 
>> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I have  
> 
>> already provided that information**and references multiple
> 
>> times.]***
> 
> The problem with the FCC definition of OBU is that it has no 
> relationship to IP.  Worse, that FCC definition has no indication that 
> it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do 
> you see what I mean?
> 
> Do you think FCC will mind if we use the term OBU in this draft to mean 
> something else?  I, and a colleague, think that FCC would not mind.
> 
> Alex
> 
> _______________________________________________
> 
> its mailing list
> 
> its@ietf.org
> 
> https://www.ietf.org/mailman/listinfo/its
>