From nobody Mon May 1 07:11:06 2017 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A46129483; Mon, 1 May 2017 07:11:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: suresh.krishnan@gmail.com, cjbc@it.uc3m.es, its@ietf.org, ipwave-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149364786636.9991.7879978600573251023.idtracker@ietfa.amsl.com> Date: Mon, 01 May 2017 07:11:06 -0700 Archived-At: Subject: [ipwave] ipwave - Update to a Meeting Session Request for IETF 99 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 14:11:06 -0000 An update to a meeting session request has just been submitted by Carlos J. Bernardos, a Chair of the ipwave working group. --------------------------------------------------------- Working Group Name: IP Wireless Access in Vehicular Environments Area Name: Internet Area Session Requester: Carlos Bernardos Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: l2sm saag rtgarea manet 6man 6lo intarea stir lamps nfvrg detnet Second Priority: lime isis i2nsf ospf roll dhc cfrg sfc dmm People who must be present: Russ Housley Suresh Krishnan Carlos J. Bernardos Resources Requested: Special Requests: --------------------------------------------------------- From raghav.kulkarni@unex.com.tw Fri May 12 15:33:54 2017 Return-Path: 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 788551314C0 for ; Fri, 12 May 2017 15:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 2-bJ9XYX_aTv for ; Fri, 12 May 2017 15:33:52 -0700 (PDT) Received: from smtp6.hibox.hinet.net (smtp6.hibox.hinet.net [210.71.187.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADE2131468 for ; Fri, 12 May 2017 15:30:16 -0700 (PDT) X-MID: 43643400 X-EnvelopeFrom: raghav.kulkarni@unex.com.tw X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CtBADrNRZZ/xY8EqxdHgYMhDeBDAe3XiSGAAKFXBQBAgEBAQEBAQGBE4UPCgY9DAEIHBkCDgEJFCUPB0EZu0gmAoNLhlwBAQEHAQEBASQFhlqEeYEkhAuCCQyDEQWJRIZqeYxjgVs1kQuLAheGUnCSCAGBSjaBIAtPfIcTWIhrAQEB X-IronPort-AV: E=Sophos;i="5.38,332,1491235200"; d="scan'208";a="43643400" Received: from unknown (HELO hb2-smtpbko02.hibox.hinet.net) ([172.18.60.22]) by smtp2.hibox.hinet.net with ESMTP; 13 May 2017 06:30:13 +0800 Received: from unknown (HELO hb2-http03-zone.hibox.hinet.net) ([172.16.10.16]) by hb2-smtpbko02.hibox.hinet.net with ESMTP; 13 May 2017 06:30:13 +0800 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Ov9A5Dg6SfdPdW8SdszJlg)" Received: from hibox.hinet.net ([unknown] [172.16.10.26]) by hb2-http03-zone.hibox.hinet.net (Sun Java(tm) System Messaging Server 7u2-7.05 64bit (built Jul 30 2009)) with ESMTPA id <0OPV00I9Z2IDSS50@hb2-http03-zone.hibox.hinet.net> for its@ietf.org; Sat, 13 May 2017 06:30:13 +0800 (CST) Received: from [172.16.10.26] (Forwarded-For: 98.6.1.82) by hb2-http06-zone.hibox.hinet.net (mshttpd); Fri, 12 May 2017 17:30:13 -0500 From: Raghav Kulkarni To: its@ietf.org Message-id: Date: Fri, 12 May 2017 17:30:13 -0500 X-Mailer: Oracle Communications Messenger Express 7.0.5.34.0 64bit (built Oct 14 2014) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: References: Archived-At: X-Mailman-Approved-At: Sat, 13 May 2017 03:17:58 -0700 Subject: [ipwave] Request to join Group/mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 00:07:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Ov9A5Dg6SfdPdW8SdszJlg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi there=2C=A0 =A0 =A0We have products (V2X-On Board unit=2C Road side unit) compliant = with 802=2E11p standard=2E I would like to join the group/mailing list w= hich discusses work related to 802=2E11p =26 IPv6 usage=2E Pls add me to= the mailing list=2E My email id is=3A =3Craghav=2Ekulkarni=40unex=2Ecom= =2Etw=3E=A0 Regards=2C Raghav=2E ------------------------ Raghav Kulkarni Senior Application Engineer - V2X Division Unex Technology Corporation - Zhubei City=2C Taiwan 11F-3=2C No=2E 100=2C Sec=2E 1=2C Jiafeng 11th Road +886-3-6578188 Ext=2E 3156 (Office)=2C +886-972718472 (Mobile) www=2Eunex=2Ecom=2Etw --Boundary_(ID_Ov9A5Dg6SfdPdW8SdszJlg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: inline Hi there, 
   We have products (V2X-On Board unit, Road side unit) compliant with 802.11p standard. I would like to join the group/mailing list which discusses work related to 802.11p & IPv6 usage. Pls add me to the mailing list. My email id is: <raghav.kulkarni@unex.com.tw> 

Regards,
Raghav.



------------------------
Raghav Kulkarni
Senior Application Engineer - V2X Division
Unex Technology Corporation - Zhubei City, Taiwan
11F-3, No. 100, Sec. 1, Jiafeng 11th Road
+886-3-6578188 Ext. 3156 (Office), +886-972718472 (Mobile)
www.unex.com.tw



--Boundary_(ID_Ov9A5Dg6SfdPdW8SdszJlg)-- From nobody Sun May 14 10:29:43 2017 Return-Path: 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 7EA3B129521 for ; Sun, 14 May 2017 10:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] 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 CfGz8r0u1Su1 for ; Sun, 14 May 2017 10:29:38 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EAED129B81 for ; Sun, 14 May 2017 10:26:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CA765300572 for ; Sun, 14 May 2017 13:26:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5Ki53Hk3TOlv for ; Sun, 14 May 2017 13:26:40 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 231BA30029F; Sun, 14 May 2017 13:26:39 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7A4C87FA-15FF-45A0-8C4B-3C91FC09A6D6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 14 May 2017 13:26:39 -0400 In-Reply-To: Cc: its To: Raghav Kulkarni References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] Request to join Group/mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 17:29:40 -0000 --Apple-Mail=_7A4C87FA-15FF-45A0-8C4B-3C91FC09A6D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please go to https://www.ietf.org/mailman/listinfo/its = to subscribe. Russ > On May 12, 2017, at 6:30 PM, Raghav Kulkarni = wrote: >=20 > Hi there,=20 > We have products (V2X-On Board unit, Road side unit) compliant with = 802.11p standard. I would like to join the group/mailing list which = discusses work related to 802.11p & IPv6 usage. Pls add me to the = mailing list. My email id is: =20 >=20 > Regards, > Raghav. --Apple-Mail=_7A4C87FA-15FF-45A0-8C4B-3C91FC09A6D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Please go to https://www.ietf.org/mailman/listinfo/its to = subscribe.

Russ


On May 12, 2017, at 6:30 PM, Raghav Kulkarni <raghav.kulkarni@unex.com.tw> wrote:

Hi there, 
   We have products (V2X-On Board unit, Road side = unit) compliant with 802.11p standard. I would like to join the = group/mailing list which discusses work related to 802.11p & IPv6 = usage. Pls add me to the mailing list. My email id is: <raghav.kulkarni@unex.com.tw> 

Regards,
Raghav.

