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 957EE12711A
 for <its@ietfa.amsl.com>; Sun,  4 Feb 2018 07:48:52 -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 Sgi6lX60UWQv for <its@ietfa.amsl.com>;
 Sun,  4 Feb 2018 07:48:49 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr
 [132.167.192.148])
 (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 11A2012702E
 for <its@ietf.org>; Sun,  4 Feb 2018 07:48:43 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21])
 by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP
 id w14Fmgi2006380; Sun, 4 Feb 2018 16:48:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1])
 by localhost (Postfix) with SMTP id 2DEA0200C99;
 Sun,  4 Feb 2018 16:48:42 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7])
 by pisaure.intra.cea.fr (Postfix) with ESMTP id 1FE95200BBA;
 Sun,  4 Feb 2018 16:48:42 +0100 (CET)
Received: from [132.166.84.126] ([132.166.84.126])
 by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id
 w14FmfGQ013267; Sun, 4 Feb 2018 16:48:41 +0100
To: =?UTF-8?Q?Fran=c3=a7ois_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: <827a8e03-75fc-7b64-9b2a-2c2bdc0288ed@gmail.com>
Date: Sun, 4 Feb 2018 16:48:41 +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/V-_Chl7T_t7Ug1OrKdbJ9h8VPw8>
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: Sun, 04 Feb 2018 15:48:53 -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 Speciﬁcation 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) Speciﬁcations”; 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.

Thank you for the explanation.  It is useful to understand that DSRC is 
related to ASTM E 2213-03 and that neither refers to 802.11 OCB.

I think in works related to standards and products it is advantageous if 
there is correlation.

For example, in an ideal world, standards talk about "A" and the 
regulation also about "A" and the products and sofware are also labelled 
"A".

In our context, software is labelled "OCB" (kernel drivers), regulation 
talks "DSRC" and standards "802.11p" and "802.11 OCB".
> *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,

I thought "DSRC" is also about Applications and Use-cases.

> 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.

It is one thing to have no restrictions, and another thing to reckon 
that IP is the networking layer.

> 
> *OBU / RSU***
> 
> **
> 
> The CFR (FCC) definitions are:
> 
> /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver

Sigh, it is way different.

An RSU product has many transceivers inside.

> 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.

I think it should be updated to refer to this document.

> /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

Thanks for the definitions.

They are far different from what we need in this draft.

I will see the other suggestions.

Alex

> 
> *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.
> 
> 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
> 