= --Apple-Mail=_7A4C87FA-15FF-45A0-8C4B-3C91FC09A6D6-- From nobody Thu May 18 02:44:27 2017 Return-Path: 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 5594512EBDF for ; Thu, 18 May 2017 02:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.367 X-Spam-Level: ** X-Spam-Status: No, score=2.367 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no 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 z5DjaF9gBh8m for ; Thu, 18 May 2017 02:44:24 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 AE83212EBC7 for ; Thu, 18 May 2017 02:39:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v4I9dNqg024866 for ; Thu, 18 May 2017 11:39:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 062C1202876 for ; Thu, 18 May 2017 11:39:23 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F018F20283B for ; Thu, 18 May 2017 11:39:22 +0200 (CEST) Received: from [132.166.85.90] ([132.166.85.90]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4I9dM2n020132 for ; Thu, 18 May 2017 11:39:22 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: Date: Thu, 18 May 2017 11:39:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-02 - minor textual issues 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 09:44:26 -0000 Hello, A set of private comments early March pointed to a need of clarifying a few aspects. Here is the resolution. OLD: > The IPv6 network layer operates on 802.11 OCB in the same manner as > it operates on 802.11 WiFi. This makes think that, below IPv6, 802.11 OCB works as 802.11 WiFi works. It is not true. As such, the resolution is this. NEW: > The IPv6 network layer operates on 802.11 OCB in the same manner as > it operates on 802.11 WiFi, with a few particular exceptions. End issue. OLD: > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet > Adaptation Layer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > 802.11 WiFi MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 802.11 WiFi PHY | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this figure, a clarification was requested, in the form of adding a figure caption clarifying whether this represents a WiFi profile or a OCB profile. At this time I dont know how to add figure captions in xml2rfc, but the clarification can be added right before the figure. This is the clarification: NEW: > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet > Adaptation Layer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > 802.11 WiFi MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 802.11 WiFi PHY | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > (in the above figure, a WiFi profile is represented; this is used > also for OCB profile.) End issue. OLD: > RSU: Road Side Unit. An IP router equipped with, or connected to, at > least one interface that is 802.11 and that is an interface that > operates in OCB mode. A comment was made stating that an RSU is not a router, and that an RSU may be connected to a router via an interface, e.g. Ethernet, to access the infrastructure if required. But I think that some Road Side Units are indeed IP routers and they access the infrastructure and the Internet. This is an important point when using the IP protocol - be connected. I think I keep that text that way at this time. End issue. OLD: > The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010 > [ieee802.11p-2010] as an amendment to the 802.11 specifications It was suggested that the "802.11 specifications" are in fact "IEEE Std 802.11-2007". As such the resolution is: NEW: > The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010 > [ieee802.11p-2010] as an amendment to IEEE Std 802.11-2007 End issue. OLD: > The used identifier of BSS (BSSID) has a hexadecimal value always > ff:ff:ff:ff:ff:ff (48 '1' bits, or the 'wildcard' BSSID), It was suggested that the base 16 numerical notation convention is 0xffffffffffff, and not ff:ff:ff:ff:ff:ff. As such the resolution is this new text: NEW: > The used identifier of BSS (BSSID) has a hexadecimal value always > 0xffffffffffff (48 '1' bits, represented as MAC address > ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' BSSID) End issue. OLD: > On the hand It was suggested it is not goog English expression. So it becomes: NEW: > On the other hand End issue. OLD: > Prohibition of IPv6 on some channels relevant for the PHY of IEEE > 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on > which 802.11a/b/g/n runs; at the time of writing, this prohibition is > explicit in IEEE 1609 documents. It was suggested that this is not a PHY prohibition, but rather a higher layer protocols providing services to the application. As such the new text is the following: NEW: > Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, > as opposed to IPv6 not being prohibited on any channel on which > 802.11a/b/g/n runs; at the time of writing, this prohibition is > explicit at higher layer protocols providing services to the > application; these higher layer protocols are specified in IEEE 1609 > documents. End issue. OLD: > In vehicular communications using 802.11-OCB links, there are strong > privacy concerns with respect to addressing. While the 802.11-OCB > standard does not specify anything in particular with respect to MAC > addresses It has been suggested that there is something to think about here, which may affect the above statement: there is at least one country where the vehicle|driver information, be it physical or electronic, must be allowed access by law enforcement if so required. This is noted. I suggest we discuss this separately. At this time I do not modify this text. End issue. OLD: > If IPv6 packets of size larger than 1500 bytes are sent on an > 802.11-OCB interface then the IP stack will fragment. There was a question whether we should substitute "SAP - Service Access Point" for "interface" in the above phrase. I think the current text is right: it talks about an interface card, not about a SAP between layers. NEW: > If IPv6 packets of size larger than 1500 bytes are sent on an > 802.11-OCB interface card then the IP stack will fragment. End issue. OLD: > +--------+ +-------+ > | | 802.11-OCB Link | | > ---| Router |--------------------------------| Host | > | | | | > +--------+ +-------+ There was a question whether that "802.11-OCB Link" is the air interface, and, if yes, then the question further asks whether the OBU or RSU is integrated int he router and host? The clarification is that the Host may be an OBU (that is not a IP router) and the Router may be a Road Side Unit that is an IP router. 'Host' and 'Router' are terms defined. End issue. OLD: > There are considerations for 2 or more IEEE 802.11-OCB interface > cards per vehicle. For each vehicle taking part in road traffic, one > IEEE 802.11-OCB interface card MUST be fully allocated for Non IP > safety-critical communication. Any other IEEE 802.11-OCB may be used > for other type of traffic. There was a comment stating that while "fully allocated" certaiinly improves performance in many ways, that is not a MUST. As such, the new clarified text is the following. NEW: > There are considerations for 2 or more IEEE 802.11-OCB interface > cards per vehicle. For each vehicle taking part in road traffic, one > IEEE 802.11-OCB interface card could be fully allocated for Non IP > safety-critical communication. Any other IEEE 802.11-OCB may be used > for other type of traffic. End of minor textual issues. Alex From nobody Thu May 18 06:39:08 2017 Return-Path: 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 43943129A9B for ; Thu, 18 May 2017 06:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001] 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 7cm2LsQ4DXpx for ; Thu, 18 May 2017 06:39:05 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBF0129AA8 for ; Thu, 18 May 2017 06:33:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AEF12300526 for ; Thu, 18 May 2017 09:33:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q4VjLRfRgfTQ for ; Thu, 18 May 2017 09:33:48 -0400 (EDT) Received: from [5.5.33.141] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id DD70F30029F; Thu, 18 May 2017 09:33:47 -0400 (EDT) From: Russ Housley Message-Id: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_94159F79-94BC-4431-959B-F4DE722D46D9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 18 May 2017 09:33:49 -0400 In-Reply-To: Cc: "its@ietf.org" To: Alexandre Petrescu References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 13:39:06 -0000 --Apple-Mail=_94159F79-94BC-4431-959B-F4DE722D46D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 18, 2017, at 5:39 AM, Alexandre Petrescu = wrote: >=20 > OLD: >> RSU: Road Side Unit. An IP router equipped with, or connected to, at >> least one interface that is 802.11 and that is an interface that >> operates in OCB mode. >=20 > A comment was made stating that an RSU is not a router, and that an = RSU > may be connected to a router via an interface, e.g. Ethernet, to = access > the infrastructure if required. >=20 > But I think that some Road Side Units are indeed IP routers and they > access the infrastructure and the Internet. This is an important = point > when using the IP protocol - be connected. >=20 > I think I keep that text that way at this time. >=20 > End issue. Alex: Some RSUs will be routers, but others will not. For example, an RSU = that sends messages to vehicles about foggy conditions does not need to = be a router. I think the definition should allow both cases. Russ --Apple-Mail=_94159F79-94BC-4431-959B-F4DE722D46D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

OLD:
RSU: Road Side Unit. An IP = router equipped with, or connected to, at
least one = interface that is 802.11 and that is an interface that
operates in OCB mode.

A comment was made stating that an RSU is not a = router, and that an RSU
may be connected to a router via = an interface, e.g. Ethernet, to access
the infrastructure if = required.

But I think that some Road Side = Units are indeed IP routers and they
access the infrastructure and = the Internet.  This is an important point
when using the IP protocol - be = connected.

I think I keep that text that = way at this time.

End = issue.

Alex:

Some RSUs will be routers, but others will not.  For = example, an RSU that sends messages to vehicles about foggy conditions = does not need to be a router.  I think the definition should allow = both cases.

Russ

= --Apple-Mail=_94159F79-94BC-4431-959B-F4DE722D46D9-- From nobody Thu May 18 06:43:24 2017 Return-Path: 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 6D525127A90 for ; Thu, 18 May 2017 06:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 feBiOOu39NDL for ; Thu, 18 May 2017 06:43:22 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3161293EE for ; Thu, 18 May 2017 06:38:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E27B2300526 for ; Thu, 18 May 2017 09:38:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wiKpaBmNUCcA for ; Thu, 18 May 2017 09:38:05 -0400 (EDT) Received: from [5.5.33.141] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 6A24D30029F; Thu, 18 May 2017 09:38:05 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7222925F-6A5B-47D7-8052-B6D60FA019A8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 18 May 2017 09:38:06 -0400 In-Reply-To: Cc: "its@ietf.org" To: Alexandre Petrescu References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [ipwave] 802.11p minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 13:43:23 -0000 --Apple-Mail=_7222925F-6A5B-47D7-8052-B6D60FA019A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 18, 2017, at 5:39 AM, Alexandre Petrescu = wrote: >=20 > OLD: >> The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010 >> [ieee802.11p-2010] as an amendment to the 802.11 specifications >=20 > It was suggested that the "802.11 specifications" are in fact "IEEE = Std > 802.11-2007". As such the resolution is: >=20 > NEW: >> The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010 >> [ieee802.11p-2010] as an amendment to IEEE Std 802.11-2007 >=20 > End issue. Alex: I do not believe that the "(TM)" should appear in the name. I suggest = IEEE Std 802.11p-2010. Also, it might help people locate the specification if we tell people = that OCB was first specified in IEEE Std 802.11p-2010 as an amendment to = IEEE Std 802.11-2007, and then it was incorporated into the base = standard in =E2=80=A6 Russ --Apple-Mail=_7222925F-6A5B-47D7-8052-B6D60FA019A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

OLD:
The link 802.11 OCB was = specified in IEEE Std 802.11p(TM)-2010
[ieee802.11p-2010] = as an amendment to the 802.11 specifications

It was suggested that the "802.11 = specifications" are in fact "IEEE Std
802.11-2007".  As such the = resolution is:

NEW:
The link 802.11 OCB was = specified in IEEE Std 802.11p(TM)-2010
[ieee802.11p-2010] = as an amendment to IEEE Std 802.11-2007

End issue.

Alex:

I do not believe that the "(TM)" should = appear in the name.  I suggest IEEE Std 802.11p-2010.

Also, it might help = people locate the specification if we tell people that OCB was first = specified in IEEE Std 802.11p-2010 as an amendment to IEEE Std = 802.11-2007, and then it was incorporated into the base standard in = =E2=80=A6

Russ

= --Apple-Mail=_7222925F-6A5B-47D7-8052-B6D60FA019A8-- From nobody Thu May 18 06:49:17 2017 Return-Path: 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 35C901294F4 for ; Thu, 18 May 2017 06:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001] 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 Wy6TVMhp7thJ for ; Thu, 18 May 2017 06:49:14 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CEE1294B2 for ; Thu, 18 May 2017 06:43:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A9993300538 for ; Thu, 18 May 2017 09:43:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id azmpsyb_dXOk for ; Thu, 18 May 2017 09:43:49 -0400 (EDT) Received: from [5.5.33.141] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 2093F300435; Thu, 18 May 2017 09:43:49 -0400 (EDT) From: Russ Housley Message-Id: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F788A224-5C30-4CEC-94DA-71C9B5C90930" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 18 May 2017 09:43:50 -0400 In-Reply-To: Cc: "its@ietf.org" To: Alexandre Petrescu References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [ipwave] MAC Address minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 13:49:16 -0000 --Apple-Mail=_F788A224-5C30-4CEC-94DA-71C9B5C90930 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 18, 2017, at 5:39 AM, Alexandre Petrescu = wrote: >=20 > OLD: >> In vehicular communications using 802.11-OCB links, there are strong >> privacy concerns with respect to addressing. While the 802.11-OCB >> standard does not specify anything in particular with respect to MAC >> addresses >=20 > It has been suggested that there is something to think about here, = which > may affect the above statement: there is at least one country where = the > vehicle|driver information, be it physical or electronic, must be > allowed access by law enforcement if so required. >=20 > This is noted. I suggest we discuss this separately. >=20 > At this time I do not modify this text. >=20 > End issue. IEEE 1609 does impose MAC address requirements. Is this the right place = to call that out? Russ --Apple-Mail=_F788A224-5C30-4CEC-94DA-71C9B5C90930 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

OLD:
In vehicular communications = using 802.11-OCB links, there are strong
privacy concerns = with respect to addressing. While the 802.11-OCB
standard = does not specify anything in particular with respect to MAC
addresses

It has been suggested that there = is something to think about here, which
may affect the above statement: = there is at least one country where the
vehicle|driver information, be = it physical or electronic, must be
allowed access by law = enforcement if so required.

This is noted.  I suggest we discuss this = separately.

At this time I do not modify = this text.

End = issue.

IEEE = 1609 does impose MAC address requirements.  Is this the right place = to call that out?

Russ

= --Apple-Mail=_F788A224-5C30-4CEC-94DA-71C9B5C90930-- From nobody Thu May 18 07:03:29 2017 Return-Path: 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 9A4BC129BB7 for ; Thu, 18 May 2017 07:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 NugkjaeRkkf3 for ; Thu, 18 May 2017 07:03:24 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id DD8CE129BAF for ; Thu, 18 May 2017 06:57:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,359,1491256800"; d="scan'208,217";a="6273233" Received: from monza.eurecom.fr ([192.168.106.15]) by drago2i.eurecom.fr with ESMTP; 18 May 2017 15:57:24 +0200 Received: from xerus29 (xerus29.eurecom.fr [172.17.31.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 8E96515FD; Thu, 18 May 2017 15:57:24 +0200 (CEST) From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= To: "'Russ Housley'" , "'Alexandre Petrescu'" Cc: References: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> In-Reply-To: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> Date: Thu, 18 May 2017 15:57:24 +0200 Organization: EURECOM Message-ID: <009601d2cfde$ad5abce0$081036a0$@eurecom.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01D2CFEF.70E38CE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLaRBK88xykj8VYhlOq8uhoK7bq9wHFxqHEn90FTvA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] MAC Address minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 14:03:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0097_01D2CFEF.70E38CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Russ, Dear Alex, =20 Indeed, and so does ETSI ITS. So, we can keep what is there, and maybe = add something like:=20 =20 (=85)While the 802.11-OCB standard does not specify anything particular = with respect to MAC addresses, higher layer stack architecture, such as IEEE = 1609 and ETSI ITS does impose MAC requirements. Accordingly, similar = requirements might be expected or required when operating IPv6 over 802.11-OCB = without these architectures (=85)=20 =20 Do we need to define what we mean by =91MAC requirements=92?=20 =20 Best Regards, =20 J=E9r=F4me =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley Sent: Thursday 18 May 2017 15:44 To: Alexandre Petrescu Cc: its@ietf.org Subject: [ipwave] MAC Address minor textual issue =20 =20 On May 18, 2017, at 5:39 AM, Alexandre Petrescu wrote: =20 OLD: In vehicular communications using 802.11-OCB links, there are strong privacy concerns with respect to addressing. While the 802.11-OCB standard does not specify anything in particular with respect to MAC addresses It has been suggested that there is something to think about here, which may affect the above statement: there is at least one country where the vehicle|driver information, be it physical or electronic, must be allowed access by law enforcement if so required. This is noted. I suggest we discuss this separately. At this time I do not modify this text. End issue. =20 IEEE 1609 does impose MAC address requirements. Is this the right place = to call that out? =20 Russ =20 ------=_NextPart_000_0097_01D2CFEF.70E38CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Russ, Dear Alex,

 

Indeed, and so does ETSI ITS. So, we can keep what is there, and = maybe add something like:

 

(…)While the = 802.11-OCB standard does not specify anything particular with respect to = MAC addresses, higher layer stack architecture, such as IEEE 1609 and = ETSI ITS does impose MAC requirements. Accordingly, similar requirements = might be expected or required when operating IPv6 over 802.11-OCB = without these architectures (…)

 = ;

Do we = need to=A0 define what we mean by ‘MAC requirements’? =

 = ;

Best = Regards,

 = ;

J=E9r=F4me=

 

 

 

From:= = its [mailto:its-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Thursday 18 May 2017 15:44
To: = Alexandre Petrescu
Cc: its@ietf.org
Subject: = [ipwave] MAC Address minor textual = issue

 

 

On May 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:

 

OLD:

In = vehicular communications using 802.11-OCB links, there are = strong
privacy concerns with respect to addressing. While the = 802.11-OCB
standard does not specify anything in particular with = respect to MAC
addresses


It = has been suggested that there is something to think about here, = which
may affect the above statement: there is at least one country = where the
vehicle|driver information, be it physical or electronic, = must be
allowed access by law enforcement if so required.

This = is noted.  I suggest we discuss this separately.

At this = time I do not modify this text.

End = issue.

 

IEEE = 1609 does impose MAC address requirements.  Is this the right place = to call that out?

 

Russ

 

------=_NextPart_000_0097_01D2CFEF.70E38CE0-- From nobody Thu May 18 07:52:57 2017 Return-Path: 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 0DF0612EB5F for ; Thu, 18 May 2017 07:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IwdXN4sqPeXW for ; Thu, 18 May 2017 07:52:54 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 43AC912EB28 for ; Thu, 18 May 2017 07:47:22 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id u75so37614636qka.3 for ; Thu, 18 May 2017 07:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=U4HIrnxQsg4FwC0Vzu0NQq1YkYrQTvzjVR7pAsgwuJk=; b=HercALtiUiuvWYZJVMTUW1eQ5TXTdsbvFeMywN3qIL//4kocTwBtP+wmKMNFsDBtfT TQGnSX3WnpglCV5hFcTVdHw+4zQwSNHla1SZ8TLIErETlp8hKB80BysOy709cZeB93hU lPd2ezAmFgJs1aikOpxPE4N+YWWfvvcM5ckjiwzqATMYaTl0nFN4BTZfJAhCIljxtRmj +YRtiWV4dymEdpV980K7/qwsZRV5ccs+un8hE1Daij7RCLFbbbRAT20b5e98RZ/d+57v 9IBvwXPEVmD4g2TFZFPlBQtQ3LIDm2O0K5oprNIQ4I0JRQkVFJkrM1GCaCbUvSe6MMiY K6mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=U4HIrnxQsg4FwC0Vzu0NQq1YkYrQTvzjVR7pAsgwuJk=; b=mNKbvMzN6Xil6B5m9pHP1bP7XUBRkx24sEZSang5a1rW9VSQkU2IMB2lPEoSUVFSfX f+KoYn6DcQNJ/AtmjKdKRA6SXMGuvTQaZNHUuvC3ZJu96kTAAMqcZIO/0e9UUigvop71 vZxYiCpTjtBRsuokk6O7SaZ2drAOM7ZYeUvk88kLXqOUk30f+o6aHq44yaOTAII0edWz 2TsLPn67uYXV9Me/rkwxOA0Poli45cbhRqtPyhLUaiYPkIPKi5RcsKgd7fPRnM/cncAi OlAG0vD7NpfRZvH+RuauPVNpKKXWgYipC6ufpZgstEYs3pBH/6stzZDnu355CZSHdRi5 7IMg== X-Gm-Message-State: AODbwcDRqVbmUibrdVo+Ad+30aSnHKe+QZja4kmro+06c7+ZDNPbt7uy XfE9ODshqMWQLw== X-Received: by 10.55.138.193 with SMTP id m184mr3917370qkd.192.1495118841496; Thu, 18 May 2017 07:47:21 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-247.washdc.fios.verizon.net. [108.48.182.247]) by smtp.gmail.com with ESMTPSA id 75sm1858061qkw.63.2017.05.18.07.47.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 07:47:20 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: "'Russ Housley'" , "'Alexandre Petrescu'" Cc: , References: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> In-Reply-To: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> Date: Thu, 18 May 2017 10:47:19 -0400 Message-ID: <008601d2cfe5$a6cc8f50$f465adf0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01D2CFC4.1FBD6050" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLaRBK88xykj8VYhlOq8uhoK7bq9wHFxqHEn90GxPA= Content-Language: en-us Archived-At: Subject: Re: [ipwave] MAC Address minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 14:52:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0087_01D2CFC4.1FBD6050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mr. Housley; =20 See comments in the text. =20 Fygs =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley Sent: Thursday, May 18, 2017 9:44 AM To: Alexandre Petrescu Cc: its@ietf.org Subject: [ipwave] MAC Address minor textual issue =20 =20 On May 18, 2017, at 5:39 AM, Alexandre Petrescu > = wrote: =20 OLD: In vehicular communications using 802.11-OCB links, there are strong privacy concerns with respect to addressing. While the 802.11-OCB standard does not specify anything in particular with respect to MAC addresses=20 [Fygs: if we are talking about privacy, I believed the statement is = correct. Other methods are used in IEEE 802.11 Security to support privacy. This function would not be expected to be in the MAC sub-layer].=20 It has been suggested that there is something to think about here, which may affect the above statement: there is at least one country where the vehicle|driver information, be it physical or electronic, must be allowed access by law enforcement if so required. [Fygs: This is correct. IEEE 1609 recognize this fact and such does not mandate the implementations to secure privacy =96 =93whatever privacy = services are provided, there may be a legal right for appropriately authorized parties to reverse that privacy for law enforcement or to ensure the = correct operation of the system. =91]. This is noted. I suggest we discuss this separately. At this time I do not modify this text. End issue. =20 IEEE 1609 does impose MAC address requirements. Is this the right place = to call that out?=20 [Fygs: I do not think there is an =93imposition=94 implied here. IEEE = 1609.0: IEEE 1609 standards provide primitives to change local WAVE MAC = addresses to protect the privacy of the device operator. The process by which a = decision is made to change the WAVE MAC address is not addressed in the IEEE 1609 standards. See 5.13.10 for further discussion.=94] =20 ------=_NextPart_000_0087_01D2CFC4.1FBD6050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mr. = Housley;

 

See comments in the text.

 

Fygs

 

From: its = [mailto:its-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Thursday, May 18, 2017 9:44 AM
To: = Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: = its@ietf.org
Subject: [ipwave] MAC Address minor textual = issue

 

 

On May 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:

 

OLD:

In = vehicular communications using 802.11-OCB links, there are = strong
privacy concerns with respect to addressing. While the = 802.11-OCB
standard does not specify anything in particular with = respect to MAC
addresses

[Fygs: if = we are talking about privacy, I believed the statement is correct.=A0 = Other methods are used in IEEE 802.11 Security to support privacy.=A0 = This function would not be expected to be in the MAC = sub-layer]. =


It has = been suggested that there is something to think about here, which
may = affect the above statement: there is at least one country where = the
vehicle|driver information, be it physical or electronic, must = be
allowed access by law enforcement if so = required.

[Fygs: This is correct.=A0 IEEE 1609 = recognize this fact and such does not mandate the implementations to = secure privacy – “whatever = privacy services are provided, there may be a legal right for = appropriately authorized parties to reverse that privacy for law = enforcement or to ensure the correct operation of the system. = ‘].



This= is noted.  I suggest we discuss this separately.

At this = time I do not modify this text.

End = issue.

 

IEEE 1609 does impose MAC address = requirements.  Is this the right place to call that out? =

[Fygs: I do not think there is an = “imposition” implied here.=A0 IEEE 1609.0: IEEE 1609 standards = provide primitives to change local WAVE MAC addresses to protect the = privacy of =A0the device operator. The process by which a decision is = made to change the WAVE MAC address is not addressed in the IEEE 1609 = standards. See 5.13.10 for further = discussion.”]

 

------=_NextPart_000_0087_01D2CFC4.1FBD6050-- From nobody Thu May 18 07:56:38 2017 Return-Path: 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 7D6C512700F for ; Thu, 18 May 2017 07:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.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 rleNfsKxrF50 for ; Thu, 18 May 2017 07:56:34 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 BF44212751F for ; Thu, 18 May 2017 07:50:52 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id z52so36888500wrc.2 for ; Thu, 18 May 2017 07:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zasJ888p0TOpmYR9coZFsz76nB3qdpqvUBIgLDSe4Zc=; b=ZbyHqu0JKRiiVuP0bvtV+gwiWBH4qYpgQ0IGfyaguULJV8TJs3GrMVlAaeTrHf3QBt cU+2VrsPh7TokmR/XCXXV2otFOarIPOhDEjWPmpOHufPbwHU50nqQS7ByPTwFjkm5w0s oJ5t4ioAShLROgZvwQq5wnUYNuDZQTUvtmNsIaMsnRkaHmAD8BotUVT6pjg/BTC6Adgn Q2hEl5eUImWWcB7fO7DsUWBm8+BXPrjgU/Vqxi3UvcKtcnzlwhQ2ZsDE6ClKIimEp3PO D/oenglXeMBk/DY4qitsgq6vKj6dw697G62rPuEWiJVwKEKDsLwPm0Dmap4So+BjgGpf EqYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zasJ888p0TOpmYR9coZFsz76nB3qdpqvUBIgLDSe4Zc=; b=ZPpVZJIhC9m5N3kIHTIfNUH0XNPmdTXR2nvExlQB6L0YL1e2r1WiU9hpBrGag3Katd KguszltoidVC8yXfd0xznal38WczaD0sfvLGZ8sBNaxp03Yt/BqQ0l6ivux9eUC0OOdn vPTKrHhd4eaxPlKbhyGiy/uXYMJ9goUR7DOqDJE6ISQBfJzt8nNidv1l89b8tnZ23J21 PR3R6jCUalgid/poSz2Vs7J3HWwHdcbZKuv7nMrnlo0xFHiu5hrTv/YtcI1LWyu/fHPF rQJg9x6C5qs3VfhsVlEibUMgG/dT9UL2oV+VBGQdvkU+c2EZhvaSNnFSsUtkC2ZZ00Gz 68tw== X-Gm-Message-State: AODbwcDFTvDxfv12Co+o0hV3eA2yOXj0ad9B9NxlODJRMWjspSoWjq8+ lAaKylLoCQe3pw9Wljkz5LZaDne7jhRF X-Received: by 10.223.163.21 with SMTP id c21mr3023961wrb.38.1495119051145; Thu, 18 May 2017 07:50:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.136 with HTTP; Thu, 18 May 2017 07:50:50 -0700 (PDT) In-Reply-To: <009601d2cfde$ad5abce0$081036a0$@eurecom.fr> References: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> <009601d2cfde$ad5abce0$081036a0$@eurecom.fr> From: John Kenney Date: Thu, 18 May 2017 07:50:50 -0700 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= Cc: Russ Housley , Alexandre Petrescu , "its@ietf.org" Content-Type: multipart/alternative; boundary="f403045f1a5cf0f105054fcd8734" Archived-At: Subject: Re: [ipwave] MAC Address minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 14:56:36 -0000 --f403045f1a5cf0f105054fcd8734 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello All: I do not agree with the statement that "there are strong privacy concerns". I suggest changing "concerns" to "requirements". I think stating that there are strong concerns conveys a sense of this being a big unsolved problem. For the DSRC/ITS-G5 community this is not the case. Privacy protection, including careful avoidance of PII in messages, pseudonymous certificates, and frequent identifier randomization, has been designed into DSRC/ITS-G5 from day 1. The requirements are cross-layer and systemic, but also not universal for OCB (e.g. RSUs are licensed for a site and do not need privacy protection), so 802.11 would not have been the best place to address them. Stating that they are not addressed in 802.11 sounds to me like it was an oversight or omission. It was not. I agree with noting that some standards already address privacy protection, but I don't think it helps to list standards (like 802.11) that do not. I hope these comments are helpful. Best Regards, John On Thu, May 18, 2017 at 6:57 AM, J=C3=A9r=C3=B4me H=C3=A4rri wrote: > Dear Russ, Dear Alex, > > > > Indeed, and so does ETSI ITS. So, we can keep what is there, and maybe ad= d > something like: > > > > (=E2=80=A6)While the 802.11-OCB standard does not specify anything partic= ular > with respect to MAC addresses, higher layer stack architecture, such as > IEEE 1609 and ETSI ITS does impose MAC requirements. Accordingly, similar > requirements might be expected or required when operating IPv6 over > 802.11-OCB without these architectures (=E2=80=A6) > > > > Do we need to define what we mean by =E2=80=98MAC requirements=E2=80=99? > > > > Best Regards, > > > > J=C3=A9r=C3=B4me > > > > > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Russ Housley > *Sent:* Thursday 18 May 2017 15:44 > *To:* Alexandre Petrescu > *Cc:* its@ietf.org > *Subject:* [ipwave] MAC Address minor textual issue > > > > > > On May 18, 2017, at 5:39 AM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > > > OLD: > > In vehicular communications using 802.11-OCB links, there are strong > privacy concerns with respect to addressing. While the 802.11-OCB > standard does not specify anything in particular with respect to MAC > addresses > > > It has been suggested that there is something to think about here, which > may affect the above statement: there is at least one country where the > vehicle|driver information, be it physical or electronic, must be > allowed access by law enforcement if so required. > > This is noted. I suggest we discuss this separately. > > At this time I do not modify this text. > > End issue. > > > > IEEE 1609 does impose MAC address requirements. Is this the right place > to call that out? > > > > Russ > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --f403045f1a5cf0f105054fcd8734 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All:

I do not agree with the stat= ement that "there are strong privacy concerns". I suggest changin= g "concerns" to "requirements".

I think stating that there are strong concerns conveys a sense of this be= ing a big unsolved problem. For the DSRC/ITS-G5 community this is not the c= ase. Privacy protection, including careful avoidance of PII in messages, ps= eudonymous certificates, and frequent identifier randomization, has been de= signed into DSRC/ITS-G5 from day 1. =C2=A0

The= requirements are cross-layer and systemic, but also not universal for OCB = (e.g. RSUs are licensed for a site and do not need privacy protection), so = 802.11 would not have been the best place to address them. Stating that the= y are not addressed in 802.11 sounds to me like it was an oversight or omis= sion. It was not.

I agree with noting that some st= andards already address privacy protection, but I don't think it helps = to list standards (like 802.11) that do not.

I= hope these comments are helpful.

Best Regards,
John





On Thu, = May 18, 2017 at 6:57 AM, J=C3=A9r=C3=B4me H=C3=A4rri <= jerome.haerri= @eurecom.fr> wrote:

Dear R= uss, Dear Alex,

=C2=A0

Indeed, and so does ETSI ITS. So, we can keep what is= there, and maybe add something like:

=C2=A0

(=E2=80=A6)While the 802.11-OCB standard does not specify anything particular with = respect to MAC addresses, higher layer stack architecture, such as IEEE 160= 9 and ETSI ITS does impose MAC requirements. Accordingly, similar requireme= nts might be expected or required when operating IPv6 over 802.11-OCB witho= ut these architectures (=E2=80=A6)

=C2=A0

Do we need to=C2=A0 define what we mean by =E2=80=98MAC requ= irements=E2=80=99?

=C2=A0

B= est Regards,

<= u>=C2=A0

J=C3=A9r= =C3=B4me

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On May 18, 2017, at 5:39 = AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:=

=C2=A0

OLD:

In vehicular communications using 802.11-OCB links, there = are strong
privacy concerns with respect to addressing. While the 802.11= -OCB
standard does not specify anything in particular with respect to MA= C
addresses


It has been suggested that there is something to think about here, w= hich
may affect the above statement: there is at least one country where= the
vehicle|driver information, be it physical or electronic, must beallowed access by law enforcement if so required.

This is noted.= =C2=A0 I suggest we discuss this separately.

At this time I do not m= odify this text.

End issue.

=C2=A0

IEEE 1609 does impose MAC address requirements.=C2=A0 Is this the = right place to call that out?

=C2=A0

Russ=

=C2=A0

=

__________________________________________= _____
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its




--
=
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--f403045f1a5cf0f105054fcd8734-- From nobody Thu May 18 08:09:49 2017 Return-Path: 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 EF86212EB3B for ; Thu, 18 May 2017 08:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 MoC0lYlZiE5t for ; Thu, 18 May 2017 08:09:46 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 DB8DC1293D9 for ; Thu, 18 May 2017 08:03:09 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with SMTP id BMx0dnWqal4eqBMxJdOF89; Thu, 18 May 2017 15:03:09 +0000 Received: from [10.120.1.165] ([12.1.72.210]) by resomta-ch2-05v.sys.comcast.net with SMTP id BMv5du1YxxrGZBMv8dIOnW; Thu, 18 May 2017 15:01:07 +0000 From: Tony Li Message-Id: <846437B4-BE7D-4DF2-9C37-26D60180E82B@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_271A47C5-DE3B-44C8-A288-9731088ABB07" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 18 May 2017 08:00:52 -0700 In-Reply-To: Cc: =?utf-8?B?SsOpcsO0bWUgSMOkcnJp?= , Alexandre Petrescu , Russ Housley , "its@ietf.org" To: John Kenney References: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> <009601d2cfde$ad5abce0$081036a0$@eurecom.fr> X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfOe66wYgv2kCJqwKOzPzZKfPa5HT04FpdJXhicD87O0TloFcc3B89sUO+f4wRoT66bNGZGjyQtYMFazGppqNRu3N4H/wJg6Br03CvLV2S27xNUkbmmeR /vOGJcLU+7y8txlWImfXOizxstuAytNnHjKTzLQDmZ/8Iz342b1lP+EFF6T7sq5ZIRCXXCNJg9FyzmSgGJDQGO3EfYK9VVB+95MQ1TJi2FcEf4Tw6RF59Dgp Cs6afUYgOd9Pmk0A3+4zrdoahxbo1zbZ2IxWHISXRGtCqfajO3Un6I9wBVQebTbE Archived-At: Subject: Re: [ipwave] MAC Address minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:09:48 -0000 --Apple-Mail=_271A47C5-DE3B-44C8-A288-9731088ABB07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 18, 2017, at 7:50 AM, John Kenney = wrote: >=20 > I do not agree with the statement that "there are strong privacy = concerns". I suggest changing "concerns" to "requirements". >=20 > I think stating that there are strong concerns conveys a sense of this = being a big unsolved problem. For the DSRC/ITS-G5 community this is not = the case. Privacy protection, including careful avoidance of PII in = messages, pseudonymous certificates, and frequent identifier = randomization, has been designed into DSRC/ITS-G5 from day 1. =20 Well, I for one am still mystified by how the solution maps to IP. DSRC = can do all of this work, but if my IP addressing doesn=E2=80=99t change = in synchrony, it seems like it all doesn=E2=80=99t help. And if the IP = addresses do change in synchrony, you abort upper layer TCP connections. So I=E2=80=99m still concerned. Tony --Apple-Mail=_271A47C5-DE3B-44C8-A288-9731088ABB07 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 18, 2017, at 7:50 AM, John Kenney <jkenney@us.toyota-itc.com> wrote:

I = do not agree with the statement that "there are strong privacy = concerns". I suggest changing "concerns" to "requirements".
I think stating that there = are strong concerns conveys a sense of this being a big unsolved = problem. For the DSRC/ITS-G5 community this is not the case. Privacy = protection, including careful avoidance of PII in messages, pseudonymous = certificates, and frequent identifier randomization, has been designed = into DSRC/ITS-G5 from day 1.  

Well, I for one am still mystified by how the = solution maps to IP.  DSRC can do all of this work, but if my IP = addressing doesn=E2=80=99t change in synchrony, it seems like it all = doesn=E2=80=99t help. And if the IP addresses do change in synchrony, = you abort upper layer TCP connections.

So I=E2=80=99m still = concerned.

Tony

= --Apple-Mail=_271A47C5-DE3B-44C8-A288-9731088ABB07-- From nobody Thu May 18 08:11:56 2017 Return-Path: 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 C4A98129AA0 for ; Thu, 18 May 2017 08:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 5mUcippkokQi for ; Thu, 18 May 2017 08:11:52 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 26F0D129BF5 for ; Thu, 18 May 2017 08:05:24 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id r58so6063285qtb.2 for ; Thu, 18 May 2017 08:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=6eL4AgTZCJiFkuKOTX9Cmgd4SSr+K0UJ1TSdg7+s5vI=; b=Y30ylR1D9MpI4XWwpJYi8dz9CMicaorBdiVWQY0ak4chEgx9r4900c0as6Wg9dl51z KUOStntTTzEvALrTmfukvc8qRvHfsF3/96CafrnyAdJ9c69i0HMTchR0xDSs0Diw9fug IXPOrOiCk8gad1271ywylnUOr5PIdjkIQfB/+JZwP7VU6USZuYWdOH+t1SyR1FvGZaQo Y8lHizztt2VT1NvV3oaA4hHjr+VE45IX3y6IwZOVZddcmQ8px9a+LaQQjjCofEWLyqKE Nb+rzwIBkxEt5YTor7r2zmRL2+R4cCrRqVWv+BhXHg1OVHZu5z9mzYVggEKWka6+RRiL Ovew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=6eL4AgTZCJiFkuKOTX9Cmgd4SSr+K0UJ1TSdg7+s5vI=; b=lqQtjv2g5E63amDBvC064uXyGJiCwXO6SbYCH9ywrnn3Gm4AtmKkIHWxLs3dP+ATNz WS+zWRc30Bj+s18La7QtisW434qxlB2pDI4mS0t8BbXi0zILoiJBDq+BsX/rJLkNoWMm 4WS23xVWTxWN+yQpNRnWBWkSRvurmwwk+2I2AGf2py8Ljp/ITIaHmrml2Y0Iqf8xqjj0 Ij4sifIiMA9/lfcTUaVqJqfBLzE5VBM5/4ddDH1OUOIaBxAZrkbURSAg6gfSp0qDR5MF +E+C6EmsfhegW4c3kaMcc+wprT11vhqn6zuDG3FbdLQwLREd7Cp+Zsser1Z2QpzRltXO JXkQ== X-Gm-Message-State: AODbwcDo49JmwCsAUi/gNdcGieoyrcO3YwDVurF3AJ1AYEJQXRJ3G/s5 f29xmxG/B9TxXA== X-Received: by 10.200.40.178 with SMTP id i47mr4597081qti.59.1495119923329; Thu, 18 May 2017 08:05:23 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-247.washdc.fios.verizon.net. [108.48.182.247]) by smtp.gmail.com with ESMTPSA id c202sm2834881qke.65.2017.05.18.08.05.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 08:05:22 -0700 (PDT) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: "'John Kenney'" , =?UTF-8?B?J0rDqXLDtG1lIEjDpHJyaSc=?= Cc: "'Alexandre Petrescu'" , "'Russ Housley'" , , References: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> <009601d2cfde$ad5abce0$081036a0$@eurecom.fr> In-Reply-To: Date: Thu, 18 May 2017 11:05:21 -0400 Message-ID: <00a301d2cfe8$2b95de10$82c19a30$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A4_01D2CFC6.A488F900" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLaRBK88xykj8VYhlOq8uhoK7bq9wHFxqHEAmd6r9ABFBL2jJ/BPGbg Content-Language: en-us Archived-At: Subject: Re: [ipwave] MAC Address minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:11:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A4_01D2CFC6.A488F900 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gentlemen; =20 Regardless if we are talking about MAC address changes or any other = methods related to privacy, this would not be a data-plane MAC sub-layer = function. =20 Fygs =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of John Kenney Sent: Thursday, May 18, 2017 10:51 AM To: J=C3=A9r=C3=B4me H=C3=A4rri Cc: Alexandre Petrescu ; Russ Housley = ; its@ietf.org Subject: Re: [ipwave] MAC Address minor textual issue =20 Hello All: =20 I do not agree with the statement that "there are strong privacy = concerns". I suggest changing "concerns" to "requirements". =20 I think stating that there are strong concerns conveys a sense of this = being a big unsolved problem. For the DSRC/ITS-G5 community this is not = the case. Privacy protection, including careful avoidance of PII in = messages, pseudonymous certificates, and frequent identifier = randomization, has been designed into DSRC/ITS-G5 from day 1. =20 =20 The requirements are cross-layer and systemic, but also not universal = for OCB (e.g. RSUs are licensed for a site and do not need privacy = protection), so 802.11 would not have been the best place to address = them. Stating that they are not addressed in 802.11 sounds to me like it = was an oversight or omission. It was not. =20 I agree with noting that some standards already address privacy = protection, but I don't think it helps to list standards (like 802.11) = that do not. =20 I hope these comments are helpful. =20 Best Regards, John =20 =20 =20 =20 =20 On Thu, May 18, 2017 at 6:57 AM, J=C3=A9r=C3=B4me H=C3=A4rri = > wrote: Dear Russ, Dear Alex, =20 Indeed, and so does ETSI ITS. So, we can keep what is there, and maybe = add something like:=20 =20 (=E2=80=A6)While the 802.11-OCB standard does not specify anything = particular with respect to MAC addresses, higher layer stack = architecture, such as IEEE 1609 and ETSI ITS does impose MAC = requirements. Accordingly, similar requirements might be expected or = required when operating IPv6 over 802.11-OCB without these architectures = (=E2=80=A6)=20 =20 Do we need to define what we mean by =E2=80=98MAC = requirements=E2=80=99?=20 =20 Best Regards, =20 J=C3=A9r=C3=B4me =20 =20 =20 From: its [mailto:its-bounces@ietf.org ] = On Behalf Of Russ Housley Sent: Thursday 18 May 2017 15:44 To: Alexandre Petrescu Cc: its@ietf.org =20 Subject: [ipwave] MAC Address minor textual issue =20 =20 On May 18, 2017, at 5:39 AM, Alexandre Petrescu = > = wrote: =20 OLD: In vehicular communications using 802.11-OCB links, there are strong privacy concerns with respect to addressing. While the 802.11-OCB standard does not specify anything in particular with respect to MAC addresses It has been suggested that there is something to think about here, which may affect the above statement: there is at least one country where the vehicle|driver information, be it physical or electronic, must be allowed access by law enforcement if so required. This is noted. I suggest we discuss this separately. At this time I do not modify this text. End issue. =20 IEEE 1609 does impose MAC address requirements. Is this the right place = to call that out? =20 Russ =20 _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its =20 --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 ------=_NextPart_000_00A4_01D2CFC6.A488F900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Gentlemen;

 

Regardless = if we are talking about MAC address changes or any other methods related = to privacy, this would not be a data-plane MAC sub-layer = function.

 

Fygs

 

 

From: = its [mailto:its-bounces@ietf.org] On Behalf Of John = Kenney
Sent: Thursday, May 18, 2017 10:51 AM
To: = J=C3=A9r=C3=B4me H=C3=A4rri = <jerome.haerri@eurecom.fr>
Cc: Alexandre Petrescu = <alexandre.petrescu@gmail.com>; Russ Housley = <housley@vigilsec.com>; its@ietf.org
Subject: Re: = [ipwave] MAC Address minor textual issue

 

Hello = All:

 

I = do not agree with the statement that "there are strong privacy = concerns". I suggest changing "concerns" to = "requirements".

 

I = think stating that there are strong concerns conveys a sense of this = being a big unsolved problem. For the DSRC/ITS-G5 community this is not = the case. Privacy protection, including careful avoidance of PII in = messages, pseudonymous certificates, and frequent identifier = randomization, has been designed into DSRC/ITS-G5 from day 1. =  

 

The requirements are cross-layer and systemic, but = also not universal for OCB (e.g. RSUs are licensed for a site and do not = need privacy protection), so 802.11 would not have been the best place = to address them. Stating that they are not addressed in 802.11 sounds to = me like it was an oversight or omission. It was = not.

 

I = agree with noting that some standards already address privacy = protection, but I don't think it helps to list standards (like 802.11) = that do not.

 

I = hope these comments are helpful.

 

Best Regards,

John

 

 

 

 

 

On Thu, = May 18, 2017 at 6:57 AM, J=C3=A9r=C3=B4me H=C3=A4rri <jerome.haerri@eurecom.fr> = wrote:

Dear Russ, Dear Alex,

 

Indeed, and so does ETSI ITS. So, we can keep = what is there, and maybe add something like:

 

(=E2=80=A6)While the = 802.11-OCB standard does not specify anything particular with respect to = MAC addresses, higher layer stack architecture, such as IEEE 1609 and = ETSI ITS does impose MAC requirements. Accordingly, similar requirements = might be expected or required when operating IPv6 over 802.11-OCB = without these architectures (=E2=80=A6)

 

Do we need = to  define what we mean by =E2=80=98MAC requirements=E2=80=99? =

 

Best = Regards,

 

J=C3=A9r=C3=B4= me

 

 

 

From: its = [mailto:its-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Thursday 18 May 2017 15:44
To: = Alexandre Petrescu
Cc: its@ietf.org
Subject: [ipwave] MAC = Address minor textual = issue

 <= /o:p>

 <= /o:p>

On May 18, = 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> = wrote:

 <= /o:p>

OLD:<= o:p>

In = vehicular communications using 802.11-OCB links, there are = strong
privacy concerns with respect to addressing. While the = 802.11-OCB
standard does not specify anything in particular with = respect to MAC
addresses


It has = been suggested that there is something to think about here, which
may = affect the above statement: there is at least one country where = the
vehicle|driver information, be it physical or electronic, must = be
allowed access by law enforcement if so required.

This is = noted.  I suggest we discuss this separately.

At this time I = do not modify this text.

End = issue.

 <= /o:p>

IEEE 1609 = does impose MAC address requirements.  Is this the right place to = call that out?

 <= /o:p>

Russ

 <= /o:p>


______________________________________= _________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its



 

-- =

John = Kenney

Director and = Principal Researcher

Toyota InfoTechnology Center, = USA

465 Bernardo = Avenue

Mountain View, CA = 94043

Tel: 650-694-4160. = Mobile: = 650-224-6644

------=_NextPart_000_00A4_01D2CFC6.A488F900-- From nobody Thu May 18 08:15:25 2017 Return-Path: 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 0E5D6128BC8 for ; Thu, 18 May 2017 08:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.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 B8cwrtVkpfLJ for ; Thu, 18 May 2017 08:15:21 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 E2D58126C26 for ; Thu, 18 May 2017 08:09:21 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id d127so55741728wmf.0 for ; Thu, 18 May 2017 08:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kiRKW7IwMoWjfotFciKpMJWlXZv5E/NQ+0djfG7QTW4=; b=KeXeTaQtZ/bg6MNLczMROyGpYj8MjijELP6z8UiOsmGaW6BnPozIh9z/RkIYTsztPP NVX5OlaijeITSf0V97V1MLpdK9uEnxXcDCEhjUkNz6nYLqpcKbEmqdVmXpZZEMn+Cv3M wZ6row1OQFmVKU97LWxIzBuuQYGHB7MH4YkBjk+efwzk7UixOh6EhsDUcZN71F9k/z7A f/pqgn2KYGHawyygNKwrW3/VJr7XNlRYBJEGJ9qJPEmp4Lsyxyn+RV7aqdZD/wvK96k/ Vphrj755Qc2hb3cxsVTGFbrV2XqS+OB84g1ZlFAIn6x5cEa5OsGwAX/CTLEk9/aWiMAO fQLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kiRKW7IwMoWjfotFciKpMJWlXZv5E/NQ+0djfG7QTW4=; b=P0MdQKDPlwgl9RlFKWpg5UBOA/mF9TTqg1IV3ssM1i7f6FZrUjVTgyhWGAQq/0d6Ht Ekg25nZWhPZCUOI54qneMDuROwWnxQFjefw8DncOb4C25whkw+4Qk9d3MpKKIZTVWEKz 5pCXc8kLg2diaj6nvybrsqBddM4LVH+hxbYacrrM0Ereltzo4Q0pt94HTh1Z3KCbBgHI 3K8Zhw2h5HVs/+/Lf2hisgvTL/WfDksmakWb3jE8gw6zsIJCWIsIAt4Rjnc2vUnNPpNk A5qCtGPFEsS3kXmtiImgGt9dSxm4wC4dSMVA4IyxCvcqD2uAJdIP4qmHirfATP4xmj3E 1Mvg== X-Gm-Message-State: AODbwcBUk75iammc1+tqRsQ5mp295moH9EG4kHEd5wMuTqNPhdbvIl0a KNUm5DGy/4p+l9D7ppvSSsFjpW6dQran X-Received: by 10.28.56.198 with SMTP id f189mr3138078wma.111.1495120160344; Thu, 18 May 2017 08:09:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.136 with HTTP; Thu, 18 May 2017 08:09:19 -0700 (PDT) In-Reply-To: References: From: John Kenney Date: Thu, 18 May 2017 08:09:19 -0700 Message-ID: To: Russ Housley Cc: Alexandre Petrescu , "its@ietf.org" Content-Type: multipart/alternative; boundary="001a114cbf0a0dea87054fcdcaca" Archived-At: Subject: Re: [ipwave] 802.11p minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:15:23 -0000 --001a114cbf0a0dea87054fcdcaca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI, when the IEEE 1609 WG recently prepared a document that cited our standards, we were told by IEEE to do it this way: The NPRM references IEEE standards that have been superseded by these more recently published IEEE standards: IEEE Std 802.11TM-2016, IEEE Std 1609.2 TM -2016, IEEE Std 1609.3 TM -2016, IEEE Std 1609.4 TM -2016, and IEEE Std 1609.12 TM -2016 Here is a quote from the IEEE-SA Standards Style Manual (section 7): "IEEE designations are trademarks of the IEEE and shall be identified as trademarks (=C2=AE or =E2=84=A2, as appropriate) at first citation of each = designation in the frontmatter and in the body of the draft." So, if the text quoted by Alex is the first citation in the ID, I believe it would be correct to include TM not only for the 11p amendment, but also for 802.11-2007 since it is a different publication. Best Regards, John On Thu, May 18, 2017 at 6:38 AM, Russ Housley wrote: > > On May 18, 2017, at 5:39 AM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > OLD: > > The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010 > [ieee802.11p-2010] as an amendment to the 802.11 specifications > > > It was suggested that the "802.11 specifications" are in fact "IEEE Std > 802.11-2007". As such the resolution is: > > NEW: > > The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010 > [ieee802.11p-2010] as an amendment to IEEE Std 802.11-2007 > > > End issue. > > > Alex: > > I do not believe that the "(TM)" should appear in the name. I suggest > IEEE Std 802.11p-2010. > > Also, it might help people locate the specification if we tell people tha= t > OCB was first specified in IEEE Std 802.11p-2010 as an amendment to IEEE > Std 802.11-2007, and then it was incorporated into the base standard in = =E2=80=A6 > > Russ > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --001a114cbf0a0dea87054fcdcaca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, when the IEEE 1609 WG recently prepared a document th= at cited our standards, we were told by IEEE to do it this way:

The NPRM references IEEE standards that have been superseded by these more rece= ntly published IEEE standards:=C2=A0IEEE Std 802.11TM-2016, IEEE Std 1609.2 TM -2016= , IEEE Std 1609.3 TM<= /font> -2016, IEEE Std 1609.4 TM -2016, and IEEE Std 1609.12 TM= -2016

Here is a= quote from the IEEE-SA Standards Style Manual (sec= tion 7):
"= IEEE designations are trademarks of the IEEE and shall be identified as tra= demarks (=C2=AE or =E2=84=A2, as appropriate) at first citation of each designation in the frontmatter and i= n the body of the draft."

So, = if the text quoted by Alex is the first citation in the ID, I believe it wo= uld be correct to include TM not only for the 11p amendment, but also for 8= 02.11-2007 since it is a different publication.

Best Regards,
John



On Thu, May 18, 2017 at 6:38 AM, Russ Housley = <housley@vigil= sec.com> wrote:

On May 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmai= l.com> wrote:

OLD:
The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010
[ie= ee802.11p-2010] as an amendment to the 802.11 specifications

It was suggested that the "802.11 specific= ations" are in fact "IEEE Std
802= .11-2007".=C2=A0 As such the resolution is:

NEW:
The link 802.11 OCB was specified in IE= EE Std 802.11p(TM)-2010
[ieee802.11p-2010] as an amendment to IEEE Std 8= 02.11-2007

End issue.

Alex:

I do not believ= e that the "(TM)" should appear in the name.=C2=A0 I suggest IEEE= Std 802.11p-2010.

Also, it might help people loca= te the specification if we tell people that OCB was first specified in IEEE= Std 802.11p-2010 as an amendment to IEEE Std 802.11-2007, and then it was = incorporated into the base standard in =E2=80=A6

Russ


____________________________________________= ___
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its




--
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--001a114cbf0a0dea87054fcdcaca-- From nobody Thu May 18 08:19:58 2017 Return-Path: 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 D98DD126CBF for ; Thu, 18 May 2017 08:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] 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 06GXJsllv7kU for ; Thu, 18 May 2017 08:19:52 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B47129C3E for ; Thu, 18 May 2017 08:14:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6EE45300537 for ; Thu, 18 May 2017 11:13:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 73OFnldHP32j for ; Thu, 18 May 2017 11:13:57 -0400 (EDT) Received: from [5.5.33.143] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id DC758300265; Thu, 18 May 2017 11:13:56 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EF68C48B-9884-4C01-96CA-5FB55BB07D7C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 18 May 2017 11:13:58 -0400 In-Reply-To: Cc: "its@ietf.org" To: John Kenney References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] 802.11p minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:19:55 -0000 --Apple-Mail=_EF68C48B-9884-4C01-96CA-5FB55BB07D7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks. For providing this quote. I think it makes searching difficult = for the reader, but we should follow IEEE-SA guidelines. Russ > On May 18, 2017, at 11:09 AM, John Kenney = wrote: >=20 > FYI, when the IEEE 1609 WG recently prepared a document that cited our = standards, we were told by IEEE to do it this way: >=20 > The NPRM references IEEE standards that have been superseded by these = more recently published IEEE standards: IEEE Std 802.11TM-2016, IEEE Std = 1609.2 TM -2016, IEEE Std 1609.3 TM -2016, IEEE Std 1609.4 TM -2016, and = IEEE Std 1609.12 TM -2016 >=20 > Here is a quote from the IEEE-SA Standards Style Manual = (section 7): > "IEEE designations are trademarks of the IEEE and shall be identified = as trademarks (=C2=AE or =E2=84=A2, as appropriate) at first citation of = each designation in the frontmatter and in the body of the draft." >=20 > So, if the text quoted by Alex is the first citation in the ID, I = believe it would be correct to include TM not only for the 11p = amendment, but also for 802.11-2007 since it is a different publication. >=20 > Best Regards, > John >=20 >=20 >=20 > On Thu, May 18, 2017 at 6:38 AM, Russ Housley > wrote: >=20 >> On May 18, 2017, at 5:39 AM, Alexandre Petrescu = > = wrote: >>=20 >> OLD: >>> The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010 >>> [ieee802.11p-2010] as an amendment to the 802.11 specifications >>=20 >> It was suggested that the "802.11 specifications" are in fact "IEEE = Std >> 802.11-2007". As such the resolution is: >>=20 >> NEW: >>> The link 802.11 OCB was specified in IEEE Std 802.11p(TM)-2010 >>> [ieee802.11p-2010] as an amendment to IEEE Std 802.11-2007 >>=20 >> End issue. >=20 > Alex: >=20 > I do not believe that the "(TM)" should appear in the name. I suggest = IEEE Std 802.11p-2010. >=20 > Also, it might help people locate the specification if we tell people = that OCB was first specified in IEEE Std 802.11p-2010 as an amendment to = IEEE Std 802.11-2007, and then it was incorporated into the base = standard in =E2=80=A6 >=20 > Russ >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its = >=20 >=20 >=20 >=20 > --=20 > John Kenney > Director and Principal Researcher > Toyota InfoTechnology Center, USA > 465 Bernardo Avenue > Mountain View, CA 94043 > Tel: 650-694-4160. Mobile: 650-224-6644 --Apple-Mail=_EF68C48B-9884-4C01-96CA-5FB55BB07D7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks.  For providing this quote.  I think it = makes searching difficult for the reader, but we should follow IEEE-SA = guidelines.

Russ


On May 18, 2017, at 11:09 AM, John Kenney <jkenney@us.toyota-itc.com> wrote:

FYI, when the IEEE 1609 WG recently prepared a document that = cited our standards, we were told by IEEE to do it this way:

The NPRM references IEEE standards that have been superseded by these more = recently published IEEE standards: IEEE Std 802.11TM-2016,= IEEE Std 1609.2 = TM -2016, IEEE Std 1609.3 TM -2016, IEEE Std 1609.4 TM -2016, and IEEE Std 1609.12 TM = -2016

Here is a quote from the IEEE-SA = Standards Style Manual (section = 7):
"IEEE designations are trademarks of the IEEE and = shall be identified as trademarks (=C2=AE or =E2=84=A2, as appropriate) at first citation of each designation in the frontmatter = and in the body of the draft."

So, if the text quoted by Alex is the first = citation in the ID, I believe it would be correct to include TM not only = for the 11p amendment, but also for 802.11-2007 since it is a different = publication.

Best Regards,
John



On = Thu, May 18, 2017 at 6:38 AM, Russ Housley <housley@vigilsec.com> wrote:

On May = 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

OLD:
The link 802.11 OCB was specified in IEEE Std = 802.11p(TM)-2010
[ieee802.11p-2010] as an amendment to the = 802.11 specifications

It was suggested that the "802.11 = specifications" are in fact "IEEE Std
802.11-2007".  As such the = resolution is:

NEW:
The link 802.11 OCB was specified in IEEE Std = 802.11p(TM)-2010
[ieee802.11p-2010] as an amendment to = IEEE Std 802.11-2007

End = issue.

Alex:

I do not believe that the "(TM)" should appear in the = name.  I suggest IEEE Std 802.11p-2010.

Also, it might help people locate the = specification if we tell people that OCB was first specified in IEEE Std = 802.11p-2010 as an amendment to IEEE Std 802.11-2007, and then it was = incorporated into the base standard in =E2=80=A6

Russ


_______________________________________________
its mailing list
its@ietf.org
= https://www.ietf.org/mailman/listinfo/its




--
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: = 650-224-6644

= --Apple-Mail=_EF68C48B-9884-4C01-96CA-5FB55BB07D7C-- From nobody Thu May 18 08:27:51 2017 Return-Path: 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 3969C1294A4 for ; Thu, 18 May 2017 08:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 cXpapbILL8sL for ; Thu, 18 May 2017 08:27:49 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E02712EA97 for ; Thu, 18 May 2017 08:22:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 89CAD300538 for ; Thu, 18 May 2017 11:22:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6nFD0AtOYrzW for ; Thu, 18 May 2017 11:22:22 -0400 (EDT) Received: from [5.5.33.143] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id C2F1B300265; Thu, 18 May 2017 11:22:21 -0400 (EDT) From: Russ Housley Message-Id: <81C61671-C468-4841-B097-15C6328F4A2C@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_23123A59-E758-4510-A6DB-EF627D67D361" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 18 May 2017 11:22:23 -0400 In-Reply-To: <846437B4-BE7D-4DF2-9C37-26D60180E82B@tony.li> Cc: "its@ietf.org" To: Tony Li , Alexandre Petrescu References: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> <009601d2cfde$ad5abce0$081036a0$@eurecom.fr> <846437B4-BE7D-4DF2-9C37-26D60180E82B@tony.li> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [ipwave] MAC Address minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:27:50 -0000 --Apple-Mail=_23123A59-E758-4510-A6DB-EF627D67D361 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> I do not agree with the statement that "there are strong privacy = concerns". I suggest changing "concerns" to "requirements". >>=20 >> I think stating that there are strong concerns conveys a sense of = this being a big unsolved problem. For the DSRC/ITS-G5 community this is = not the case. Privacy protection, including careful avoidance of PII in = messages, pseudonymous certificates, and frequent identifier = randomization, has been designed into DSRC/ITS-G5 from day 1. =20 >=20 > Well, I for one am still mystified by how the solution maps to IP. = DSRC can do all of this work, but if my IP addressing doesn=E2=80=99t = change in synchrony, it seems like it all doesn=E2=80=99t help. And if = the IP addresses do change in synchrony, you abort upper layer TCP = connections. >=20 > So I=E2=80=99m still concerned. I agree that the IPv6 address needs to change whenever the MAC address = changes. This is not a problem for UDP traffic, but it can be a problem = for TCP. In my view, there is no privacy benefit to changing the = MAC/IPv6 address while the vehicle is stationary, like in a garage = overnight. In fact, this is the time when long-lived TCP connections = are extremely likely for actives like software update. Is this a place = we can add value with crisp recommendations? Russ --Apple-Mail=_23123A59-E758-4510-A6DB-EF627D67D361 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I = do not agree with the statement that "there are strong privacy = concerns". I suggest changing "concerns" to "requirements".
I think stating that there = are strong concerns conveys a sense of this being a big unsolved = problem. For the DSRC/ITS-G5 community this is not the case. Privacy = protection, including careful avoidance of PII in messages, pseudonymous = certificates, and frequent identifier randomization, has been designed = into DSRC/ITS-G5 from day 1.  

Well, I for one am still mystified by how the = solution maps to IP.  DSRC can do all of this work, but if my IP = addressing doesn=E2=80=99t change in synchrony, it seems like it all = doesn=E2=80=99t help. And if the IP addresses do change in synchrony, = you abort upper layer TCP connections.

So I=E2=80=99m still = concerned.

I = agree that the IPv6 address needs to change whenever the MAC address = changes.  This is not a problem for UDP traffic, but it can be a = problem for TCP.  In my view, there is no privacy benefit to = changing the MAC/IPv6 address while the vehicle is stationary, like in a = garage overnight.  In fact, this is the time when long-lived TCP = connections are extremely likely for actives like software update. =  Is this a place we can add value with crisp = recommendations?

Russ




= --Apple-Mail=_23123A59-E758-4510-A6DB-EF627D67D361-- From nobody Thu May 18 08:41:52 2017 Return-Path: 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 207D0129C13 for ; Thu, 18 May 2017 08:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=us-toyota-itc-com.20150623.gappssmtp.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 rWTBZ31pnbF8 for ; Thu, 18 May 2017 08:41:49 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 D438F129C1D for ; Thu, 18 May 2017 08:36:23 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id l50so38233114wrc.3 for ; Thu, 18 May 2017 08:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us-toyota-itc-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KqzAJUtND5/27arkRqXsNUJQyDdQQxIQQnaC98+pDV4=; b=eUr3zFvMtTI0Uaz0u8FHVd6rGXZyXGQhFMvRSvslnIZ/fF7DD4eXdcQ7x+5IrriqcQ 71WR3p/t5gb8AfH9K+gHcgm4fwBGUTYvuPKPccfc/iKPtK0ycu5q8/ebaoZ26KSAbyFT T9jc5i4b7HZKmxEl8rymVvrEdWuMJ2AHYEnIdcx5xVLaktGq6kdWcz7zRAg5GJ7M2GvK EMj/Nkrk3Ozzt3CKfXugMUF8pTmtuqgZFKshrpcOJAue4wh2TDQ+lyBAXZ13frviamEC QVlQD8tsSWYCGWWhTRC1DwFZzkBrljc0lj5EL0Naabd3xkcgvsrKvXY6ECBbk/P2KaI/ BJ4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KqzAJUtND5/27arkRqXsNUJQyDdQQxIQQnaC98+pDV4=; b=HDONcKVGi43aZw78HfjlEILYLM6wEdUwBB53FcUGb01dTv05c6xyy2+P+Mc5QayvPT V0fxPfd+dWfxIWosiBrguOKCFKyDhZedUcMWsyYer0bKntTK1GJ0mBfbYMgD14QIOW/1 YyQoPsrsqdBDDa1KA2sd78ZbQSZcDYJNjHMYazNpqRsvzFs+rw+ThCPvXOOkaGRiQHrt kvZUVnKpeWbg5JPHcoEeSXrGIXHpej49sfv9Xxf1aCJLmCSbZDlr00PojVwSXBgcC2dX xjjGZb6/6U45VRgWrpWwqZIx5miY3xPaW3OAMsz2GfM/TmvEZiRHCUaM/uI8wrcqrSom qhWA== X-Gm-Message-State: AODbwcB/Qz4/mqllXROr3ZdOO+dIRER4DsrOGYLEnDFnt0ea7B2a3uc7 R1NPo5PFi7cIXzy0l2IihHLTN/Gxi7o5 X-Received: by 10.223.170.74 with SMTP id q10mr3402940wrd.171.1495121782244; Thu, 18 May 2017 08:36:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.136 with HTTP; Thu, 18 May 2017 08:36:21 -0700 (PDT) In-Reply-To: <846437B4-BE7D-4DF2-9C37-26D60180E82B@tony.li> References: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> <009601d2cfde$ad5abce0$081036a0$@eurecom.fr> <846437B4-BE7D-4DF2-9C37-26D60180E82B@tony.li> From: John Kenney Date: Thu, 18 May 2017 08:36:21 -0700 Message-ID: To: Tony Li Cc: =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= , Alexandre Petrescu , Russ Housley , "its@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cda32ba1ad4054fce2a3a" Archived-At: Subject: Re: [ipwave] MAC Address minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:41:51 -0000 --94eb2c1cda32ba1ad4054fce2a3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tony, Frequent identifier changes are one component of the privacy protection solution in DSRC. If IP is involved, I believe you are correct that IP addressing would need to change in synchrony with other identifiers. That's partly what I meant by "cross-layer and systemic." I don't know what the technical challenges associated with that are, but I believe that is the requirement where privacy needs to be protected. You're right to have concerns, but these are technical concerns that stem from privacy requirements, not privacy concerns. We have good solutions, so I want to avoid saying there are "strong privacy concerns." We would not deploy technology for which there were strong privacy concerns. To use an analogy, it would be horrible if a plane crashed, but the people flying on it need not have "strong concerns" that it will. The plane was designed, built, and maintained according to strong requirements to make sure it doesn't crash. Thanks, John On Thu, May 18, 2017 at 8:00 AM, Tony Li wrote: > > On May 18, 2017, at 7:50 AM, John Kenney > wrote: > > I do not agree with the statement that "there are strong privacy > concerns". I suggest changing "concerns" to "requirements". > > I think stating that there are strong concerns conveys a sense of this > being a big unsolved problem. For the DSRC/ITS-G5 community this is not t= he > case. Privacy protection, including careful avoidance of PII in messages, > pseudonymous certificates, and frequent identifier randomization, has bee= n > designed into DSRC/ITS-G5 from day 1. > > > Well, I for one am still mystified by how the solution maps to IP. DSRC > can do all of this work, but if my IP addressing doesn=E2=80=99t change i= n > synchrony, it seems like it all doesn=E2=80=99t help. And if the IP addre= sses do > change in synchrony, you abort upper layer TCP connections. > > So I=E2=80=99m still concerned. > > Tony > > --=20 John Kenney Director and Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --94eb2c1cda32ba1ad4054fce2a3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,

Frequent identifier changes ar= e one component of the privacy protection solution in DSRC. If IP is involv= ed, I believe you are correct that IP addressing would need to change in sy= nchrony with other identifiers. That's partly what I meant by "cro= ss-layer and systemic." I don't know what the technical challenges= associated with that are, but I believe that is the requirement where priv= acy needs to be protected.

You're right to hav= e concerns, but these are technical concerns that stem from privacy require= ments, not privacy concerns. We have good solutions, so I want to avoid say= ing there are "strong privacy concerns." We would not deploy tech= nology for which there were strong privacy concerns.

To use an analogy, it would be horrible if a plane crashed, but the peop= le flying on it need not have "strong concerns" that it will.=C2= =A0 The plane was designed, built, and maintained according to strong requi= rements to make sure it doesn't crash.

Thanks,=
John


On Thu, May 18, 2017 at 8:00 AM, Tony Li <tony.li@t= ony.li> wrote:

On May 18, 2017, at 7:50 AM, John Kenney <jkenney@us.toyota-itc.com> = wrote:

<= div>
I do not agree with the statement that "there are strong privacy c= oncerns". I suggest changing "concerns" to "requirement= s".

I think stating that there are strong concerns conv= eys a sense of this being a big unsolved problem. For the DSRC/ITS-G5 commu= nity this is not the case. Privacy protection, including careful avoidance = of PII in messages, pseudonymous certificates, and frequent identifier rand= omization, has been designed into DSRC/ITS-G5 from day 1. =C2=A0

Well, I for one am still mystified by h= ow the solution maps to IP.=C2=A0 DSRC can do all of this work, but if my I= P addressing doesn=E2=80=99t change in synchrony, it seems like it all does= n=E2=80=99t help. And if the IP addresses do change in synchrony, you abort= upper layer TCP connections.

So I=E2=80=99m still= concerned.

Tony



--
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--94eb2c1cda32ba1ad4054fce2a3a-- From nobody Thu May 18 09:28:42 2017 Return-Path: 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 78FB7127180 for ; Thu, 18 May 2017 09:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 6vCSXWJPU3fv for ; Thu, 18 May 2017 09:28:38 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 BE7E912951C for ; Thu, 18 May 2017 09:23:44 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id f55so38323776qta.3 for ; Thu, 18 May 2017 09:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=BK5YX5czRitb8Iddw62cj0EiPGLTPUwzl0k4220U4DA=; b=A09tYVrJsEpajFpcoR/QZxvF0KYSi1OB4Yj+QD3BDY8UjcwrnilHnNnyCKmh66A6XU 6bMB8zh2unjVbLqjfrKjRaM/M9oOJQcghoQ1M8tuVv7fZwyLfxT1vr5AxF/GeQW7tS1E O6poDSHfDy4GYJ2JRF55wsTUK5TM13x/hMHesijx11VcF08j8w1mpABY3S3cWe3jT8Ne 9r4shot9xVvCptl7zm/hxJ10iPDr/geTlo9RJkNL/Bdc2nDPuN3T4tfwnNhSXJBbdC0m ZwZsaGFiXuET4WimfV8PTFTyI2XJTUJOveavLYxUqu5OCBU+Z/Sg4xF/BD4W7L2nTAN2 p0pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=BK5YX5czRitb8Iddw62cj0EiPGLTPUwzl0k4220U4DA=; b=bWJ6sCeCz5sFHz9HB2p5iZfYt5I06nOcIdjZ4hIlpVJCR41Tmi5PTiM17IjBq2996s VZsMtCDSnxjmmdXNs2NvN+DTUH556tF/XIfkvSrCnmYDpoD1E+ZVKSc8s6GESxy5ZQ9/ 5B8uHbCzRUQgDWp6hMypZzTB+Twp1/TOnSzxQBrbu5QFUtdQSJeJgs38TMmKmnIA5SwZ iWI3Kp0ZXJRPnQt7Sgg2kfWv0bdKNRSqCAwTjFsyyyU0kFFb+D7mm6YigMrslrO9OFwh UHJTDgZKVr+w/QUN91HocYIGsVigAgaqZeSKCCudga8tL19SxnKswtLlm9V9rpxkNmlz gXOw== X-Gm-Message-State: AODbwcAArMDu9wsOM1ZZsbBYsWo5alLvJVk9n9TwDN8ohJ3PFOUKXB7r z16q0R9MShnR+Ira X-Received: by 10.200.42.252 with SMTP id c57mr5063709qta.282.1495124623857; Thu, 18 May 2017 09:23:43 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-247.washdc.fios.verizon.net. [108.48.182.247]) by smtp.gmail.com with ESMTPSA id g66sm3962310qkb.55.2017.05.18.09.23.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 09:23:42 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: "'Russ Housley'" Cc: , References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> In-Reply-To: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> Date: Thu, 18 May 2017 12:23:41 -0400 Message-ID: <019201d2cff3$1d415870$57c40950$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0193_01D2CFD1.96322970" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLaRBK88xykj8VYhlOq8uhoK7bq9wLPbpucn9Tf76A= Content-Language: en-us Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 16:28:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0193_01D2CFD1.96322970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the US, RSUs ARE NOT ROUTERS. There are logical boundaries between = RSU and functions accessing the infrastructure (when required): =20 FHWA Definition:=20 =931.6. Roadside Units DSRC enables communication between vehicles and roadside equipment, but = does not generate data necessary to provide warnings and advisories from infrastructure to drivers. To support V2I applications, DSRC must be integrated with existing traffic equipment, such as Signal Controllers and backhaul connections to Traffic Management = Centers (TMCs). DSRC devices that serve as the demarcation component between vehicles and = other mobile devices and existing traffic equipment will be referred to DSRC Roadside Units = (RSU) in this document.=94 =20 RSU - A connected device that is only allowed to operate from a fixed position (which may in fact be a permanent installation or from temporary equipment brought on-site for a period of time associated with an incident, road construction, or other event). Some RSEs may have connectivity to other nodes or the Internet. =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley Sent: Thursday, May 18, 2017 9:34 AM To: Alexandre Petrescu Cc: its@ietf.org Subject: [ipwave] RSU minor textual issue =20 =20 On May 18, 2017, at 5:39 AM, Alexandre Petrescu > = wrote: =20 OLD: RSU: Road Side Unit. An IP router equipped with, or connected to, at least one interface that is 802.11 and that is an interface that operates in OCB mode. A comment was made stating that an RSU is not a router, and that an RSU may be connected to a router via an interface, e.g. Ethernet, to access the infrastructure if required. But I think that some Road Side Units are indeed IP routers and they access the infrastructure and the Internet. This is an important point when using the IP protocol - be connected. I think I keep that text that way at this time. End issue. =20 Alex: =20 Some RSUs will be routers, but others will not. For example, an RSU = that sends messages to vehicles about foggy conditions does not need to be a router. I think the definition should allow both cases. =20 Russ =20 ------=_NextPart_000_0193_01D2CFD1.96322970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In the US, = RSUs ARE NOT ROUTERS. There are logical boundaries between RSU and = functions accessing the infrastructure (when required):

 

FHWA = Definition:

“1.6. Roadside = Units

DSRC enables = communication between vehicles and roadside equipment, but does = not

generate data necessary to = provide warnings and advisories from infrastructure to drivers. = To

support V2I applications, = DSRC must be integrated with existing traffic equipment, such = as

Signal Controllers and = backhaul connections to Traffic Management Centers (TMCs). = DSRC

devices that serve as the = demarcation component between vehicles and other mobile = devices

and existing traffic = equipment will be referred to DSRC Roadside Units (RSU) in this = document.”

 

RSU - A connected device that is only allowed to = operate from a fixed position

(which may in fact be a permanent installation or = from temporary

equipment = brought on-site for a period of time associated with = an

incident, road = construction, or other event). Some RSEs may have

connectivity to other nodes or the = Internet.

 

 

 

From: its = [mailto:its-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Thursday, May 18, 2017 9:34 AM
To: = Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: = its@ietf.org
Subject: [ipwave] RSU minor textual = issue

 

 

On May 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:

 

OLD:

RSU: Road = Side Unit. An IP router equipped with, or connected to, at
least one = interface that is 802.11 and that is an interface that
operates in = OCB mode.


A = comment was made stating that an RSU is not a router, and that an = RSU
may be connected to a router via an interface, e.g. Ethernet, to = access
the infrastructure if required.

But I think that some = Road Side Units are indeed IP routers and they
access the = infrastructure and the Internet.  This is an important = point
when using the IP protocol - be connected.

I think I = keep that text that way at this time.

End = issue.

 

Alex:

 

Some RSUs will be routers, but others will not. =  For example, an RSU that sends messages to vehicles about foggy = conditions does not need to be a router.  I think the definition = should allow both cases.

 

Russ

 

------=_NextPart_000_0193_01D2CFD1.96322970-- From nobody Thu May 18 10:27:12 2017 Return-Path: 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 131F81294E8 for ; Thu, 18 May 2017 10:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FPrggoA8d8nP for ; Thu, 18 May 2017 10:27:07 -0700 (PDT) Received: from mail2-156.sinamail.sina.com.cn (mail2-156.sinamail.sina.com.cn [60.28.2.156]) by ietfa.amsl.com (Postfix) with SMTP id 540D61243F3 for ; Thu, 18 May 2017 10:21:53 -0700 (PDT) Received: from webmail-2-96.pop3.fmail.tg.sinanode.com (HELO webmail.sinamail.sina.com.cn)([172.16.201.96]) by sina.com with SMTP 19 May 2017 01:21:52 +0800 (CST) X-Sender: langziwumingzhimi@sina.com X-SMAIL-MID: 1508631065105 Received: by webmail.sinamail.sina.com.cn (Postfix, from userid 496) id DF44940097; Fri, 19 May 2017 01:21:51 +0800 (CST) Date: Fri, 19 May 2017 01:21:51 +0800 Received: from langziwumingzhimi@sina.com([212.72.98.66]) by m0.mail.sina.com.cn via HTTP; Fri, 19 May 2017 01:21:51 +0800 (CST) Reply-To: langziwumingzhimi@sina.com From: To: =?UTF-8?B?RnJhbsOnb2lzX1NpbW9u?= , "'Russ Housley'" , Cc: "its" MIME-Version: 1.0 X-Priority: 3 X-MessageID: 591dd82f22c61e54_201705 X-Originating-IP: [172.16.201.96] X-Mailer: Sina WebMail 4.0 Content-Type: multipart/alternative; boundary="=-sinamail_alt_e51b38749171e1e89f4fe7525dc16d1a" Message-Id: <20170518172151.DF44940097@webmail.sinamail.sina.com.cn> Archived-At: Subject: [ipwave] =?gbk?q?=BB=D8=B8=B4=A3=BARe=3A__RSU_minor_textual_issue?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 17:27:11 -0000 --=-sinamail_alt_e51b38749171e1e89f4fe7525dc16d1a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Qnkgdmlld2luZyB0aGlzIGRpc2N1c3Npb24sIEkgd291bGQgbGlrZSB0byByYWlzZSBhIHF1ZXN0 aW9uIGZvciBWMkksIHdoaWNoIEkgc3RhbmRzIGZvciBpbmZyYXN0cnVjdHVyZS4gQW5kIFJTVSBp cyBhIGtpbmQgb2YgaW5mcmFzdHJ1Y3R1cmUuCk15IHF1ZXN0aW9uIGlzOiBJcyB0aGF0IGluZnJh c3RydWN0dXJlIG1lYW5zIHRyYW5zcG9ydGF0aW9uIGluZnJhc3RydWN0dXJlLCBvciBJbnRlcm5l dCBpbmZyYXN0cnVjdHVyZT8KSWYgaXQgaXMgdHJhbnNwb3J0YXRpb24gaW5mcmFzdHJ1Y3R1cmUs ICBSU1Ugc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGFzIGEgcm91dGVyLiAKQlJzLE1pbnBlbmcK CgotLS0tLSDljp/lp4vpgq7ku7YgLS0tLS0K5Y+R5Lu25Lq677yaRnJhbsOnb2lzX1NpbW9uIDxm eWdzaW1vbkBnbWFpbC5jb20+CuaUtuS7tuS6uu+8miInUnVzcyBIb3VzbGV5JyIgPGhvdXNsZXlA dmlnaWxzZWMuY29tPgrmioTpgIHkurrvvJpmeWdzaW1vbkBnbWFpbC5jb20sIGl0c0BpZXRmLm9y ZwrkuLvpopjvvJpSZTogW2lwd2F2ZV0gUlNVIG1pbm9yIHRleHR1YWwgaXNzdWUK5pel5pyf77ya MjAxN+W5tDA15pyIMTnml6UgMDDngrkyOOWIhgoKSW4gdGhlIFVTLCBSU1VzIEFSRSBOT1QgUk9V VEVSUy4gVGhlcmUgYXJlIGxvZ2ljYWwgYm91bmRhcmllcyBiZXR3ZWVuIFJTVSBhbmQgZnVuY3Rp b25zIGFjY2Vzc2luZyB0aGUgaW5mcmFzdHJ1Y3R1cmUgKHdoZW4gcmVxdWlyZWQpOiBGSFdBIERl ZmluaXRpb246IOKAnDEuNi4gUm9hZHNpZGUgVW5pdHNEU1JDIGVuYWJsZXMgY29tbXVuaWNhdGlv biBiZXR3ZWVuIHZlaGljbGVzIGFuZCByb2Fkc2lkZSBlcXVpcG1lbnQsIGJ1dCBkb2VzIG5vdGdl bmVyYXRlIGRhdGEgbmVjZXNzYXJ5IHRvIHByb3ZpZGUgd2FybmluZ3MgYW5kIGFkdmlzb3JpZXMg ZnJvbSBpbmZyYXN0cnVjdHVyZSB0byBkcml2ZXJzLiBUb3N1cHBvcnQgVjJJIGFwcGxpY2F0aW9u cywgRFNSQyBtdXN0IGJlIGludGVncmF0ZWQgd2l0aCBleGlzdGluZyB0cmFmZmljIGVxdWlwbWVu dCwgc3VjaCBhc1NpZ25hbCBDb250cm9sbGVycyBhbmQgYmFja2hhdWwgY29ubmVjdGlvbnMgdG8g VHJhZmZpYyBNYW5hZ2VtZW50IENlbnRlcnMgKFRNQ3MpLiBEU1JDZGV2aWNlcyB0aGF0IHNlcnZl IGFzIHRoZSBkZW1hcmNhdGlvbiBjb21wb25lbnQgYmV0d2VlbiB2ZWhpY2xlcyBhbmQgb3RoZXIg bW9iaWxlIGRldmljZXNhbmQgZXhpc3RpbmcgdHJhZmZpYyBlcXVpcG1lbnQgd2lsbCBiZSByZWZl cnJlZCB0byBEU1JDIFJvYWRzaWRlIFVuaXRzIChSU1UpIGluIHRoaXMgZG9jdW1lbnQu4oCdIFJT VSAtIEEgY29ubmVjdGVkIGRldmljZSB0aGF0IGlzIG9ubHkgYWxsb3dlZCB0byBvcGVyYXRlIGZy b20gYSBmaXhlZCBwb3NpdGlvbih3aGljaCBtYXkgaW4gZmFjdCBiZSBhIHBlcm1hbmVudCBpbnN0 YWxsYXRpb24gb3IgZnJvbSB0ZW1wb3JhcnllcXVpcG1lbnQgYnJvdWdodCBvbi1zaXRlIGZvciBh IHBlcmlvZCBvZiB0aW1lIGFzc29jaWF0ZWQgd2l0aCBhbmluY2lkZW50LCByb2FkIGNvbnN0cnVj dGlvbiwgb3Igb3RoZXIgZXZlbnQpLiBTb21lIFJTRXMgbWF5IGhhdmVjb25uZWN0aXZpdHkgdG8g b3RoZXIgbm9kZXMgb3IgdGhlIEludGVybmV0LiAgIEZyb206IGl0cyBbbWFpbHRvOml0cy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUnVzcyBIb3VzbGV5ClNlbnQ6IFRodXJzZGF5LCBN YXkgMTgsIDIwMTcgOTozNCBBTQpUbzogQWxleGFuZHJlIFBldHJlc2N1IDxhbGV4YW5kcmUucGV0 cmVzY3VAZ21haWwuY29tPgpDYzogaXRzQGlldGYub3JnClN1YmplY3Q6IFtpcHdhdmVdIFJTVSBt aW5vciB0ZXh0dWFsIGlzc3VlICBPbiBNYXkgMTgsIDIwMTcsIGF0IDU6MzkgQU0sIEFsZXhhbmRy ZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT4gd3JvdGU6IE9MRDoKUlNV OiBSb2FkIFNpZGUgVW5pdC4gQW4gSVAgcm91dGVyIGVxdWlwcGVkIHdpdGgsIG9yIGNvbm5lY3Rl ZCB0bywgYXQKbGVhc3Qgb25lIGludGVyZmFjZSB0aGF0IGlzIDgwMi4xMSBhbmQgdGhhdCBpcyBh biBpbnRlcmZhY2UgdGhhdApvcGVyYXRlcyBpbiBPQ0IgbW9kZS4KQSBjb21tZW50IHdhcyBtYWRl IHN0YXRpbmcgdGhhdCBhbiBSU1UgaXMgbm90IGEgcm91dGVyLCBhbmQgdGhhdCBhbiBSU1UKbWF5 IGJlIGNvbm5lY3RlZCB0byBhIHJvdXRlciB2aWEgYW4gaW50ZXJmYWNlLCBlLmcuIEV0aGVybmV0 LCB0byBhY2Nlc3MKdGhlIGluZnJhc3RydWN0dXJlIGlmIHJlcXVpcmVkLgoKQnV0IEkgdGhpbmsg dGhhdCBzb21lIFJvYWQgU2lkZSBVbml0cyBhcmUgaW5kZWVkIElQIHJvdXRlcnMgYW5kIHRoZXkK YWNjZXNzIHRoZSBpbmZyYXN0cnVjdHVyZSBhbmQgdGhlIEludGVybmV0LiAgVGhpcyBpcyBhbiBp bXBvcnRhbnQgcG9pbnQKd2hlbiB1c2luZyB0aGUgSVAgcHJvdG9jb2wgLSBiZSBjb25uZWN0ZWQu CgpJIHRoaW5rIEkga2VlcCB0aGF0IHRleHQgdGhhdCB3YXkgYXQgdGhpcyB0aW1lLgoKRW5kIGlz c3VlLiBBbGV4OiBTb21lIFJTVXMgd2lsbCBiZSByb3V0ZXJzLCBidXQgb3RoZXJzIHdpbGwgbm90 LiAgRm9yIGV4YW1wbGUsIGFuIFJTVSB0aGF0IHNlbmRzIG1lc3NhZ2VzIHRvIHZlaGljbGVzIGFi b3V0IGZvZ2d5IGNvbmRpdGlvbnMgZG9lcyBub3QgbmVlZCB0byBiZSBhIHJvdXRlci4gIEkgdGhp bmsgdGhlIGRlZmluaXRpb24gc2hvdWxkIGFsbG93IGJvdGggY2FzZXMuIFJ1c3MgDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwppdHMgbWFpbGluZyBsaXN0 Cml0c0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cwo= --=-sinamail_alt_e51b38749171e1e89f4fe7525dc16d1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5CeSB2aWV3aW5nIHRoaXMgZGlzY3Vzc2lvbiwgSSB3b3VsZCBsaWtlIHRvIHJhaXNlIGEg cXVlc3Rpb24gZm9yIFYySSwgd2hpY2ggSSBzdGFuZHMgZm9yIGluZnJhc3RydWN0dXJlLiBBbmQg UlNVIGlzIGEga2luZCBvZiBpbmZyYXN0cnVjdHVyZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pk15IHF1ZXN0aW9uIGlzOiBJcyB0aGF0IGluZnJhc3RydWN0dXJlIG1lYW5zIHRyYW5zcG9ydGF0 aW9uIGluZnJhc3RydWN0dXJlLCBvciBJbnRlcm5ldCBpbmZyYXN0cnVjdHVyZT88L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PklmIGl0IGlzIHRyYW5zcG9ydGF0aW9uIGluZnJhc3RydWN0dXJlLCAm bmJzcDtSU1Ugc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGFzIGEgcm91dGVyLiZuYnNwOzwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+QlJzLDwvZGl2PjxkaXY+TWlucGVuZzwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9Im9yaWdib2R5Ij48 ZGl2IHN0eWxlPSJiYWNrZ3JvdW5kOiAjZjJmMmYyOyI+LS0tLS0g5Y6f5aeL6YKu5Lu2IC0tLS0t PGJyPuWPkeS7tuS6uu+8mkZyYW7Dp29pc19TaW1vbiAmbHQ7Znlnc2ltb25AZ21haWwuY29tJmd0 Ozxicj7mlLbku7bkurrvvJoiJ1J1c3MgSG91c2xleSciICZsdDtob3VzbGV5QHZpZ2lsc2VjLmNv bSZndDs8YnI+5oqE6YCB5Lq677yaZnlnc2ltb25AZ21haWwuY29tLCBpdHNAaWV0Zi5vcmc8YnI+ 5Li76aKY77yaUmU6IFtpcHdhdmVdIFJTVSBtaW5vciB0ZXh0dWFsIGlzc3VlPGJyPuaXpeacn++8 mjIwMTflubQwNeaciDE55pelIDAw54K5MjjliIY8YnI+PC9kaXY+PGJyPjxkaXYgY2xhc3M9IiI+ PHAgY2xhc3M9IiI+SW4gdGhlIFVTLCBSU1VzIEFSRSBOT1QgUk9VVEVSUy4gVGhlcmUgYXJlIGxv Z2ljYWwgYm91bmRhcmllcyBiZXR3ZWVuIFJTVSBhbmQgZnVuY3Rpb25zIGFjY2Vzc2luZyB0aGUg aW5mcmFzdHJ1Y3R1cmUgKHdoZW4gcmVxdWlyZWQpOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSIi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPSIiPkZIV0EgRGVmaW5pdGlvbjogPG86cD48 L286cD48L3A+PHAgY2xhc3M9IiI+PGk+4oCcMS42LiBSb2Fkc2lkZSBVbml0czxvOnA+PC9vOnA+ PC9pPjwvcD48cCBjbGFzcz0iIj48aT5EU1JDIGVuYWJsZXMgY29tbXVuaWNhdGlvbiBiZXR3ZWVu IHZlaGljbGVzIGFuZCByb2Fkc2lkZSBlcXVpcG1lbnQsIGJ1dCBkb2VzIG5vdDxvOnA+PC9vOnA+ PC9pPjwvcD48cCBjbGFzcz0iIj48aT5nZW5lcmF0ZSBkYXRhIG5lY2Vzc2FyeSB0byBwcm92aWRl IHdhcm5pbmdzIGFuZCBhZHZpc29yaWVzIGZyb20gaW5mcmFzdHJ1Y3R1cmUgdG8gZHJpdmVycy4g VG88bzpwPjwvbzpwPjwvaT48L3A+PHAgY2xhc3M9IiI+PGk+c3VwcG9ydCBWMkkgYXBwbGljYXRp b25zLCBEU1JDIG11c3QgYmUgaW50ZWdyYXRlZCB3aXRoIGV4aXN0aW5nIHRyYWZmaWMgZXF1aXBt ZW50LCBzdWNoIGFzPG86cD48L286cD48L2k+PC9wPjxwIGNsYXNzPSIiPjxpPlNpZ25hbCBDb250 cm9sbGVycyBhbmQgYmFja2hhdWwgY29ubmVjdGlvbnMgdG8gVHJhZmZpYyBNYW5hZ2VtZW50IENl bnRlcnMgKFRNQ3MpLiBEU1JDPG86cD48L286cD48L2k+PC9wPjxwIGNsYXNzPSIiPjxpPmRldmlj ZXMgdGhhdCBzZXJ2ZSBhcyB0aGUgZGVtYXJjYXRpb24gY29tcG9uZW50IGJldHdlZW4gdmVoaWNs ZXMgYW5kIG90aGVyIG1vYmlsZSBkZXZpY2VzPG86cD48L286cD48L2k+PC9wPjxwIGNsYXNzPSIi PjxpPmFuZCBleGlzdGluZyB0cmFmZmljIGVxdWlwbWVudCB3aWxsIGJlIHJlZmVycmVkIHRvIERT UkMgUm9hZHNpZGUgVW5pdHMgKFJTVSkgaW4gdGhpcyBkb2N1bWVudC7igJ08bzpwPjwvbzpwPjwv aT48L3A+PHAgY2xhc3M9IiI+PGk+PG86cD4mbmJzcDs8L286cD48L2k+PC9wPjxwIGNsYXNzPSIi PjxpPlJTVSAtIEEgY29ubmVjdGVkIGRldmljZSB0aGF0IGlzIG9ubHkgYWxsb3dlZCB0byBvcGVy YXRlIGZyb20gYSBmaXhlZCBwb3NpdGlvbjxvOnA+PC9vOnA+PC9pPjwvcD48cCBjbGFzcz0iIj48 aT4od2hpY2ggbWF5IGluIGZhY3QgYmUgYSBwZXJtYW5lbnQgaW5zdGFsbGF0aW9uIG9yIGZyb20g dGVtcG9yYXJ5PG86cD48L286cD48L2k+PC9wPjxwIGNsYXNzPSIiPjxpPmVxdWlwbWVudCBicm91 Z2h0IG9uLXNpdGUgZm9yIGEgcGVyaW9kIG9mIHRpbWUgYXNzb2NpYXRlZCB3aXRoIGFuPG86cD48 L286cD48L2k+PC9wPjxwIGNsYXNzPSIiPjxpPmluY2lkZW50LCByb2FkIGNvbnN0cnVjdGlvbiwg b3Igb3RoZXIgZXZlbnQpLiBTb21lIFJTRXMgbWF5IGhhdmU8bzpwPjwvbzpwPjwvaT48L3A+PHAg Y2xhc3M9IiI+PGk+Y29ubmVjdGl2aXR5IHRvIG90aGVyIG5vZGVzIG9yIHRoZSBJbnRlcm5ldC48 L2k+PG86cD48L286cD48L3A+PHAgY2xhc3M9IiI+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9IiI+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9IiI+PG86cD4mbmJzcDs8L286cD48 L3A+PGRpdj48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+PHAgY2xhc3M9IiI+PGI+RnJvbTo8L2I+ IGl0cyBbbWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlJ1 c3MgSG91c2xleTxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAxOCwgMjAxNyA5OjM0IEFN PGJyPjxiPlRvOjwvYj4gQWxleGFuZHJlIFBldHJlc2N1ICZsdDthbGV4YW5kcmUucGV0cmVzY3VA Z21haWwuY29tJmd0Ozxicj48Yj5DYzo8L2I+IGl0c0BpZXRmLm9yZzxicj48Yj5TdWJqZWN0Ojwv Yj4gW2lwd2F2ZV0gUlNVIG1pbm9yIHRleHR1YWwgaXNzdWU8bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48cCBjbGFzcz0iIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz0iIj48bzpwPiZu YnNwOzwvbzpwPjwvcD48ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPjxkaXY+PHAgY2xhc3M9IiI+T24gTWF5IDE4LCAyMDE3LCBhdCA1 OjM5IEFNLCBBbGV4YW5kcmUgUGV0cmVzY3UgJmx0OzxhIHRhcmdldD0iX2JsYW5rIiBocmVmPSJt YWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbSI+YWxleGFuZHJlLnBldHJlc2N1QGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPSIiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T0xE OjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij48YnI+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPjxwIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJTVTogUm9hZCBT aWRlIFVuaXQuIEFuIElQIHJvdXRlciBlcXVpcHBlZCB3aXRoLCBvciBjb25uZWN0ZWQgdG8sIGF0 PGJyPmxlYXN0IG9uZSBpbnRlcmZhY2UgdGhhdCBpcyA4MDIuMTEgYW5kIHRoYXQgaXMgYW4gaW50 ZXJmYWNlIHRoYXQ8YnI+b3BlcmF0ZXMgaW4gT0NCIG1vZGUuPG86cD48L286cD48L3NwYW4+PC9w PjwvYmxvY2txdW90ZT48cCBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+QSBjb21tZW50 IHdhcyBtYWRlIHN0YXRpbmcgdGhhdCBhbiBSU1UgaXMgbm90IGEgcm91dGVyLCBhbmQgdGhhdCBh biBSU1U8YnI+bWF5IGJlIGNvbm5lY3RlZCB0byBhIHJvdXRlciB2aWEgYW4gaW50ZXJmYWNlLCBl LmcuIEV0aGVybmV0LCB0byBhY2Nlc3M8YnI+dGhlIGluZnJhc3RydWN0dXJlIGlmIHJlcXVpcmVk Ljxicj48YnI+QnV0IEkgdGhpbmsgdGhhdCBzb21lIFJvYWQgU2lkZSBVbml0cyBhcmUgaW5kZWVk IElQIHJvdXRlcnMgYW5kIHRoZXk8YnI+YWNjZXNzIHRoZSBpbmZyYXN0cnVjdHVyZSBhbmQgdGhl IEludGVybmV0LiAmbmJzcDtUaGlzIGlzIGFuIGltcG9ydGFudCBwb2ludDxicj53aGVuIHVzaW5n IHRoZSBJUCBwcm90b2NvbCAtIGJlIGNvbm5lY3RlZC48YnI+PGJyPkkgdGhpbmsgSSBrZWVwIHRo YXQgdGV4dCB0aGF0IHdheSBhdCB0aGlzIHRpbWUuPGJyPjxicj5FbmQgaXNzdWUuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz0iIj48bzpwPiZu YnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPSIiPkFsZXg6PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz0iIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PSIiPlNvbWUgUlNVcyB3aWxsIGJlIHJvdXRlcnMsIGJ1dCBvdGhlcnMgd2lsbCBub3QuICZuYnNw O0ZvciBleGFtcGxlLCBhbiBSU1UgdGhhdCBzZW5kcyBtZXNzYWdlcyB0byB2ZWhpY2xlcyBhYm91 dCBmb2dneSBjb25kaXRpb25zIGRvZXMgbm90IG5lZWQgdG8gYmUgYSByb3V0ZXIuICZuYnNwO0kg dGhpbmsgdGhlIGRlZmluaXRpb24gc2hvdWxkIGFsbG93IGJvdGggY2FzZXMuPG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSIiPlJ1c3M8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSIiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+aXRzIG1haWxpbmcgbGlzdDxicj5pdHNAaWV0Zi5v cmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHM8YnI+PC9kaXY+ --=-sinamail_alt_e51b38749171e1e89f4fe7525dc16d1a-- From nobody Thu May 18 10:36:21 2017 Return-Path: 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 745CB127B31 for ; Thu, 18 May 2017 10:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 w5t4w1o-qXiD for ; Thu, 18 May 2017 10:36:17 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 69C8E128BB7 for ; Thu, 18 May 2017 10:30:37 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id f55so39916870qta.3 for ; Thu, 18 May 2017 10:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=TIOQ/ECfIT09gD/Q/7qvUYywjBPyOBqSAeGi3kkT4Ag=; b=LjVYAYvFmKhq3dlJghKS8smXNqKmJfDJKZgjekvJPrsTiJyV1dayshWP0uGlTxo7tS P+zik3oGt4NAWXNZldYWj9Z6uHf965ePimjKThrUVZmmRW94usEopR8hDEDrYQoUIc7W NrWB/LqE749vp0mM7XE8DD2PpPRn5gGasqhorAgLSAgfXO1W+e3GKOykZHLg2xcoIlRI KcnT+7wLTH/Q/UL2K9Rx+PkWMe7M2ylLmCQfh90tRsVAgZPMw3ycoLWjnjCKoUC3wte1 D/Kj1SuZhKJfniVT/kt03F7XcnnZ5y6R1jEY3ngaaoPd60UxptjsClIwNn058gIAZkEf xu2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=TIOQ/ECfIT09gD/Q/7qvUYywjBPyOBqSAeGi3kkT4Ag=; b=NV0K9F7dUEoN+aq6KXQjMdvuglS+zUtZau/Y+iZuHMDu/GhWN01oWUmyhDZcjI/08Q rndB5EY7Y1Ohh6j+6mPz/3rn4ktBPqZbDbreX/cZqQz9Vb8V9xuWj9y5SS5itfwV7n07 Pe2vcb5IQuBTNFkKHoKqR6x6p1iccZA4Q0TGDu7jI/4VygbZAYQTzGlax7iTp/WZbzBh E7dDLNfc2lcQ/BgYbkltBjYRQMkG1wYH7csHL7T89vVVRBdpjpJgG9+PJ4atkYnKSI94 5+ZPZYw5Qz1T3TrI2I8qcDzCKQ9Jm++pk5Oztzq3LrJ9VrYvNv37Pyxc5ybFR9fJ1Wv/ SLfQ== X-Gm-Message-State: AODbwcBeEi/WXCkWmEFgEb0vu2YcCrDA1DFtKxamM1LFRoDOLmMKyL6Z gSEqLemghfcB+A== X-Received: by 10.200.38.227 with SMTP id 32mr4752774qtp.275.1495128636536; Thu, 18 May 2017 10:30:36 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-247.washdc.fios.verizon.net. [108.48.182.247]) by smtp.gmail.com with ESMTPSA id 29sm4245506qkz.38.2017.05.18.10.30.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 10:30:35 -0700 (PDT) From: =?UTF-8?Q?Fran=C3=A7ois_Simon?= To: Cc: References: <20170518172151.DF44940097@webmail.sinamail.sina.com.cn> In-Reply-To: <20170518172151.DF44940097@webmail.sinamail.sina.com.cn> Date: Thu, 18 May 2017 13:30:33 -0400 Message-ID: <01ad01d2cffc$74e10d60$5ea32820$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AE_01D2CFDA.EDDC65B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQII2sauNVGQjzqHIG+YJr7kANVbzqGOQhJw Content-Language: en-us Archived-At: Subject: Re: [ipwave] =?utf-8?b?5Zue5aSN77yaUmU6ICBSU1UgbWlub3IgdGV4dHVhbCBp?= =?utf-8?q?ssue?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 17:36:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AE_01D2CFDA.EDDC65B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It is any nodes outside the DSRC network which can provides the RSU with = information it needs for its applications (monetary transactions, = traveling information, maps, weather, etc.). =20 From: langziwumingzhimi@sina.com [mailto:langziwumingzhimi@sina.com]=20 Sent: Thursday, May 18, 2017 1:22 PM To: Fran=C3=A7ois_Simon ; 'Russ Housley' = Cc: its Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9ARe: [ipwave] RSU minor textual issue =20 By viewing this discussion, I would like to raise a question for V2I, = which I stands for infrastructure. And RSU is a kind of infrastructure. =20 My question is: Is that infrastructure means transportation = infrastructure, or Internet infrastructure? =20 If it is transportation infrastructure, RSU should not be considered as = a router.=20 =20 BRs, Minpeng =20 =20 =20 ----- =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 ----- =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AFran=C3=A7ois_Simon = > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A"'Russ Housley'" = > =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Afygsimon@gmail.com = , its@ietf.org =20 =E4=B8=BB=E9=A2=98=EF=BC=9ARe: [ipwave] RSU minor textual issue =E6=97=A5=E6=9C=9F=EF=BC=9A2017=E5=B9=B405=E6=9C=8819=E6=97=A5 = 00=E7=82=B928=E5=88=86 =20 In the US, RSUs ARE NOT ROUTERS. There are logical boundaries between = RSU and functions accessing the infrastructure (when required): =20 FHWA Definition:=20 =E2=80=9C1.6. Roadside Units DSRC enables communication between vehicles and roadside equipment, but = does not generate data necessary to provide warnings and advisories from = infrastructure to drivers. To support V2I applications, DSRC must be integrated with existing traffic = equipment, such as Signal Controllers and backhaul connections to Traffic Management = Centers (TMCs). DSRC devices that serve as the demarcation component between vehicles and = other mobile devices and existing traffic equipment will be referred to DSRC Roadside Units = (RSU) in this document.=E2=80=9D =20 RSU - A connected device that is only allowed to operate from a fixed = position (which may in fact be a permanent installation or from temporary equipment brought on-site for a period of time associated with an incident, road construction, or other event). Some RSEs may have connectivity to other nodes or the Internet. =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley Sent: Thursday, May 18, 2017 9:34 AM To: Alexandre Petrescu > Cc: its@ietf.org =20 Subject: [ipwave] RSU minor textual issue =20 =20 On May 18, 2017, at 5:39 AM, Alexandre Petrescu = > = wrote: =20 OLD: RSU: Road Side Unit. An IP router equipped with, or connected to, at least one interface that is 802.11 and that is an interface that operates in OCB mode. A comment was made stating that an RSU is not a router, and that an RSU may be connected to a router via an interface, e.g. Ethernet, to access the infrastructure if required. But I think that some Road Side Units are indeed IP routers and they access the infrastructure and the Internet. This is an important point when using the IP protocol - be connected. I think I keep that text that way at this time. End issue. =20 Alex: =20 Some RSUs will be routers, but others will not. For example, an RSU = that sends messages to vehicles about foggy conditions does not need to = be a router. I think the definition should allow both cases. =20 Russ =20 _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its ------=_NextPart_000_01AE_01D2CFDA.EDDC65B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It is any = nodes outside the DSRC network which can provides the RSU with = information it needs for its applications (monetary transactions, = traveling information, =C2=A0maps, weather, etc.).

 

From: = langziwumingzhimi@sina.com [mailto:langziwumingzhimi@sina.com] =
Sent: Thursday, May 18, 2017 1:22 PM
To: = Fran=C3=A7ois_Simon <fygsimon@gmail.com>; 'Russ Housley' = <housley@vigilsec.com>
Cc: its = <its@ietf.org>
Subject: =E5=9B=9E=E5=A4=8D=EF=BC=9ARe: [ipwave] RSU minor = textual issue

 

By = viewing this discussion, I would like to raise a question for V2I, which = I stands for infrastructure. And RSU is a kind of = infrastructure.

 

My question is: Is that infrastructure means = transportation infrastructure, or Internet = infrastructure?

 

If it is transportation infrastructure,  RSU = should not be considered as a router. 

 

BRs,

Minpeng

 

 

 

----- =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 -----
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AFran=C3=A7= ois_Simon <fygsimon@gmail.com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A"'Russ = Housley'" <housley@vigilsec.com>
=E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Afygsimon@gmail.com, its@ietf.org
=E4=B8=BB=E9=A2=98=EF=BC=9ARe: [ipwave] RSU minor = textual issue
=E6=97=A5=E6=9C=9F=EF=BC=9A2017=E5=B9=B405=E6=9C=8819=E6=97=A5 00=E7=82=B928=E5=88=86

 

In the US, = RSUs ARE NOT ROUTERS. There are logical boundaries between RSU and = functions accessing the infrastructure (when required):

 <= /o:p>

FHWA = Definition:

=E2=80=9C= 1.6. Roadside Units

DSRC = enables communication between vehicles and roadside equipment, but does = not

generate = data necessary to provide warnings and advisories from infrastructure to = drivers. To

support = V2I applications, DSRC must be integrated with existing traffic = equipment, such as

Signal = Controllers and backhaul connections to Traffic Management Centers = (TMCs). DSRC

devices = that serve as the demarcation component between vehicles and other = mobile devices

and = existing traffic equipment will be referred to DSRC Roadside Units (RSU) = in this document.=E2=80=9D

 

RSU - A = connected device that is only allowed to operate from a fixed = position

(which = may in fact be a permanent installation or from = temporary

equipment= brought on-site for a period of time associated with = an

incident,= road construction, or other event). Some RSEs may = have

connectiv= ity to other nodes or the Internet.

 <= /o:p>

 <= /o:p>

 <= /o:p>

From:= its [mailto:its-bounces@ietf.org] = On Behalf Of Russ Housley
Sent: Thursday, May 18, 2017 = 9:34 AM
To: Alexandre Petrescu <alexandre.petrescu@gmail.com= >
Cc: its@ietf.org
Subject: = [ipwave] RSU minor textual issue

 <= /o:p>

 <= /o:p>

On May 18, = 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> = wrote:

 <= /o:p>

OLD:<= o:p>

RSU: Road = Side Unit. An IP router equipped with, or connected to, at
least one = interface that is 802.11 and that is an interface that
operates in = OCB mode.


A = comment was made stating that an RSU is not a router, and that an = RSU
may be connected to a router via an interface, e.g. Ethernet, to = access
the infrastructure if required.

But I think that some = Road Side Units are indeed IP routers and they
access the = infrastructure and the Internet.  This is an important = point
when using the IP protocol - be connected.

I think I = keep that text that way at this time.

End = issue.

 <= /o:p>

Alex:

 <= /o:p>

Some RSUs = will be routers, but others will not.  For example, an RSU that = sends messages to vehicles about foggy conditions does not need to be a = router.  I think the definition should allow both = cases.

 <= /o:p>

Russ

 <= /o:p>

_______________________________________________
its = mailing list
its@ietf.org
https://www.ietf.org/m= ailman/listinfo/its

------=_NextPart_000_01AE_01D2CFDA.EDDC65B0-- From nobody Thu May 18 11:17:46 2017 Return-Path: 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 C613A1201F2 for ; Thu, 18 May 2017 11:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ieqY9w48TRKD for ; Thu, 18 May 2017 11:17:42 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 3EED5129B98 for ; Thu, 18 May 2017 11:11:59 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id m17so27533054pfg.3 for ; Thu, 18 May 2017 11:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=Wr/V0OOngbXjWb9FmsPlX95xYzmTF3Nqg6002ROAZQs=; b=jAcmA8FZy3+fKAKhs04qj1aQRaAvalKbeE5Ot5ttcC1NFZJQlvLE9ANQrtGAG51Lig i4zf4UipoLUVDol4t70+gUtl0bRblZCY1qQHdYRONesbVg6g2DqbpMuID3wy7B+xegT8 91VWtSjOgXvOdspDLqOq3+LWqBXLMxQH7tQlWV5PkegOrji7W+5LspRTc2X0MOBeQDTo 9lk/VoDGW1SfgPmLF0KLhLJPykpeyeU7AmVWsq6RBMzrjI/ekhQEcCSnxLHDmoBm7hGn aVd64ZcXH8vOkDkwhFcuFRWi79n5R4/2QrXdnso4rNGL9Ry3/TcompkoH1XTLdVTUjsO fKIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=Wr/V0OOngbXjWb9FmsPlX95xYzmTF3Nqg6002ROAZQs=; b=CYL89d5DSsp/TW0eI7nA6GZyWFLUBcIP0QI0WPFxC+rS10OC6/gG2CCeplfdwQoHn6 DP9WXYQigSxPdx6h49OGbIyAJCE+xkAxOIyPcILHhZATgribaHIypRDMeHeC2+1P3c90 IUNvXjxKkr3lfjmNvJGomdHLCxSg+9kxA0hEW3kS13NVMgMhdac1Qb+vaSTZCC5kFBhr lI92BbtNP+e4GsFkHuo9yeCvfJVjhzytmMEZeke7Iown+YWTDVfNGDVbLdx5763kpWGv S2L0fUnAfFFSs3hJ+OHoZv3lxup+qCgoSZeGw/F9EWj86wzouaHZnuFn1AbDkzv8PEf7 EpEw== X-Gm-Message-State: AODbwcCEyi7V90QdgmeIvSF9akFcf6s3VqhzCH0iwPcaEuwBB36k/FMW wH1Dz9tIIgX5gw== X-Received: by 10.98.72.213 with SMTP id q82mr6061229pfi.152.1495131118265; Thu, 18 May 2017 11:11:58 -0700 (PDT) Received: from localhost.localdomain (c-71-198-163-21.hsd1.ca.comcast.net. [71.198.163.21]) by smtp.gmail.com with ESMTPSA id l7sm16632477pgn.10.2017.05.18.11.11.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 11:11:57 -0700 (PDT) Message-ID: <1495131116.2400.9.camel@gmail.com> From: Rex Buddenberg To: Russ Housley , Alexandre Petrescu Cc: "its@ietf.org" Date: Thu, 18 May 2017 11:11:56 -0700 In-Reply-To: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 18:17:45 -0000 Russ, You said: > Some RSUs will be routers, but others will not.  For example, an RSU > that sends messages to vehicles about foggy conditions does not need > to be a router.  I think the definition should allow both cases.>  I think that a specific focus on RSU would make some sense.  Some thoughts: - router.  RSU would be a router.  plain/simple.  The wired internet on its backside (terrestrial-WAN in my classroom terminology) would certainly be made up of routable networks.  And the radio-WANs on the front side would be routable network(s) too.   - yes, but...  There are major differences, both qualitative and quantitative between terrestrial-WANs and radio-WANs.        o terrestrial plumbing is largely made up of point-point links (example, fiber optic strings between routers).  Radio-WANs are shared media (with consequent need for MAC which is absent in point-point stuff).       o capacity.  Radio-WANs are measured, on good days, in Mbit/sec and that capacity is pro-rated across all stations on the net.  By contrast, fiber links are routinely provisioned at 10Gbit/sec -- four orders of magnitude more capacious (a capacity essentially infinite compared to the radio-WAN).  This disparity will continue to grow over time -- compare the potential of 1) DWDM advances and 2) more fibers to the limitations of spectrum.   Multicast has far more payoff in radio- WAN than in point-point plumbing.  Especially in a bandwidth-limited radio-WAN.        o noise.  The radio-WAN will experience orders of magnitude more bit error rate than the terrestrial-WAN.  This tends to influence variables like packet size -- the noisier the environment the smaller the packets, minimizing the expense per bit error.        Some of these limitations might indicate some layer 7 gateway functions rather than the simple layer 3 forwarding that a router does.   - server functions.  RSU is ideally situated to provide some auxiliary functions. And some are vital. DNS is a fairly obvious example.  DNS lookups can consume a considerable amount of connection setup time so colocating a caching DNS server at RSU strikes  me as cost-effective. And as noted in last message, serving public keys would be required somewhere in the internetwork; closer to the moving vehicle should be better.     Another server function that comes immediately to my mind is differential GPS* (or differential Galileo if you are to be Euro and eschew US GPS;-). An auxiliary function as a dGPS reference receiver makes sense to me; the marginal cost is low.     It'd make sense to mount cameras as peripherals to RSU, at least in some situations -- your foggy conditions example.  This list is flexible and open-ended; both functions to help automobile traffic and functions to help traffic managers ashore. Suggestion.  Would a standards-track RFC titled 'Requirements for RoadSi de Units' make sense?  Not unlike the old RFC1812       (*in a former life, I designed the differential GPS program that US Coas t Guard ran in maritime areas to provide integrity check and improved accuracy to raw GPS.  I can explain, ad nauseum, why this is a good idea and how it would work.  As we are discovering how fragile GPS is, we may see Loran reappear and differential Loran works too -- indeed that's where we got the dGPS idea from.) On Thu, 2017-05-18 at 09:33 -0400, Russ Housley wrote: > (*in a former life, I designed the differential GPS program that US Coast Guard ran in maritime areas to provide integrity check and improved accuracy to raw GPS.  I can explain, ad nauseum, why this is a good idea and how it would work.  As we are discovering how fragile GPS is, we may see Loran reappear and differential Loran works too -- indeed that's where we got the dGPS idea from.) > > On May 18, 2017, at 5:39 AM, Alexandre Petrescu > @gmail.com> wrote: > > > > OLD: > > > RSU: Road Side Unit. An IP router equipped with, or connected to, > > > at > > > least one interface that is 802.11 and that is an interface that > > > operates in OCB mode. > > A comment was made stating that an RSU is not a router, and that an > > RSU > > may be connected to a router via an interface, e.g. Ethernet, to > > access > > the infrastructure if required. > > > > But I think that some Road Side Units are indeed IP routers and > > they > > access the infrastructure and the Internet.  This is an important > > point > > when using the IP protocol - be connected. > > > > I think I keep that text that way at this time. > > > > End issue. > Alex: > > Some RSUs will be routers, but others will not.  For example, an RSU > that sends messages to vehicles about foggy conditions does not need > to be a router.  I think the definition should allow both cases. > > Russ > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu May 18 13:51:51 2017 Return-Path: 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 97ED3129BB6 for ; Thu, 18 May 2017 13:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2_l8VrDNMG52 for ; Thu, 18 May 2017 13:51:47 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 D4B14127BA3 for ; Thu, 18 May 2017 13:45:37 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id f55so44209619qta.3 for ; Thu, 18 May 2017 13:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=Lihs7gqWFlzMeKw8fZC4Z+sLm7bA+FOhq2CjOuWxidA=; b=WHdjtzwDirB7nDJxGjk20FmNN6ZF1Xod9FDr9pEsFUpHECtvhBVaLUlYKJvAaWe8zg awh9HGITuHx2eibrBCD9o9NGxOtyrDWUnctvRKOZEs5jmZPUjww3f3DBTGhrI/nXOZ1U bsgpHD/j9u9F48scWonILGriHsZvCIARLnJfFIMNnwjk6GlwigsTnqvS20d5jEXiGWpL KThgxIQWv9MTLLU3nmLjGiLDNv4cQ2url7uaRmf+7e9Ahkdw3HA0KOnaP7jmy48jS2lV ziXAUlNR9WfaLxuUNZVMQCmzxjc7lHIpJtphPbA+qbIhWUeTtSwNrK0bqtFHYjmF1iTb qm2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=Lihs7gqWFlzMeKw8fZC4Z+sLm7bA+FOhq2CjOuWxidA=; b=Tb4+HLvE6YVTiq+7KwHysHaPK5k7eTGRZ/lwD3NAPewFaI0qrwooeOrjgD8NUYdGlC Zoj4av28yifyqTJfFTNH/ZYMNHABa0mNPXM0yXC8NxtHej59rV0Xp+3qfXKKODaq0cUI kbKqCABOv2/aIUgjzVdr06torKAXj4SduRe52UMFviDVXpcgjAQ89tPyBNW2Vhe03jKi nmkRuAfXbQu8iMoxnA6no6zfNkz8MllBWh4WUOtDLgiPA62fk+8kymeWO/tkN2zCR30R wPtPzHoz4V5d8zMPFOZvkbYtMK/g9nmwuzUge93nVKzi6QfUwufO8osJUGiYLRADHukq CDXg== X-Gm-Message-State: AODbwcCzn6Cxv6tOPQhQwVQI5Ru9/ME0wDRQG3BZPzfj9Pc3oVw1WJVs aQ5U9Pdd9yYVdA== X-Received: by 10.200.33.232 with SMTP id 37mr6407329qtz.189.1495140337104; Thu, 18 May 2017 13:45:37 -0700 (PDT) Received: from FrancoisPC (pool-108-48-182-247.washdc.fios.verizon.net. [108.48.182.247]) by smtp.gmail.com with ESMTPSA id f81sm4427105qkb.37.2017.05.18.13.45.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 May 2017 13:45:36 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois_Simon?= To: "'Russ Housley'" Cc: , References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> In-Reply-To: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> Date: Thu, 18 May 2017 16:45:34 -0400 Message-ID: <022e01d2d017$b2dd04a0$18970de0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022F_01D2CFF6.2BCDD5A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLaRBK88xykj8VYhlOq8uhoK7bq9wLPbpucAksG+Is= Content-Language: en-us Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 20:51:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022F_01D2CFF6.2BCDD5A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In the US, RSUs ARE NOT ROUTERS. There are logical boundaries between RSU and devices accessing the infrastructure (when required): From: its [mailto:its-bounces@ietf.org] On Behalf Of Russ Housley Sent: Thursday, May 18, 2017 9:34 AM To: Alexandre Petrescu Cc: its@ietf.org Subject: [ipwave] RSU minor textual issue On May 18, 2017, at 5:39 AM, Alexandre Petrescu > wrote: OLD: RSU: Road Side Unit. An IP router equipped with, or connected to, at least one interface that is 802.11 and that is an interface that operates in OCB mode. A comment was made stating that an RSU is not a router, and that an RSU may be connected to a router via an interface, e.g. Ethernet, to access the infrastructure if required. But I think that some Road Side Units are indeed IP routers and they access the infrastructure and the Internet. This is an important point when using the IP protocol - be connected. I think I keep that text that way at this time. End issue. Alex: Some RSUs will be routers, but others will not. For example, an RSU that sends messages to vehicles about foggy conditions does not need to be a router. I think the definition should allow both cases. Russ ------=_NextPart_000_022F_01D2CFF6.2BCDD5A0 Content-Type: text/html; boundary="----=_NextPart_000_018B_01D2CFD1.0E4CE2C0"; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In the US, = RSUs ARE NOT ROUTERS. There are logical boundaries between RSU and = devices accessing the infrastructure (when required):

 

 

 

From: its = [mailto:its-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Thursday, May 18, 2017 9:34 AM
To: = Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: = its@ietf.org
Subject: [ipwave] RSU minor textual = issue

 

 

On May 18, 2017, at 5:39 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= > wrote:

 

OLD:

RSU: Road = Side Unit. An IP router equipped with, or connected to, at
least one = interface that is 802.11 and that is an interface that
operates in = OCB mode.


A = comment was made stating that an RSU is not a router, and that an = RSU
may be connected to a router via an interface, e.g. Ethernet, to = access
the infrastructure if required.

But I think that some = Road Side Units are indeed IP routers and they
access the = infrastructure and the Internet.  This is an important = point
when using the IP protocol - be connected.

I think I = keep that text that way at this time.

End = issue.

 

Alex:

 

Some RSUs will be routers, but others will not. =  For example, an RSU that sends messages to vehicles about foggy = conditions does not need to be a router.  I think the definition = should allow both cases.

 

Russ

 

------=_NextPart_000_022F_01D2CFF6.2BCDD5A0-- From nobody Mon May 22 06:51:01 2017 Return-Path: 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 E35A6127876 for ; Mon, 22 May 2017 06:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 SbOcCQhQ81zW for ; Mon, 22 May 2017 06:50:58 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (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 A603F1292D3 for ; Mon, 22 May 2017 06:50:58 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id 130so12315924ybl.3 for ; Mon, 22 May 2017 06:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=lyy9t5/6OkSQWZXbKk0l83nPPFr9rLqBKA8LAhuMs1s=; b=lLjdAiO9pz2ZUYp4HxSPpR6GRuEDORdA2aMjTBZj55v4+g3/gyrMhhGee1Q6Y3Rboy xAP1DlD6oOlwZ3BHMBG6IaZgVQxP5rMPCLz3gFjuLiQTbV+HmY/Sz1vHWNDpKR92UwU7 W2IOr3dd36ShQ3q8UKiBSDZhR+tXb3YIKWW3+C5itGfMWv2SbK2Uo5FfQi006KLuX1Of Hx0GYXU5p6E25GVKjAFxyJcRy4ue52x8aUCM+2Zkx+oi2ylWQfxsRoRF4P1hQKlTJeIa ggxqTvic3WJMJSfD+3E9EY+Ni9G/0jwiWlKtooGuFtnWyRd23HVzceAFRD1NFDZ7i3z5 ++6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=lyy9t5/6OkSQWZXbKk0l83nPPFr9rLqBKA8LAhuMs1s=; b=DJPa1hOC7FSzpKXvh/4ssk1eDj62yn9VVrcDkEA0V+zschwKjBx0AEdxdKc+BkRJ+Z Hcxv1LM7nu+Mejc7D/Uos4PQEeVs31xbybeGrPoMGeD1E33o0hpp64069ycxpw+szq4L O4YVdUrBHmCjUhISaOf9uvr3iCbvtY/lR+n1BRKVslvHI+SfxEiAbnBPEiq7DxPPD9ia uOq+TKX/p9hKtaHoiipyeLSJRYQc2B8WklDWlX0Hq5x9w2sqw03yF16wB442Rs/W0RGt 53i2WiKjd/kZX2X/hyd110kcsh7OzyXLvBtmAXmbwbGA1ViVNdYIN09Z4sWCEVzkFcc2 Dxkw== X-Gm-Message-State: AODbwcCSn8ZIKY5rkhcGkvttLM+v2LPq7v7Rovz3OScirEC3u40V+vsv 4+Ls1M63R4LCaZRgGY+q1A3uJ6aU+Avw X-Received: by 10.37.43.199 with SMTP id r190mr5470431ybr.118.1495461057940; Mon, 22 May 2017 06:50:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.65.69 with HTTP; Mon, 22 May 2017 06:50:57 -0700 (PDT) From: Michelle Wetterwald Date: Mon, 22 May 2017 15:50:57 +0200 Message-ID: To: Alexandre Petrescu Cc: "its@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1358f4226a2905501d29c0" Archived-At: Subject: Re: [ipwave] minor textual issues on channels 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 13:51:00 -0000 --94eb2c1358f4226a2905501d29c0 Content-Type: text/plain; charset="UTF-8" Hi Alex, Regarding the new suggested text below, I would rather re-phrase it as: NEW2: Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on which 802.11a/b/g/n runs; this prohibition may be explicit at higher layer protocols providing services to the application; these higher layer protocols and prohibition are specified in related specifications, e.g., in IEEE 1609 documents. National or regional specifications and regulations need to be considered as well. -- This would not restrict to one set of specifications and allow a higher coverage of the issue. Moreover, it is future-proof and in line with what was discussed during the meeting in Chicago. Best, Michelle 2017-05-18 11:39 GMT+02:00 Alexandre Petrescu : > > > OLD: > >> Prohibition of IPv6 on some channels relevant for the PHY of IEEE >> 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on >> which 802.11a/b/g/n runs; at the time of writing, this prohibition is >> explicit in IEEE 1609 documents. >> > > It was suggested that this is not a PHY prohibition, but rather a higher > layer protocols providing services to the application. > > As such the new text is the following: > > NEW: > >> Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, >> as opposed to IPv6 not being prohibited on any channel on which >> 802.11a/b/g/n runs; at the time of writing, this prohibition is >> explicit at higher layer protocols providing services to the >> application; these higher layer protocols are specified in IEEE 1609 >> documents. >> > > End issue. > > > -- Michelle Wetterwald michelle.wetterwald@gmail.com --94eb2c1358f4226a2905501d29c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,

Regarding the new s= uggested text below, I would rather re-phrase it as:
NEW2:
<= div>Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB,=C2= =A0 as opposed to IPv6 not being prohibited on any channel on which=C2=A0 8= 02.11a/b/g/n runs; this prohibition may be explicit at higher layer protoco= ls providing services to the=C2=A0application; these higher layer protocols= and prohibition are specified in related specifications, e.g., in IEEE 160= 9 documents. National or regional specifications and regulations=C2=A0need = to be considered as well.
--
This would not restrict to= one set of specifications and allow a higher coverage of the issue. Moreov= er, it is future-proof and in line with what was discussed during the meeti= ng in Chicago.

Best, Michelle

=

2017-05-18 11:39 = GMT+02:00 Alexandre Petrescu <alexandre.petrescu@gmail.com&= gt;:


OLD:
Prohibition of IPv6 on some channels relevant for the PHY of IEEE
802.11-OCB, as opposed to IPv6 not being prohibited on any channel on
which 802.11a/b/g/n runs; at the time of writing, this prohibition is
explicit in IEEE 1609 documents.

It was suggested that this is not a PHY prohibition, but rather a higher layer protocols providing services to the application.

As such the new text is the following:

NEW:
Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB,
as opposed to IPv6 not being prohibited on any channel on which
802.11a/b/g/n runs; at the time of writing, this prohibition is
explicit at higher layer protocols providing services to the
application; these higher layer protocols are specified in IEEE 1609
=C2=A0documents.

End issue.





--
--94eb2c1358f4226a2905501d29c0-- From nobody Mon May 29 08:54:35 2017 Return-Path: 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 11E8A129ACC for ; Mon, 29 May 2017 08:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.367 X-Spam-Level: ** X-Spam-Status: No, score=2.367 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 3WQ9NtqcI5ZQ for ; Mon, 29 May 2017 08:54:32 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 896BE129AC6 for ; Mon, 29 May 2017 08:54:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v4TFsTEd056690; Mon, 29 May 2017 17:54:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 76025205791; Mon, 29 May 2017 17:54:29 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5D27320574A; Mon, 29 May 2017 17:54:29 +0200 (CEST) Received: from [132.166.84.45] ([132.166.84.45]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4TFsS4k027402; Mon, 29 May 2017 17:54:28 +0200 To: Rex Buddenberg , Russ Housley References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> <1495131116.2400.9.camel@gmail.com> Cc: "its@ietf.org" From: Alexandre Petrescu Message-ID: <785b7136-17b1-0915-e860-b67fbfbc427b@gmail.com> Date: Mon, 29 May 2017 18:54:27 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1495131116.2400.9.camel@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 15:54:34 -0000 Rex, Le 18/05/2017 à 20:11, Rex Buddenberg a écrit : [...] > Suggestion. Would a standards-track RFC titled 'Requirements for > Road Side Units' make sense? Not unlike the old RFC1812 I think it can make sense to have a separate document listing the requirements for Road-Sode Units. I agree with you that some characteristics of IP RSUs are: - there is huge difference between the radio interfaces and the wired interfaces situated on an RSU; - some RSUs may provide Internet service like DNS, and other IP presence indication like RA or DHCP. - some RSUs may provide application-layer services like POI broadcast, or charge spot information, or time info. - some RSUs may connect to the Internet at large. Alex From nobody Mon May 29 08:56:25 2017 Return-Path: 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 14094129AD1 for ; Mon, 29 May 2017 08:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.367 X-Spam-Level: ** X-Spam-Status: No, score=2.367 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 CPaDhDfVMufg for ; Mon, 29 May 2017 08:56:23 -0700 (PDT) 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 9D4BC129AD0 for ; Mon, 29 May 2017 08:56:23 -0700 (PDT) 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 v4TFuL3b009460 for ; Mon, 29 May 2017 17:56:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E5402205841 for ; Mon, 29 May 2017 17:56:20 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B72BF205829 for ; Mon, 29 May 2017 17:56:20 +0200 (CEST) Received: from [132.166.84.45] ([132.166.84.45]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4TFuJcP012193 for ; Mon, 29 May 2017 17:56:20 +0200 To: its@ietf.org References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> <022e01d2d017$b2dd04a0$18970de0$@gmail.com> From: Alexandre Petrescu Message-ID: <4e3e209f-6f96-ab6c-d300-6d7296e41c4d@gmail.com> Date: Mon, 29 May 2017 18:56:18 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <022e01d2d017$b2dd04a0$18970de0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 15:56:25 -0000 Franois, Some RSUs, including in America, may need to be securely connected to the Internet. Some not. When connected to the Internet, and if they are not Routers, they may induce some inefficiencies, break the Internet model (like bidirectional reachability), and other risks; it depends how it is done. There is now an updated RSU definition in the upcoming -03 draft. Alex Le 18/05/2017 22:45, Franois Simon a crit : > In the US, RSUs ARE NOT ROUTERS. There are logical boundaries between > RSU and devices accessing the infrastructure (when required): > > > > > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Russ Housley > *Sent:* Thursday, May 18, 2017 9:34 AM > *To:* Alexandre Petrescu > *Cc:* its@ietf.org > *Subject:* [ipwave] RSU minor textual issue > > > > > > On May 18, 2017, at 5:39 AM, Alexandre Petrescu > > > wrote: > > > > OLD: > > RSU: Road Side Unit. An IP router equipped with, or connected to, at > least one interface that is 802.11 and that is an interface that > operates in OCB mode. > > > A comment was made stating that an RSU is not a router, and that an RSU > may be connected to a router via an interface, e.g. Ethernet, to access > the infrastructure if required. > > But I think that some Road Side Units are indeed IP routers and they > access the infrastructure and the Internet. This is an important point > when using the IP protocol - be connected. > > I think I keep that text that way at this time. > > End issue. > > > > Alex: > > > > Some RSUs will be routers, but others will not. For example, an RSU > that sends messages to vehicles about foggy conditions does not need to > be a router. I think the definition should allow both cases. > > > > Russ > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Mon May 29 08:56:47 2017 Return-Path: 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 3AADE129AD1 for ; Mon, 29 May 2017 08:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.367 X-Spam-Level: ** X-Spam-Status: No, score=2.367 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 14DjQBUAt9cV for ; Mon, 29 May 2017 08:56:44 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 596F4129AD0 for ; Mon, 29 May 2017 08:56:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v4TFug3c057253; Mon, 29 May 2017 17:56:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8891C205816; Mon, 29 May 2017 17:56:42 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 71A0220580F; Mon, 29 May 2017 17:56:42 +0200 (CEST) Received: from [132.166.84.45] ([132.166.84.45]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4TFufv8012419; Mon, 29 May 2017 17:56:42 +0200 To: Russ Housley References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> Cc: "its@ietf.org" From: Alexandre Petrescu Message-ID: Date: Mon, 29 May 2017 18:56:40 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 15:56:45 -0000 Le 18/05/2017 15:33, Russ Housley a crit : > >> On May 18, 2017, at 5:39 AM, Alexandre Petrescu >> > >> wrote: >> >> OLD: >>> RSU: Road Side Unit. An IP router equipped with, or connected to, at >>> least one interface that is 802.11 and that is an interface that >>> operates in OCB mode. >> >> A comment was made stating that an RSU is not a router, and that an RSU >> may be connected to a router via an interface, e.g. Ethernet, to access >> the infrastructure if required. >> >> But I think that some Road Side Units are indeed IP routers and they >> access the infrastructure and the Internet. This is an important point >> when using the IP protocol - be connected. >> >> I think I keep that text that way at this time. >> >> End issue. > > Alex: > > Some RSUs will be routers, but others will not. For example, an RSU > that sends messages to vehicles about foggy conditions does not need to > be a router. I think the definition should allow both cases. Russ, I propose the following new definition. It allows both cases: > RSU: Road Side Unit. A computer equipped with at least one > IEEE 802.11 interface operated in OCB mode. An RSU may be > connected to the Internet, and may be equipped with additional > wired or wireless network interfaces running IP. Alex > > Russ > From nobody Mon May 29 08:57:22 2017 Return-Path: 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 45D61129AD1 for ; Mon, 29 May 2017 08:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.566 X-Spam-Level: * X-Spam-Status: No, score=1.566 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 HsAOZz-hEpIe for ; Mon, 29 May 2017 08:57:19 -0700 (PDT) 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 B47E3129AD0 for ; Mon, 29 May 2017 08:57:18 -0700 (PDT) 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 v4TFvHuQ009719 for ; Mon, 29 May 2017 17:57:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2F231205829 for ; Mon, 29 May 2017 17:57:17 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 25E0F205816 for ; Mon, 29 May 2017 17:57:17 +0200 (CEST) Received: from [132.166.84.45] ([132.166.84.45]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4TFvGdS012909 for ; Mon, 29 May 2017 17:57:16 +0200 To: its@ietf.org References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> <019201d2cff3$1d415870$57c40950$@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 29 May 2017 18:57:16 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <019201d2cff3$1d415870$57c40950$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 15:57:20 -0000 Le 18/05/2017 18:23, Franois Simon a crit : > In the US, RSUs ARE NOT ROUTERS. There are logical boundaries > between RSU and functions accessing the infrastructure (when > required): > > > > FHWA Definition: > > /1.6. Roadside Units/ > > /DSRC enables communication between vehicles and roadside equipment, > but does not/ > > /generate data necessary to provide warnings and advisories from > infrastructure to drivers. To/ > > /support V2I applications, DSRC must be integrated with existing > traffic equipment, such as/ > > /Signal Controllers and backhaul connections to Traffic Management > Centers (TMCs). DSRC/ > > /devices that serve as the demarcation component between vehicles > and other mobile devices/ > > /and existing traffic equipment will be referred to DSRC Roadside > Units (RSU) in this document./ > > / / > > /RSU - A connected device that is only allowed to operate from a > fixed position/ > > /(which may in fact be a permanent installation or from temporary/ > > /equipment brought on-site for a period of time associated with an/ > > /incident, road construction, or other event). Some RSEs may have/ > > /connectivity to other nodes or the Internet./ Franois - but this definition is not related to 802.11-OCB, right? I may suggest that that document talks 802.11-OCB in the definition of an RSU. Alex > > > > > > > > *From:* its [mailto:its-bounces@ietf.org] *On Behalf Of *Russ > Housley *Sent:* Thursday, May 18, 2017 9:34 AM *To:* Alexandre > Petrescu *Cc:* its@ietf.org *Subject:* > [ipwave] RSU minor textual issue > > > > > > On May 18, 2017, at 5:39 AM, Alexandre Petrescu > > > wrote: > > > > OLD: > > RSU: Road Side Unit. An IP router equipped with, or connected to, at > least one interface that is 802.11 and that is an interface that > operates in OCB mode. > > > A comment was made stating that an RSU is not a router, and that an > RSU may be connected to a router via an interface, e.g. Ethernet, to > access the infrastructure if required. > > But I think that some Road Side Units are indeed IP routers and they > access the infrastructure and the Internet. This is an important > point when using the IP protocol - be connected. > > I think I keep that text that way at this time. > > End issue. > > > > Alex: > > > > Some RSUs will be routers, but others will not. For example, an RSU > that sends messages to vehicles about foggy conditions does not need > to be a router. I think the definition should allow both cases. > > > > Russ > > > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Mon May 29 08:57:46 2017 Return-Path: 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 207B2129ADA for ; Mon, 29 May 2017 08:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.667 X-Spam-Level: * X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 zvvoWPnkwb2L for ; Mon, 29 May 2017 08:57:43 -0700 (PDT) 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 3DEF5129AD0 for ; Mon, 29 May 2017 08:57:43 -0700 (PDT) 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 v4TFveQh042381; Mon, 29 May 2017 17:57:40 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 99110205834; Mon, 29 May 2017 17:57:40 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8669320581D; Mon, 29 May 2017 17:57:40 +0200 (CEST) Received: from [132.166.84.45] ([132.166.84.45]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4TFvb8Z013073; Mon, 29 May 2017 17:57:38 +0200 To: John Kenney , =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= References: <13CE99A5-4B32-472A-B793-3ADC2E530409@vigilsec.com> <009601d2cfde$ad5abce0$081036a0$@eurecom.fr> Cc: Russ Housley , "its@ietf.org" From: Alexandre Petrescu Message-ID: <4484e874-d41d-50c6-b2f2-6bb4e1d182ef@gmail.com> Date: Mon, 29 May 2017 18:57:37 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] MAC Address minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 15:57:45 -0000 Le 18/05/2017 à 16:50, John Kenney a écrit : > Hello All: > > I do not agree with the statement that "there are strong privacy > concerns". I suggest changing "concerns" to "requirements". Ok, changed to "requirements". Alex > > I think stating that there are strong concerns conveys a sense of this > being a big unsolved problem. For the DSRC/ITS-G5 community this is not > the case. Privacy protection, including careful avoidance of PII in > messages, pseudonymous certificates, and frequent identifier > randomization, has been designed into DSRC/ITS-G5 from day 1. > > The requirements are cross-layer and systemic, but also not universal > for OCB (e.g. RSUs are licensed for a site and do not need privacy > protection), so 802.11 would not have been the best place to address > them. Stating that they are not addressed in 802.11 sounds to me like it > was an oversight or omission. It was not. > > I agree with noting that some standards already address privacy > protection, but I don't think it helps to list standards (like 802.11) > that do not. > > I hope these comments are helpful. > > Best Regards, > John > > > > > > On Thu, May 18, 2017 at 6:57 AM, Jérôme Härri > wrote: > > Dear Russ, Dear Alex,____ > > __ __ > > Indeed, and so does ETSI ITS. So, we can keep what is there, and > maybe add something like: ____ > > __ __ > > (…)While the 802.11-OCB standard does not specify anything > particular with respect to MAC addresses, higher layer stack > architecture, such as IEEE 1609 and ETSI ITS does impose MAC > requirements. Accordingly, similar requirements might be expected or > required when operating IPv6 over 802.11-OCB without these > architectures (…) ____ > > __ __ > > Do we need to define what we mean by ‘MAC requirements’? ____ > > __ __ > > Best Regards,____ > > __ __ > > Jérôme____ > > __ __ > > __ __ > > __ __ > > *From:*its [mailto:its-bounces@ietf.org > ] *On Behalf Of *Russ Housley > *Sent:* Thursday 18 May 2017 15:44 > *To:* Alexandre Petrescu > *Cc:* its@ietf.org > *Subject:* [ipwave] MAC Address minor textual issue____ > > __ __ > > __ __ > > On May 18, 2017, at 5:39 AM, Alexandre Petrescu > > wrote:____ > > __ __ > > OLD: > > ____ > > In vehicular communications using 802.11-OCB links, there are strong > privacy concerns with respect to addressing. While the 802.11-OCB > standard does not specify anything in particular with respect to MAC > addresses____ > > > It has been suggested that there is something to think about > here, which > may affect the above statement: there is at least one country > where the > vehicle|driver information, be it physical or electronic, must be > allowed access by law enforcement if so required. > > This is noted. I suggest we discuss this separately. > > At this time I do not modify this text. > > End issue.____ > > __ __ > > IEEE 1609 does impose MAC address requirements. Is this the right > place to call that out?____ > > __ __ > > Russ____ > > __ __ > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > John Kenney > Director and Principal Researcher > Toyota InfoTechnology Center, USA > 465 Bernardo Avenue > Mountain View, CA 94043 > Tel: 650-694-4160. Mobile: 650-224-6644 From nobody Mon May 29 08:58:05 2017 Return-Path: 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 25942129AD0 for ; Mon, 29 May 2017 08:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.367 X-Spam-Level: *** X-Spam-Status: No, score=3.367 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 gAfyFvuPUiOU for ; Mon, 29 May 2017 08:58:02 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 B1671129AD3 for ; Mon, 29 May 2017 08:57:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v4TFvt9l057718; Mon, 29 May 2017 17:57:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7FACA205834; Mon, 29 May 2017 17:57:55 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 723D820581D; Mon, 29 May 2017 17:57:55 +0200 (CEST) Received: from [132.166.84.45] ([132.166.84.45]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4TFvrG7013168; Mon, 29 May 2017 17:57:54 +0200 To: Michelle Wetterwald References: Cc: "its@ietf.org" From: Alexandre Petrescu Message-ID: Date: Mon, 29 May 2017 18:57:53 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] minor textual issues on channels 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 15:58:03 -0000 Le 22/05/2017 à 15:50, Michelle Wetterwald a écrit : > Hi Alex, > > Regarding the new suggested text below, I would rather re-phrase it > as: NEW2: Prohibition of IPv6 on some channels relevant for IEEE > 802.11-OCB, as opposed to IPv6 not being prohibited on any channel > on which 802.11a/b/g/n runs; this prohibition may be explicit at > higher layer protocols providing services to the application; these > higher layer protocols and prohibition are specified in related > specifications, e.g., in IEEE 1609 documents. National or regional > specifications and regulations need to be considered as well. Ok, I added that "national or regional...". I would like to let you know that the national and regional specs where I live do not make statements with respect to IPv6 (neither prohibiting nor allowing IPv6). However, the server where these specs are stored is under maintenance since serveral months and it's hard to point to them. ("e-spectre"). Also these national/regional specs are often superseded by supra-national specs which seem to be overseen by ETSI ITS, which does make such statements with respect to IPv6. Alex -- This > would not restrict to one set of specifications and allow a higher > coverage of the issue. Moreover, it is future-proof and in line with > what was discussed during the meeting in Chicago. > > Best, Michelle > > > 2017-05-18 11:39 GMT+02:00 Alexandre Petrescu > >: > > > > OLD: > > Prohibition of IPv6 on some channels relevant for the PHY of IEEE > 802.11-OCB, as opposed to IPv6 not being prohibited on any channel > on which 802.11a/b/g/n runs; at the time of writing, this prohibition > is explicit in IEEE 1609 documents. > > > It was suggested that this is not a PHY prohibition, but rather a > higher layer protocols providing services to the application. > > As such the new text is the following: > > NEW: > > Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, as > opposed to IPv6 not being prohibited on any channel on which > 802.11a/b/g/n runs; at the time of writing, this prohibition is > explicit at higher layer protocols providing services to the > application; these higher layer protocols are specified in IEEE 1609 > documents. > > > End issue. > > > > > > -- Michelle Wetterwald michelle.wetterwald@gmail.com > From nobody Mon May 29 09:01:28 2017 Return-Path: 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 3CEF2129AD0 for ; Mon, 29 May 2017 09:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.667 X-Spam-Level: * X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 Oe1jQgo7N1yQ for ; Mon, 29 May 2017 09:01:26 -0700 (PDT) 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 F26F6126CD6 for ; Mon, 29 May 2017 09:01:25 -0700 (PDT) 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 v4TG1Odq043297 for ; Mon, 29 May 2017 18:01:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6EFA5205791 for ; Mon, 29 May 2017 18:01:24 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5C6F2205661 for ; Mon, 29 May 2017 18:01:24 +0200 (CEST) Received: from [132.166.84.45] ([132.166.84.45]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4TG1MX3015654 for ; Mon, 29 May 2017 18:01:23 +0200 From: Alexandre Petrescu To: "its@ietf.org" Message-ID: <176ca438-2b76-3be0-c61b-23eb13066c2b@gmail.com> Date: Mon, 29 May 2017 19:01:22 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] IPv6-per-channel prohibition 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 16:01:27 -0000 Hi, During the last IPWAVE meeting at IETF Chicago we discussed about this IPv6-per-channel prohibition paragraph. This new paragraph below reflects that discussion, and is part of -03. I must say I do not agree with this text, but this seems to be what the room said (minutes, emails and video of the session). The reason I disagree with it is that in France the national regulator does not prohibit IPv6 on any channel. It is ETSI ITS who prohibits it. ETSI ITS is a supra-national body (European organisation). But I put this text below in -03, according to our meeting. Alex > o Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, > as opposed to IPv6 not being prohibited on any channel on which > 802.11a/b/g/n runs: > > * Some channels are reserved for safety communications; the IPv6 > packets should not be sent on these channels. > > * At the time of writing, the prohibition is explicit at higher > layer protocols providing services to the application; these > higher layer protocols are specified in IEEE 1609 documents. > > * National or regional specifications and regulations specify the > use of different channels; these regulations must be followed. From nobody Mon May 29 10:18:25 2017 Return-Path: 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 B7370128D19 for ; Mon, 29 May 2017 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 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_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 QqGxOyRz1fSg for ; Mon, 29 May 2017 10:18:22 -0700 (PDT) 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 6A810127444 for ; Mon, 29 May 2017 10:18:22 -0700 (PDT) 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 v4THIK7M010106 for ; Mon, 29 May 2017 19:18:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A0FC6205A14 for ; Mon, 29 May 2017 19:18:20 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 90C65205A09 for ; Mon, 29 May 2017 19:18:20 +0200 (CEST) Received: from [132.166.84.66] ([132.166.84.66]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4THII4L024340 for ; Mon, 29 May 2017 19:18:19 +0200 To: its@ietf.org References: <1491334470.3575.9.camel@it.uc3m.es> <049601d2af83$cfa0e390$6ee2aab0$@gmail.com> From: Alexandre Petrescu Message-ID: <63add389-0620-c4f7-786d-8f3103c6b444@gmail.com> Date: Mon, 29 May 2017 20:18:17 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <049601d2af83$cfa0e390$6ee2aab0$@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] Draft minutes of IPWAVE@IETF98 available 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 17:18:24 -0000 Mr. Simon, HEre are comments to your comments. > - Add the 802.11 Trailer (Frame Check Sequence) to the Ethernet > Adaptation Layer. [Fygs: Would it be CRC and not FCS?] It is called Frame Check Sequence by Wireshark. The CRC (Cyclic Redundancy Check) is called "Checksum" in ICMP headers if I am not wrong. > * Michelle Wetterwald (MW): some channels are used for safety message > only so change the text accordingly (without indicating specifically > which channels prohibit IPv6. [Fygs: From the 802.11 OCB MAC and PHY > there is no restrictions on IPv6 on any channel] I agree with you - in 802.11 OCB there is no restriction of IPv6 on any channel. > * BM: channel utilization is national-specific and there are various geos. So propose to use the term ‘national channels’ and refer to national-specific channel utilization docs. > [Fygs: why not use the recognized internation term of "bearer channels"?] If this term "bearer channels" is to be used, it should be in a separate document. > * Carlos J. Bernardos (CB): prefers the term 'Router'. > * Andrew: yes, I like ‘Router’ here. > Fygs: [Fygs: RSU as defined does not support router functions; period] See the new definition of RSU in -03 draft. It includes all what was said on this definition. > * BM: AP should be changed to STA (in ad-hoc mode). > [Fygs: OCB is not ad-hoc mode] I agree. But loook at the figure comparing the Infrastructure mode to OCB mode, in draft -03. > * BM: 1609.2 does not exist anymore. > [Fygs: 1609.2 IS ALIVE AND LIVING IN 1609 SERIES - Security] That was an error in the minutes. Alex Le 07/04/2017 à 12:46, François Simon a écrit : > Mr. Jaehoon, > > > > Please, find my comments on the minutes attached. I was not present > at the meeting. Also find additional comments below. > > > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *Mr. Jaehoon > Paul Jeong *Sent:* Wednesday, April 05, 2017 11:08 PM *To:* Michelle > Wetterwald *Cc:* Russ Housley > ; its@ietf.org; CARLOS JESUS BERNARDOS CANO > *Subject:* Re: [ipwave] Draft minutes of > IPWAVE@IETF98 available > > > > Hi all, > > Though IEEE 802.2 LLC is not used by WAVE Protocol Stack, > > LLC is part of WAVE Networking Services specified by IEEE > 1609.3.Fygs:– Per OSI, LLC is a sub-layer of the Data Link Layer (it > happen to be specified in 1609.3.] > > That is, WAVE LLC is slightly different from IEEE 802.2 LLC.– [Fygs – > Is not “slightly” it is different” the LLC in US for 5.9 GHz is > /EtherType Protocol Discrimination (EPD]./ > > > > The functions of Networking Services in IEEE 1609.3 are as follows: > > > > 1. Data Plane at WAVE Protocol Stack > > - Logical Link Control (LLC)– [Fygs: EPD] > > - IPv6, and transport layer protocols (e.g., TCP and UDP) > > - WAVE Short Message Protocol (WSMP) Transport protocols/Networking > protocols > > > > 2. Management Plane at WAVE Management Entity (WME) > > - Service requests and channel access assignment > > - WAVE Service Advertisement monitoring > > - IPv6 configuration > > - MIB maintenance[Fygs: MIBs are within the Layer Management Entity > (LME) associated with EACH layer] > > - [Fygs: Security is included in the System > Management Entity (SME)] > > > > Thanks. > > > > Best Regards, > > Paul > > > > > > On Wed, Apr 5, 2017 at 7:22 PM, Michelle Wetterwald > > wrote: > > Hi Carlos, > > > > Thank you very much for these minutes. > > > > I would like to ask for update on the notes about the survey > discussion. > > > > I think it was said that "802.2 does not exist anymore". rather than > "1609.2 does not exist anymore." > > > > Best regards, > > Michelle > > > > > > 2017-04-04 21:34 GMT+02:00 Carlos Jesús Bernardos Cano > >: > > Hi, > > We've just posted the minutes: > > https://www.ietf.org/proceedings/98/minutes/minutes-98-ipwave-01 > > Please send corrections/comments by Friday, Apr 7th. > > Thanks a lot to Danny and Bob for taking the minutes! > > Cheers, > > Carlos & Russ > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > -- > > Michelle Wetterwald > > michelle.wetterwald@gmail.com > > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > -- > > =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant > Professor Department of Software Sungkyunkwan University Office: > +82-31-299-4957 Email: jaehoon.paul@gmail.com > , pauljeong@skku.edu > Personal Homepage: > http://iotlab.skku.edu/people-jaehoon-jeong.php > > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From nobody Mon May 29 10:32:39 2017 Return-Path: X-Original-To: its@ietf.org Delivered-To: its@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E11112941D; Mon, 29 May 2017 10:32:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: its@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149607915106.30200.9372117873776438648@ietfa.amsl.com> Date: Mon, 29 May 2017 10:32:31 -0700 Archived-At: Subject: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-03.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.22 List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 17:32:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Wireless Access in Vehicular Environments of the IETF. Title : Transmission of IPv6 Packets over IEEE 802.11 Networks in mode Outside the Context of a Basic Service Set (IPv6-over-80211ocb) Authors : Alexandre Petrescu Nabil Benamar Jérôme Härri Christian Huitema Jong-Hyouk Lee Thierry Ernst Tony Li Filename : draft-ietf-ipwave-ipv6-over-80211ocb-03.txt Pages : 34 Date : 2017-05-29 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks run outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the recommended Maximum Transmission Unit size, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11 OCB networks; it portrays the layering of IPv6 on 802.11 OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. In addition, the document attempts to list what is different in 802.11 OCB (802.11p) compared to more 'traditional' 802.11a/b/g/n layers, layers over which IPv6 protocols operates without issues. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. An example of an IPv6 packet captured while transmitted over an IEEE 802.11 OCB link (802.11p) is given. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-03 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 29 10:36:29 2017 Return-Path: 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 DB468128ACA for ; Mon, 29 May 2017 10:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 SbYhrno61v95 for ; Mon, 29 May 2017 10:36:25 -0700 (PDT) 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 6B524126D73 for ; Mon, 29 May 2017 10:36:25 -0700 (PDT) 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 v4THaNIE013065 for ; Mon, 29 May 2017 19:36:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A041B205B36 for ; Mon, 29 May 2017 19:36:23 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9552F205A93 for ; Mon, 29 May 2017 19:36:23 +0200 (CEST) Received: from [132.166.84.41] ([132.166.84.41]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4THaLwg031738 for ; Mon, 29 May 2017 19:36:22 +0200 References: <149607915126.30200.14109846467837254954.idtracker@ietfa.amsl.com> To: "its@ietf.org" From: Alexandre PETRESCU Organization: CEA X-Forwarded-Message-Id: <149607915126.30200.14109846467837254954.idtracker@ietfa.amsl.com> Message-ID: <3bca282b-145b-a290-8d90-bb1bd38b185f@cea.fr> Date: Mon, 29 May 2017 20:36:21 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149607915126.30200.14109846467837254954.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020000070500090209090501" Archived-At: Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-03.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 17:36:28 -0000 This is a cryptographically signed message in MIME format. --------------ms020000070500090209090501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello to participants to IPWAVE WG, This -03 version of the IPv6-over-80211ocb draft addresses all comments=20 we had recently on the list, in the Chicago meeting, and in private. This is the changelog: o Keep the previous text on multiple addresses, so remove talk about= MIP6, NEMOv6 and MCoA. o Clarified that a 'Beacon' is an IEEE 802.11 frame Beacon. o Clarified the figure showing Infrastructure mode and OCB mode side= by side. o Added a reference to the IP Security Architecture RFC. o Detailed the IPv6-per-channel prohibition paragraph which reflects= the discussion at the last IETF IPWAVE WG meeting. o Added section "Address Mapping -- Unicast". o Added the ".11 Trailer" to pictures of 802.11 frames. o Added text about SNAP carrying the Ethertype. o New RSU definition allowing for it be both a Router and not necessarily a Router some times. o Minor textual issues. Alex -------- Message transf=C3=A9r=C3=A9 -------- Sujet : New Version Notification for=20 draft-ietf-ipwave-ipv6-over-80211ocb-03.txt Date : Mon, 29 May 2017 10:32:31 -0700 De : internet-drafts@ietf.org Pour : Nabil Benamar , Christian Huitema=20 , Jong-Hyouk Lee , J=C3=A9r=C3=B4= me=20 H=C3=A4rri , Alexandre Petrescu=20 , Tony Li , Thierry Ernst=20 , ipwave-chairs@ietf.org A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-03.txt has been successfully submitted by Alexandre Petrescu and posted to the IETF repository. Name: draft-ietf-ipwave-ipv6-over-80211ocb Revision: 03 Title: Transmission of IPv6 Packets over IEEE 802.11 Networks in mode=20 Outside the Context of a Basic Service Set (IPv6-over-80211ocb) Document date: 2017-05-29 Group: ipwave Pages: 34 URL:=20 https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb= -03.txt Status:=20 https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ Htmlized:=20 https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-03 Htmlized:=20 https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211oc= b-03 Diff:=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipwave-ipv6-over-80211ocb-= 03 Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks run outside= the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the recommended Maximum Transmission Unit size, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11 OCB networks; it portrays the layering of IPv6 on 802.11 OCB similarly to other known 802.11 and Ethernet layers - by using an Ethernet Adaptation Layer. In addition, the document attempts to list what is different in 802.11 OCB (802.11p) compared to more 'traditional' 802.11a/b/g/n layers, layers over which IPv6 protocols operates without issues. Most notably, the operation outside the context of a BSS (OCB) has impact on IPv6 handover behaviour and on IPv6 security. An example of an IPv6 packet captured while transmitted over an IEEE 802.11 OCB link (802.11p) is given. =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms020000070500090209090501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC C6QwggWgMIIEiKADAgECAgI5MDANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJGUjEMMAoG A1UECgwDQ0VBMRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwCQUMxIDAeBgNV BAMMF0NFQSBBQyBVdGlsaXNhdGV1ciAyMDIxMB4XDTE1MDExNTEzNDI1MFoXDTE4MDExNTEz NDI1MFowVTELMAkGA1UEBhMCRlIxDDAKBgNVBAoMA2NlYTEUMBIGA1UECwwLVXRpbGlzYXRl dXIxIjAgBgNVBAMMGVBFVFJFU0NVIEFsZXhhbmRyZSAyMjIwNDAwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDAmIx5QVYSXlLNLE/D9SySZPKHBBP0G9NgtMYKQuYWODXAkmI8 b4xp1YniPStCcyPauXfVn+ySgAr4SX/oWwB2kTPISYWt8FQ7eNdXH7AM7cPbLQh0IYwHUWAf 6Mzakx+/oajWhYv8NvLhVnb7qjGmWObdLUcOgJOSYAzHSVPQRnRB9A9Fw7NzNMi/9wqGwmJz maBhaDL/iMRZEDnllsnGFHZr1h6N8srFER7nEJVS/CDTIlZwBFO6DXScy1mq8ZzcD3hNIOV1 2PmhiW7dPfeE7BDjvDS+Fb0PQB7R4TCQo4J7+Nm4Cca+U4cloclzpznWJZWD1AZw8CdwXqNM /tYXAgMBAAGjggJqMIICZjAdBgNVHQ4EFgQUonHmXxWzWW2Z52J+svVY7gn56jUwHwYDVR0j BBgwFoAU+4DifDNZ7hKDQxL+ys+vHYZdUJgwgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEG AjCBqzAlBggrBgEFBQcCARYZaHR0cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUH AgIwdTANFgNDRUEwBgIBAgIBABpkVm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUg ZGUgY2VydGlmaWNhdGlvbiBhdmFudCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3 d3ctaWdjLmNlYS5mcjARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgSwMCQGA1Ud EQQdMBuBGWFsZXhhbmRyZS5wZXRyZXNjdUBjZWEuZnIwTQYDVR0fBEYwRDBCoECgPoY8aHR0 cDovL2NybC1hYy11dGlsaXNhdGV1ci5jZWEuZnIvY3JsL2FjLXV0aWxpc2F0ZXVyLTIwMjEu Y3JsMHMGCWCGSAGG+EIBDQRmFmRWb3VzIGRldmV6IGFjY2VwdGVyIGxhIHBvbGl0aXF1ZSBk ZSBjZXJ0aWZpY2F0aW9uIGF2YW50IGQndXRpbGlzZXIgY2UgY2VydGlmaWNhdCwgY2YuIHd3 dy1pZ2MuY2VhLmZyMEwGCCsGAQUFBwEBBEAwPjA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy1p Z2MuY2VhLmZyL2FjL2FjLXV0aWxpc2F0ZXVyLTIwMjEuY2VyMA0GCSqGSIb3DQEBBQUAA4IB AQB+wFDqbtylGRYrv0BVuBjf9ZHHixvEVOz1SMyR+9671bbqPylE3xAEENJ9Obz+wI/hTsrL R0R+UQuMutmU4N2y84YbdWirtCneyiLrS4aG8OkOl0cKdQubj+ptcXHWl0WWdB9urwYjBaZ4 A9Z+/VqJQBz1B3ci1u5Kz4P1HpfILJnjxaAdEvt6xepyshPCms8jEcEKz4OggYAQFKzJoIZx QPB2yBRc8aJZW+Vqb/W5i7Ow+2oaUTw2RQ7Iv84AvBMyqSFFU//tsgTED4QmIL3+bWcqrG4q rkFNeuDnQr5neJ2sR3s2kPSCZYn2d1W6BjQ67flz/V6jBEgkshD0TttRMIIF/DCCA+SgAwIB AgIBAjANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYD VQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwCQUMxGzAZBgNVBAMMEkNFQSBBQyBSYWNp bmUgMjA0MTAeFw0xMTExMjgxMzU0MzVaFw0yMTEyMDExMzU0MzVaMGMxCzAJBgNVBAYTAkZS MQwwCgYDVQQKDANDRUExFzAVBgNVBAsMDjAwMDIgNzc1Njg1MDE5MQswCQYDVQQLDAJBQzEg MB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMjEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCc/G4Oogc3nYQybY/irx22kJi+TuA6EqkXjtNRcPYfRi619L7ikuZNsVfa fBWp/1KQD6VdW4cBzNYghKyrUkdPRhGQ0xLNQhTyVFn3QuJIjyWEpl9IESc2ctzme6NIF4lG axXvlwve+UCt9v4Xuk1pUcSAt2AJ9PdTNNinJQBNprOTh6Twq30i4YcTxH99X94AWfiYZRvm /tFE38oK6fD7y8S6/xW90QuCmMHpTUtmKt8l7t6PAwNTx8uFayGFCCfeMAbLIcaXvKZzuBpA XpKXr7zvGTu/OsdNKNyzxvF7kon/2kDA4dxXAp/MTDIjaARBFjVVfs+/esdROUsLTqUDAgMB AAGjggG+MIIBujAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT7gOJ8M1nuEoNDEv7Kz68d hl1QmDAfBgNVHSMEGDAWgBSgEYn4mr+mhLEpBzdTQe2XlUJ7HTCByAYDVR0gBIHAMIG9MIG6 BgorBgEEAeBgAQYCMIGrMCUGCCsGAQUFBwIBFhlodHRwOi8vd3d3LWlnYy5jZWEuZnIvcGMv MIGBBggrBgEFBQcCAjB1MA0WA0NFQTAGAgECAgEAGmRWb3VzIGRldmV6IGFjY2VwdGVyIGxh IHBvbGl0aXF1ZSBkZSBjZXJ0aWZpY2F0aW9uIGF2YW50IGQndXRpbGlzZXIgY2UgY2VydGlm aWNhdCwgY2YuIHd3dy1pZ2MuY2VhLmZyMA4GA1UdDwEB/wQEAwIBBjBDBgNVHR8EPDA6MDig NqA0hjJodHRwOi8vY3JsLWFjLXJhY2luZS5jZWEuZnIvY3JsL2FjLXJhY2luZS0yMDQxLmNy bDBHBggrBgEFBQcBAQQ7MDkwNwYIKwYBBQUHMAKGK2h0dHA6Ly93d3ctaWdjLmNlYS5mci9h Yy9hYy1yYWNpbmUtMjA0MS5jZXIwDQYJKoZIhvcNAQEFBQADggIBAMCbWqmZRh1h4klw5m6b t2okNIorESBuwWQ3woAdLb9PsVUW70mLwwzvmf/++lphdYn6cWVHxXNn707DPz6XG/IsRfBA UWTshe0QmrGx5xpVvpbrU9gQVWGwLugF6rYgZ9B7ELOxQp/Ac03nheADYevePfbZ/2lbIJGt sn7/8lF5JKENkhvAb2+bXZZsyvy59W8xc2QsDUddemHKz9ZtggGeToG0LDT78SkSPbE3RwP+ Q0VXt7QYo8vhmV43mp+UrZeI4JUQibWXvIOp6avOf1zfpbm9RhLa501puoKaVaeHkcxi46je Bv4znpwQEi5I9yS6Hekivh9hofq52lIQJ+UNe2+QYGAzJmuI62Buto1iwWmBm8Qe+uIpZnRU /O/tFgw2Gm2fbDdtT1tbaZdJgbI40D4DpUGBbf1kkbn1G5i0bkDUZfUk18w1aa5d4sSC1tLU xAZqhKe1iA7iLeweZhqLzmylFCL5BlJrVh+PNXwUYhOOLkiE7/uC/ncog+K5J2HnzZfX2Ejh haeBCTxeQBvmm/omrzWerid6FLG/jlBjqkpoALNucTRfDB6YmspYqOY8sU8yiLKt/v6xpxb4 AI3FEheIzTz/bgCNNbQv3Be1TpdKI8cc40HG72jK/s7sbbKMf1SRtTxDZGGmarjaWtxWo6S9 uFc2ZX4lyqYbNnh3MYIDZTCCA2ECAQEwaTBjMQswCQYDVQQGEwJGUjEMMAoGA1UECgwDQ0VB MRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwCQUMxIDAeBgNVBAMMF0NFQSBB QyBVdGlsaXNhdGV1ciAyMDIxAgI5MDANBglghkgBZQMEAgEFAKCCAc0wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTI5MTczNjIxWjAvBgkqhkiG9w0B CQQxIgQgl8yuCbGPZZZhIX8byU1DlOT2CwagafQwL1VJ7nudipswbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQx azBpMGMxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExFzAVBgNVBAsMDjAwMDIgNzc1Njg1 MDE5MQswCQYDVQQLDAJBQzEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMjECAjkw MHoGCyqGSIb3DQEJEAILMWugaTBjMQswCQYDVQQGEwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYD VQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwCQUMxIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDIxAgI5MDANBgkqhkiG9w0BAQEFAASCAQApw1RRLeSsovv76xd1ECWcVBKm 7H6E8LRppOGyTS1xmY4LnF3T64yYYs9tZT9xl8Dy+iepLgEwptYyGfcAHlHOc0M1MMv6OiwU WQSBYsLqvdFFcnhKm18ckrjdikgGNl4+uJfWRDjxaOCuWltpDkK/PFYA/degJoPD5rDbVjuC 4wx2zxUJR+FQMWtP8wSPPp8vILtMWC3Y34/odbzmUt5mI9DjoUVrQJvCC6cwkMShWS2h22Y4 utMhNN7kwqbtY8UPbDJdZpBR92VctHkHttG62HG3OFG+OqlzpBiWGoW8IQIJ9b9wFWhlkV1U 0hTUip99U/vv2dY8bmpLrTectgOtAAAAAAAA --------------ms020000070500090209090501-- From nobody Mon May 29 10:44:16 2017 Return-Path: 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 F40771293FF for ; Mon, 29 May 2017 10:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.367 X-Spam-Level: ** X-Spam-Status: No, score=2.367 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 TyDpQkjKYPil for ; Mon, 29 May 2017 10:44:13 -0700 (PDT) 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 C674F1200F3 for ; Mon, 29 May 2017 10:44:12 -0700 (PDT) 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 v4THiAkV029633 for ; Mon, 29 May 2017 19:44:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 900B4205B40 for ; Mon, 29 May 2017 19:44:10 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7D3CE205995 for ; Mon, 29 May 2017 19:44:10 +0200 (CEST) Received: from [132.166.84.41] ([132.166.84.41]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v4THiAKH003869 for ; Mon, 29 May 2017 19:44:10 +0200 To: "its@ietf.org" From: Alexandre Petrescu Message-ID: <04abb104-61cf-0c6d-f195-1ea9e0367ae2@gmail.com> Date: Mon, 29 May 2017 20:44:09 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [ipwave] year 2016 for 1609.3 clause 5.5.1 and for 1609.4? 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 17:44:14 -0000 Hi, In Chicago we agreed to be more specific when referring to 1609.X documents, by citing the year. I hope this is the year 2016 correct in the following phrase. > A relevant function is described in IEEE 1609.3-2016, clause 5.5.1 > and IEEE 1609.4-2016, clause 6.7. Alex From nobody Mon May 29 16:41:14 2017 Return-Path: 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 2B98112941D for ; Mon, 29 May 2017 16:41:12 -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, HTML_MESSAGE=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 (1024-bit key) header.d=onboardsecurity.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 Nk3OcklEcUmP for ; Mon, 29 May 2017 16:41:10 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 BB6A4126B6E for ; Mon, 29 May 2017 16:41:09 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id b84so71290496wmh.0 for ; Mon, 29 May 2017 16:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+/UPB0+dCLeGnW889wqAbppiaPL32yBKr23WsekquWA=; b=XtcrXPc4dBO29oAazHK8OD/QHX1tKG27nV0OMz7JXl0xONfiTQnVshvsTMtqmOtW+2 30sxy9U+j158m44cznDruPxhq6gwtWNu+thAKkj9yWe4TNLeCbmJkndyI081qxE6Vmx/ DexLctQ9rhnS73vRy59zguD7UAhYtd4T18xe4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+/UPB0+dCLeGnW889wqAbppiaPL32yBKr23WsekquWA=; b=PnrTRhM7gSbiGGfgJy91A5KOruo6H5n7lbrgIcvV3+YHLyeXg/2LbJGHAS2ATIUmKd kfNEF+gZZa1JVpqnKT5uOK4ad4uO3la+rBLPLqFJuvRmrF33k8c+ee0LCamdBfBKnsDj MA6Eq1P+IKU1o72uD+pLSYklirvSV2SajYyv6jlSPgjxlAQdoAMoQkn/3ZKBGvq17fy/ 96C3wPFT0UIbgsY66ux8cRBjRqZz3vjphxhM5uUxqUCivDd55qwWq3FBwSbyYCako8Zd yAYD4TX5nkqECcwVfmhQTNa3ewlnrKikvfErCjwjpUf1pdA9CcxJsMJ8bsrAEBm+He5o mCRQ== X-Gm-Message-State: AODbwcB6hwtqZvMqA9pM253yFhS5msz+8hd8XNEPn3gUqc+3/YvfrV/7 zAjLlsExY9WhWibGQDJ6juDqCvBM2kHi X-Received: by 10.28.196.73 with SMTP id u70mr21832638wmf.73.1496101268123; Mon, 29 May 2017 16:41:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.10.77 with HTTP; Mon, 29 May 2017 16:40:46 -0700 (PDT) In-Reply-To: References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> From: William Whyte Date: Tue, 30 May 2017 09:40:46 +1000 Message-ID: To: Alexandre Petrescu Cc: Russ Housley , "its@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c194056a2a0af0550b238f0" Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 23:41:12 -0000 --94eb2c194056a2a0af0550b238f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alex, RSU: Road Side Unit. A computer equipped with at least one IEEE 802.11 interface operated in OCB mode. An RSU may be connected to the Internet, and may be equipped with additional wired or wireless network interfaces running IP. This doesn't cover the difference between an RSU and an OBU :-) Maybe "a computer equipped with at least one IEEE 802.11 interface operated in OCB mode, which is physically located in communications range of vehicles but is not a vehicle device itself". Cheers, William On Tue, May 30, 2017 at 1:56 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 18/05/2017 =C3=A0 15:33, Russ Housley a =C3=A9crit : > >> >> On May 18, 2017, at 5:39 AM, Alexandre Petrescu >>> > >>> wrote: >>> >>> OLD: >>> >>>> RSU: Road Side Unit. An IP router equipped with, or connected to, at >>>> least one interface that is 802.11 and that is an interface that >>>> operates in OCB mode. >>>> >>> >>> A comment was made stating that an RSU is not a router, and that an RSU >>> may be connected to a router via an interface, e.g. Ethernet, to access >>> the infrastructure if required. >>> >>> But I think that some Road Side Units are indeed IP routers and they >>> access the infrastructure and the Internet. This is an important point >>> when using the IP protocol - be connected. >>> >>> I think I keep that text that way at this time. >>> >>> End issue. >>> >> >> Alex: >> >> Some RSUs will be routers, but others will not. For example, an RSU >> that sends messages to vehicles about foggy conditions does not need to >> be a router. I think the definition should allow both cases. >> > > Russ, > > I propose the following new definition. It allows both cases: > > RSU: Road Side Unit. A computer equipped with at least one >> IEEE 802.11 interface operated in OCB mode. An RSU may be >> connected to the Internet, and may be equipped with additional >> wired or wireless network interfaces running IP. >> > > Alex > > > >> Russ >> >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --94eb2c194056a2a0af0550b238f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alex,


=C2=A0 =C2=A0 =C2=A0 =C2= =A0 RSU: Road Side Unit.=C2=A0 A computer equipped with at least one=
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 IEEE 802.11 interface operated in OCB mode.=C2=A0 An RSU = may be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 connected to the Internet, and may be equippe= d with additional
=C2=A0 =C2=A0 =C2=A0 =C2=A0 wired or wireless network interfac= es running IP.

This doesn't cover the= difference between an RSU and an OBU :-)

May= be "a=C2=A0computer equipped w= ith at least one=C2=A0IEEE 802.11 i= nterface operated in OCB mode, which is physically located in communication= s range of vehicles but is not a vehicle device itself".
<= div>
Cheers,
=
William
=

On Tue, May= 30, 2017 at 1:56 AM, Alexandre Petrescu <alexandre.petrescu@gm= ail.com> wrote:


Le 18/05/2017 =C3=A0 15:33, Russ Housley a =C3=A9crit :

On May 18, 2017, at 5:39 AM, Alexandre Petrescu
<alexa= ndre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>=
wrote:

OLD:
RSU: Road Side Unit. An IP router equipped with, or connected to, at
least one interface that is 802.11 and that is an interface that
operates in OCB mode.

A comment was made stating that an RSU is not a router, and that an RSU
may be connected to a router via an interface, e.g. Ethernet, to access
the infrastructure if required.

But I think that some Road Side Units are indeed IP routers and they
access the infrastructure and the Internet.=C2=A0 This is an important poin= t
when using the IP protocol - be connected.

I think I keep that text that way at this time.

End issue.

Alex:

Some RSUs will be routers, but others will not.=C2=A0 For example, an RSU that sends messages to vehicles about foggy conditions does not need to
be a router.=C2=A0 I think the definition should allow both cases.

 Russ,

I propose the following new definition.=C2=A0 It allows both cases:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RSU: Road Side Unit.=C2=A0 A computer equipped = with at least one
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IEEE 802.11 interface operated in OCB mode.=C2= =A0 An RSU may be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 connected to the Internet, and may be equipped = with additional
=C2=A0 =C2=A0 =C2=A0 =C2=A0 wired or wireless network interfaces running IP= .

Alex



Russ


_______________________________________________
its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its



--
=


PLEASE UPDATE YOUR ADDRESS BOOKS WIT= H MY NEW ADDRESS: wwhyte@onboardsecurity.com
--94eb2c194056a2a0af0550b238f0-- From nobody Tue May 30 07:29:57 2017 Return-Path: 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 95FD81294E7 for ; Tue, 30 May 2017 07:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IxRbk-OSpDXt for ; Tue, 30 May 2017 07:29:54 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::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 EF972126579 for ; Tue, 30 May 2017 07:29:53 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id g15so25645508wmc.2 for ; Tue, 30 May 2017 07:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=h1v+k+m1uWQopKSvjK4+gK+uGP4C6ykIgn3HuvMPfjI=; b=NguioaBs4tQVOHBSKTlzryMcGX9d3ttjbGufXYPCHMZwCn7TchjECaSvcSW6WkHgJ7 LpOzeFJEMJIxYvp+VvhA31cVm0jPJeTRzeZ2POJ0lAmvCE7YKHvZasHAJB1/9/x/+IHz Yjrcw7cbHsTRm/InXM50ASx980zdSs2kUZHFYl4BAgZd60qobGel7BuwSXrVpQqk/LPF 8mXR1V1tbkbx755TqoHerv6/P8XIvjdOPWEdQ5FgpoZ86c3DCL6L6o1e2iFiu0HvpfUx JUwF3/WDgymTC1ExzosTuTyD+zIfsB1B7vuaZHPS/CCx/m/eZjYeuHUmr2VJSrw2D8uo f1Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=h1v+k+m1uWQopKSvjK4+gK+uGP4C6ykIgn3HuvMPfjI=; b=EoRprmszTyo9zFdUxNOxckCImOI9RPB2T6jZfggPTDvfwT856gUZgItXGU61TwQJjH FfOMajoSnUhvKJx+Y2iXqrHCu+RrhZ5V3wNSAKf4MkoOBwe0LeM045ItNkWyH571Mi6r iqxdWld/RaXfgx1A6HgWStdG5nTyOuBJCEYcIhUT9lXjLsQoLVGfcovgfwV38eUseURC devQzT/cv0ppD7gPOQLhxVZPTKdTPsqC1IdPCn6mPiNhNQ/9zHdkm3ntAQJjd9RKx/OL wHhnp+sfHvwiQFYw2vHxITpzPKdrAkM3NmnwyOnbcI4txurTuMiPlLFnZjmvY/9rcECF cp4g== X-Gm-Message-State: AODbwcAuH6NbQFfjZKdF3C+keRS2Gfnw+rwQ+ehxNOJzUPnT3dYL/Mxa rjY6q9dd80UAUYab X-Received: by 10.28.215.5 with SMTP id o5mr2074488wmg.124.1496154592200; Tue, 30 May 2017 07:29:52 -0700 (PDT) Received: from ?IPv6:2001:648:22b0:0:95ca:7c9:9379:d8b? ([2001:648:22b0:0:95ca:7c9:9379:d8b]) by smtp.googlemail.com with ESMTPSA id s95sm5757664wrc.13.2017.05.30.07.29.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 07:29:51 -0700 (PDT) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu To: dickroy@alum.mit.edu, 'William Whyte' References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> Cc: 'Russ Housley' , its@ietf.org Message-ID: Date: Tue, 30 May 2017 17:29:47 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 14:29:56 -0000 Le 30/05/2017 08:08, Dick Roy a crit : > And when a police car with an OBU parks along the side of the road > and becomes an RSU by broadcasting warning messages to oncoming > vehicles So we could "a computer equipped with at least one IEEE 802.11 interface operated in OCB mode, which is physically located in communications range of vehicles but is typically not a vehicle device itself" (remark "typically"). > while the officer(s) are out of the car perusing the scene, then > what. Point is, OBUs and RSUs are not devices they are roles that > real devices can take on. When we discuss handovers we need this RSU term because of being fixed. The handover nature is such a mobile device is 'handed over' from one RSU to another, likely to be fixed. But but. Now I realize we moved the handover discussion out of this draft, so maybe the "RSU" term is not that important. It no longer appears throughout the draft... > You might want to look at ISO 21217 for definitions of all these > things, or not. It has been around for almost a decade however:^)))) Will have to check. Maybe we need another term instead of RSU, that is just a computer running at least one interface in OCB mode, and that implements what this IPv6-over-OCB draft says. Alex > > > > > Furthermore, tying the definition of these objects to a particular > communication interface (IEEE802.11 in OCB mode) really makes no > sense. You would be the only standards group to take such a stance, > and frankly, the communication interface is out of scope for the IETF > and I would recommend against it. > > > > My two euro cents > > > > RR > > > > ------------------------------------------------------------------------ > > *From:*its [mailto:its-bounces@ietf.org] *On Behalf Of *William > Whyte *Sent:* Monday, May 29, 2017 4:41 PM *To:* Alexandre Petrescu > *Cc:* Russ Housley; its@ietf.org *Subject:* Re: [ipwave] RSU minor > textual issue > > > > Hi Alex, > > > > > RSU: Road Side Unit. A computer equipped with at least one IEEE > 802.11 interface operated in OCB mode. An RSU may be connected to > the Internet, and may be equipped with additional wired or wireless > network interfaces running IP. > > > > This doesn't cover the difference between an RSU and an OBU :-) > > > > Maybe "a computer equipped with at least one IEEE 802.11 interface > operated in OCB mode, which is physically located in communications > range of vehicles but is not a vehicle device itself". > > > > Cheers, > > > > William > > > > On Tue, May 30, 2017 at 1:56 AM, Alexandre Petrescu > > > wrote: > > > > Le 18/05/2017 15:33, Russ Housley a crit : > > > > On May 18, 2017, at 5:39 AM, Alexandre Petrescu > > >> wrote: > > OLD: > > RSU: Road Side Unit. An IP router equipped with, or connected to, at > least one interface that is 802.11 and that is an interface that > operates in OCB mode. > > > A comment was made stating that an RSU is not a router, and that an > RSU may be connected to a router via an interface, e.g. Ethernet, to > access the infrastructure if required. > > But I think that some Road Side Units are indeed IP routers and they > access the infrastructure and the Internet. This is an important > point when using the IP protocol - be connected. > > I think I keep that text that way at this time. > > End issue. > > > Alex: > > Some RSUs will be routers, but others will not. For example, an RSU > that sends messages to vehicles about foggy conditions does not need > to be a router. I think the definition should allow both cases. > > > Russ, > > I propose the following new definition. It allows both cases: > > RSU: Road Side Unit. A computer equipped with at least one IEEE > 802.11 interface operated in OCB mode. An RSU may be connected to > the Internet, and may be equipped with additional wired or wireless > network interfaces running IP. > > > Alex > > > > > Russ > > > _______________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > > > > > -- > > > > > > PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: > wwhyte@onboardsecurity.com > From nobody Wed May 31 08:11:48 2017 Return-Path: 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 DB431129C03 for ; Wed, 31 May 2017 08:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 gvIzmW-aBDvu for ; Wed, 31 May 2017 08:11:44 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 90736128D44 for ; Wed, 31 May 2017 08:11:44 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id 19so14164116qke.2 for ; Wed, 31 May 2017 08:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=744NrvK4VwR7KUfyXIHXA7KpQdlwxHpmq6dMugKw2Ek=; b=B+1VncxIj7QfdUH1BvMRqjmLoXFHNwN7CNf2W6v3U7BDbzpMDyGcosykbGdeHwTqS1 BPYymGC9vbVEdgkWK7woHvAhAjuoLKfT9RxL2WNmqYzDiFQRpfOiT/fH5k9CwNOAja9w ssW9hwUoS+JbkG538CL24r9/XprH4dfVIwWXMCgjLvrrDOX1jfjNhRTX94NTuS4B3AxP v8vR9DMfufBgcxfKnRdofEuk5KpWgqvHK5zn+Y5VYMrNXVFWbrfS9XQjTQxPJKH6lhON 77S2y8n7nAfYMj+2hZ9qZsYA9Mo1EdhgMMIwctU29/KXN41t2AVd0F051fTUmtsfwvoM tKbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=744NrvK4VwR7KUfyXIHXA7KpQdlwxHpmq6dMugKw2Ek=; b=J7jIcwmoIjeY5j6O3MCE1A0tCDwkU1DhnSzicr90I/vTmu2IA43sXVf/ctR7Ota93b xTfJq8I+IhgKXFcErZThtICjHpxDSj1kJIlbDOpXPEITtuPoqAHYqNSV3lUFMoc3+n6m /k2fG0QAzWuEM9TBd6jx4uPe0tVWqYohGrliDEH7jRQ57H/xWpY+fHmZQGejaYrwyNuu E8Wqy7/hwuAW30zoxGKQ/VNPJYtDF9A/hoLvgHGHbDKC/YvPe13Pp9+THkUY2F/WikPz Ezs/F+a5rq7WtP4LCpWwiaqquR4igeXS86CrEFvk7qIA7+ynFLHbeFb9e1SGlbT4Y0Ri pP3g== X-Gm-Message-State: AODbwcAIYdkXdF6kgNKI6JXc1791KiwTrfl36Iv3uD+LHnXHLgGTkr1r yw7RITnZqVV6vnMN X-Received: by 10.55.106.199 with SMTP id f190mr30233918qkc.117.1496243503728; Wed, 31 May 2017 08:11:43 -0700 (PDT) Received: from FrancoisPC (pool-108-48-85-190.washdc.fios.verizon.net. [108.48.85.190]) by smtp.gmail.com with ESMTPSA id k200sm1418950qke.2.2017.05.31.08.11.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 08:11:42 -0700 (PDT) From: =?utf-8?Q?Fran=C3=A7ois_Simon?= To: "'William Whyte'" Cc: , References: <3916AFEC-80E9-469F-A2D7-F66010AAB23C@vigilsec.com> In-Reply-To: Date: Wed, 31 May 2017 11:11:48 -0400 Message-ID: <00ac01d2da20$39d22e10$ad768a30$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01D2D9FE.B2C45EA0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLaRBK88xykj8VYhlOq8uhoK7bq9wLPbpucAWZ9t8gCQFPuh5/KO7KA Content-Language: en-us Archived-At: Subject: Re: [ipwave] RSU minor textual issue 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 15:11:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AD_01D2D9FE.B2C45EA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Three definitions related to RSx in the U.S.: =20 FCC (CFR 90.7 - 2010): * RSU: =E2=80=9CRoadside 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=E2=80=9D. =20 FHWA ( Vehicle to Infrastructure Deployment Guidance and Products = =E2=80=93 2015): * RSU: =E2=80=9CA connected device that is only allowed to operate from = a fixed position (which may in fact be a permanent installation or from = temporary equipment brought on-site for a period of time associated with = an incident, road construction, or other event). Some RSEs may have = connectivity to other nodes or the Internet.=E2=80=9D; =20 * RSE: =E2=80=9CTerm used to describe the compliment of equipment to be = located at the roadside; the RSE will prepare and transmit messages to = the vehicles and receive messages from the vehicles for the purpose of = supporting the V2I applications. This is intended to include the DSRC = radio, traffic signal controller where appropriate, interface to the = backhaul communications network necessary to support the applications, = and support such functions as data security, encryption, buffering, and = message processing. It may also be referred to as the 2015 FHWA Vehicle = to Infrastructure Deployment Guidance and Products HANDOUT September 12, = 2014 (Rev. 1) Page 7 Term Description roadside ITS station. When = speaking of the DSRC radio alone, the correct term is RSU.=E2=80=9D. =20 Sincerely, =20 Francois Simon =20 =20 =20 =20 From: its [mailto:its-bounces@ietf.org] On Behalf Of William Whyte Sent: Monday, May 29, 2017 7:41 PM To: Alexandre Petrescu Cc: Russ Housley ; its@ietf.org Subject: Re: [ipwave] RSU minor textual issue =20 Hi Alex, =20 RSU: Road Side Unit. A computer equipped with at least one IEEE 802.11 interface operated in OCB mode. An RSU may be connected to the Internet, and may be equipped with additional wired or wireless network interfaces running IP. =20 This doesn't cover the difference between an RSU and an OBU :-) =20 Maybe "a computer equipped with at least one IEEE 802.11 interface = operated in OCB mode, which is physically located in communications = range of vehicles but is not a vehicle device itself". =20 Cheers, =20 William =20 On Tue, May 30, 2017 at 1:56 AM, Alexandre Petrescu = > = wrote: Le 18/05/2017 =C3=A0 15:33, Russ Housley a =C3=A9crit : =20 On May 18, 2017, at 5:39 AM, Alexandre Petrescu = >> wrote: OLD: RSU: Road Side Unit. An IP router equipped with, or connected to, at least one interface that is 802.11 and that is an interface that operates in OCB mode. A comment was made stating that an RSU is not a router, and that an RSU may be connected to a router via an interface, e.g. Ethernet, to access the infrastructure if required. But I think that some Road Side Units are indeed IP routers and they access the infrastructure and the Internet. This is an important point when using the IP protocol - be connected. I think I keep that text that way at this time. End issue. Alex: Some RSUs will be routers, but others will not. For example, an RSU that sends messages to vehicles about foggy conditions does not need to be a router. I think the definition should allow both cases. Russ, I propose the following new definition. It allows both cases: RSU: Road Side Unit. A computer equipped with at least one IEEE 802.11 interface operated in OCB mode. An RSU may be connected to the Internet, and may be equipped with additional wired or wireless network interfaces running IP. Alex =20 Russ _______________________________________________ its mailing list its@ietf.org =20 https://www.ietf.org/mailman/listinfo/its =20 --=20 =20 =20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: = wwhyte@onboardsecurity.com =20 ------=_NextPart_000_00AD_01D2D9FE.B2C45EA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Three = definitions related to RSx in the U.S.:

 

FCC (CFR = 90.7 - 2010):

  • RSU: =E2=80=9CRoadside 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=E2=80=9D.

 

FHWA ( Vehicle to Infrastructure Deployment = Guidance and Products =E2=80=93 2015):

  • RSU: =E2=80=9CA connected device that is = only allowed to operate from a fixed position (which may in fact be a = permanent installation or from temporary equipment brought on-site for a = period of time associated with an incident, road construction, or other = event). Some RSEs may have connectivity to other nodes or the = Internet.=E2=80=9D;

 

  • RSE: = =E2=80=9CTerm used to describe the compliment of equipment to be = located at the roadside; the RSE will prepare and transmit messages to = the vehicles and receive messages from the vehicles for the purpose of = supporting the V2I applications. This is intended to include the DSRC = radio, traffic signal controller where appropriate, interface to the = backhaul communications network necessary to support the applications, = and support such functions as data security, encryption, buffering, and = message processing. It may also be referred to as the 2015 FHWA Vehicle = to Infrastructure Deployment Guidance and Products HANDOUT September 12, = 2014 (Rev. 1) Page 7 Term Description roadside ITS station. When = speaking of the DSRC radio alone, the correct term is = RSU.=E2=80=9D.

 

Sincerely,

 

Francois = Simon

 

 

 

 

From: its [mailto:its-bounces@ietf.org] On = Behalf Of William Whyte
Sent: Monday, May 29, 2017 7:41 = PM
To: Alexandre Petrescu = <alexandre.petrescu@gmail.com>
Cc: Russ Housley = <housley@vigilsec.com>; its@ietf.org
Subject: Re: = [ipwave] RSU minor textual issue

 

Hi = Alex,

 


    =     RSU: Road Side Unit.  A computer equipped with at = least one
        IEEE 802.11 interface operated = in OCB mode.  An RSU may be
        = connected to the Internet, and may be equipped with additional
  =       wired or wireless network interfaces running = IP.

 

This doesn't cover the = difference between an RSU and an OBU = :-)

 

Maybe = "a computer equipped with at least one IEEE 802.11 = interface operated in OCB mode, which is physically located in = communications range of vehicles but is not a vehicle device = itself".

 

Cheers,

 

William

<= p class=3DMsoNormal> 

On = Tue, May 30, 2017 at 1:56 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> = wrote:



Le 18/05/2017 =C3=A0 15:33, Russ Housley a = =C3=A9crit :

 

On May = 18, 2017, at 5:39 AM, Alexandre Petrescu
<alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
wrote:
<= br>OLD:

RSU: Road = Side Unit. An IP router equipped with, or connected to, at
least one = interface that is 802.11 and that is an interface that
operates in = OCB mode.


A comment = was made stating that an RSU is not a router, and that an RSU
may be = connected to a router via an interface, e.g. Ethernet, to access
the = infrastructure if required.

But I think that some Road Side Units = are indeed IP routers and they
access the infrastructure and the = Internet.  This is an important point
when using the IP protocol = - be connected.

I think I keep that text that way at this = time.

End issue.


Alex:

Some RSUs will be routers, but others = will not.  For example, an RSU
that sends messages to vehicles = about foggy conditions does not need to
be a router.  I think = the definition should allow both cases.


Russ,

I = propose the following new definition.  It allows both = cases:

  =       RSU: Road Side Unit.  A computer equipped with = at least one
        IEEE 802.11 interface = operated in OCB mode.  An RSU may be
        = connected to the Internet, and may be equipped with additional
  =       wired or wireless network interfaces running = IP.


Alex

 


Russ


_______________________________________________
= its mailing list
its@ietf.org
https://www.ietf.org/mailman/listinfo/its



 

-- =

 

 

PLEASE = UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com

------=_NextPart_000_00AD_01D2D9FE.B2C45EA0--