From alexandru.petrescu@gmail.com Sun Jun 2 11:00:49 2013 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 630AD21F8FA9 for ; Sun, 2 Jun 2013 11:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.204 X-Spam-Level: X-Spam-Status: No, score=-9.204 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzh++GeBGXfa for ; Sun, 2 Jun 2013 11:00:42 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD4221F8FB6 for ; Sun, 2 Jun 2013 11:00:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r52I0bY7026063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 2 Jun 2013 20:00:37 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r52I0bEX025911 for ; Sun, 2 Jun 2013 20:00:37 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r52I0a7Y007521 for ; Sun, 2 Jun 2013 20:00:36 +0200 Message-ID: <51AB8843.1010206@gmail.com> Date: Sun, 02 Jun 2013 20:00:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] Pending request of BoF slot for ITS of IETF in Berlin, decision by June 20, 27 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 18:00:49 -0000 ITSers, I wanted to let you know that I have sent a request for scheduling a BoF session for ITS of IETF in Berlin. We will get a response by June 20 or June 27th. I guess the decision for Berlin depends largely on the content and activity of the email list, how far are we with Charter, how much interest there really is, other independent signals. The membership of the list counts approximately 200 email addresses. Alex From alexandru.petrescu@gmail.com Tue Jun 11 05:51:50 2013 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 795EE21F994C for ; Tue, 11 Jun 2013 05:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.249 X-Spam-Level: X-Spam-Status: No, score=-12.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4WpVz3lTOJx for ; Tue, 11 Jun 2013 05:51:46 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7D54B21F8FC4 for ; Tue, 11 Jun 2013 05:51:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5BCpeqf002592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 11 Jun 2013 14:51:40 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5BCpeQp015937 for ; Tue, 11 Jun 2013 14:51:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5BCpMxq004009 for ; Tue, 11 Jun 2013 14:51:40 +0200 Message-ID: <51B71D4A.2010503@gmail.com> Date: Tue, 11 Jun 2013 14:51:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <511F7968.7090309@gmail.com> <5177C6BA.6020805@gmail.com> <85C635C4D32378499484B2C61BD297A419E9993E@GSukMHDDCembx02.service.hitachi.net> <51952414.1050500@gmail.com> In-Reply-To: <51952414.1050500@gmail.com> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Subject: [its] Updated list of suppliers of 802.11p-compatible equipment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:51:50 -0000 Hello participants to ITS email list, I added Arada Systems to the list of suppliers of 802.11p-compatible equipment. Additionally, I have been pointed that many if not all (?) these systems use 802.11p miniPCI boards from UNEX. The list is now the following: Arada Systems LocoMate OBU RENESAS ELECTRONICS NEC NXP/Cohda Wireless Cisco/Cohda Wireless Denso Delphi Savari Kapsch Siemens ITRI AutoTalks Commsignia Yours, Alex Le 16/05/2013 20:23, Alexandru Petrescu a écrit : > Yes, thank you. The list is now: > > RENESAS ELECTRONICS > NEC > NXP/Cohda Wireless > Cisco/Cohda Wireless > Denso > Delphi > Savari > Kapsch > Siemens > ITRI > AutoTalks > Commsignia > > Yours, > > Alex > > Le 03/05/2013 18:32, Lenardi, Massimiliano a écrit : >> Dear All, >> please also add RENESAS ELECTRONICS to the list below of potential >> suppliers of 11p/DSRC enabled radio devices. >> Best, >> - >> Max >> >> >> -----Original Message----- >> From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of >> Alexandru Petrescu >> Sent: 24 April 2013 13:49 >> To: its@ietf.org >> Subject: Re: [its] suppliers of 802.11p-over-ITS-G5; >> 802.11s-over-5875-5905MHz >> >> Recently I discovered that in addition to the posted list there is >> also Commsignia as a manufacturer of 802.11p compatible OBU and RSU. >> The list is now: >> >> NEC >> NXP/Cohda Wireless >> Cisco/Cohda Wireless >> Denso >> Delphi >> Savari >> Kapsch >> Siemens >> ITRI >> AutoTalks >> Commsignia >> >> Yours, >> >> Alex >> >> Le 16/02/2013 13:19, Alexandru Petrescu a écrit : >>> Le 11/02/2013 14:50, Dowdell, John a écrit : >>>> Alex >>>> >>>> Is anyone making 802.11p radios commercially at reasonable cost? The >>>> few I have seen seem to be very expensive (few k$) and there appears >>>> to be little support in Linux. >>> >>> John, >>> >>> A person was kind enough to gather in one place information which is >>> otherwise sparsely but publicly available; this information is about >>> suppliers of 802.11p-over-ITS-G5 frequencies (5875-5905MHz, >>> 5855-5875MHz, 5470-5725MHz; caveat - only some are allowed in some >>> countries, check the local regulator before turning these on). >>> >>> NEC >>> NXP/Cohda Wireless >>> Cisco/Cohda Wireless >>> Denso >>> Delphi >>> Savari >>> Kapsch >>> Siemens >>> ITRI >>> AutoTalks >>> >>> I have some experience with ITRI equipment. In their offer there is a >>> full-blown RSU, for around 1500EUR. This is for a RSU hardened box >>> for outdoors, powerpc, GPS-enabled, 2x 802.11p interfaces, Ethernet >>> with PoE, USB, and linux 2.6. Among these, it is the software which >>> is expensive; this includes Atheros driver modifications, new kernel >>> modules for "BTP" (Base Transmission Protocol?), 'geonetworking', >>> 'wave'. >>> >>> OTher than a full-blown RSU, one could acquire also ITRI individual >>> '802.11p' miniPCI cards which are in the order of couple hundreds of >>> euros. >>> >>> This is not a commercial advertisement. Technically speaking this >>> means many things for designing protocols. For example: >>> >>> It means it is easily possible to run linux with IPv6 over a 'wave0' >>> interface. Just turn it on, watch the IPv6 link-local address, echo >>> the frequency value and ping. (no need to set ESSID, nor security). >>> >>> In addition to the Ethernet interfaces, the RSU has _2_ 802.11p >>> different interfaces, and one Ethernet. Not just two antennas, but >>> two interfaces (ifconfig 'wave0' and 'wave1'). This means one doesn't >>> need to 'relay' packets and that one needs to 'route' packets, in the >>> traditional sense of 'routing'. (compare this for example to RPL >>> context where a sensor has a _single_ interface and there is no >>> routing, but 'relaying'). >>> >>> Also this outdoors RSU has 1 GPS antenna. This means that >>> geonetworking does not work if one tries to use this indoors in a lab >>> where GPS signal does not reach. (unless one installs a GPS 'repeater' >>> - easy to do but check with regulator in country, or use a GPS >>> 'replayer' software to play pre-recorded NMEA sentences on /dev/tty). >>> >>> Note also it is strange to design an RSU Road Side Unit - designed to >>> be fixed with respect to Earth, and put a GPS interface on it. It >>> would have been easier to just record the GPS coordinates once and set >>> them in a file for as long as that RSU stays there. I consider it as >>> an extra, but cheaper RSU without GPS should be possible. >>> >>>> 802.11s on the other hand is available on standard Wi-Fi dongles >>>> (from $15) and drivers are already available in Linux. Is it correct >>>> that 802.11p is mandated for ITS in some regions? >>> >>> I doubt 802.11p be mandated for ITS. >>> >>> I think the regulator mandates the application which could be used on >>> some frequencies. >>> >>> Where I live, the regulator mandates the use of vehicular 'safety' >>> applications at 5875-5905MHz. The technical 'conditions' are referred >>> by the regulator to ETSI documents (the regulator is not ETSI, but >>> often implements what ETSI wants, but not always). I doubt the >>> regulator mandates 'geonetworking' for this band. >>> >>> I doubt 'IP' could be qualified as 'safety'. >>> >>> Hence I think 802.11s _could_ be used on the range 5875-5905MHz, as >>> long as it does not transport IP. >>> >>> 802.11p has some features which could qualify as 'safety'. For >>> example, it has some MAC-layer messages for 'emergency', and with >>> timestamps (absent from .11 non-p standard), which don't transport IP. >>> >>> 'geonetworking' also has some features which could qualify as 'safety'. >>> I just don't remember which. >>> >>> What features in 802.11s would qualify as 'safety'? >>> >>> Alex >>> >>>> >>>> John >>>> >>>> -----Original Message----- From: its-bounces@ietf.org >>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >>>> 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP over >>>> 802.11p >>>> >>>> Le 31/01/2013 14:47, Thierry Ernst a écrit : >>>>> >>>>> Well, we do actually run IPv6 over 11p (with or without >>>>> GeoNetworking), so I don't see what kind of issues there might be >>>>> ... >>>> >>>> I have some clarification questions about EtherType and 802.11p and >>>> GeoNetworking. >>>> >>>> I guess when you run IPv6 over 11p with GeoNetworking, the Ethernet >>>> header uses EtherType soon-to-be-0x8947, whereas when you run IPv6 >>>> over 11p without GeoNetworking, the Ethernet header uses EtherType >>>> 0x86DD. This is just a supposition, I don't know how you run it. >>>> >>>> Also, if I run IPv4 over 11p with GeoNetworking - should I use >>>> EtherType soon-to-be-0x8947? Or other? I suppose that if I run IPv4 >>>> over 11p without GeoNetworking I should use EtherType 0x0800, and if >>>> it's ARP over 802.11p still without GeoNetworking then I should use >>>> EtherType 0x0806. >>>> >>>> (the letter we've seen recently is not clear whether that allocation >>>> is for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for >>>> GeoNetworking for IPv6, for GeoNetworking for IPv4, etc. It is not >>>> clear either whether GeoNetworking supports IPv4 or not, or under >>>> what form). >>>> >>>> I also have some questions about the relationship between the nature >>>> of some 802.11p links (no ESSID, absence of link-layer security - as >>>> opposed to WiFi which has ESSID and link-layer security) and IP. >>>> >>>> For example - will V2V prefix exchange using Router Advertisements >>>> work easier on 802.11p links (easier than on WiFi), because the ESSID >>>> does not need to be discovered, the ad-hoc network does not need to >>>> be formed - suffices it to send packets on a certain channel. >>>> >>>> (in a V2V draft one seems to say that the presence of Access Point is >>>> absolutely necessary in order for 802.11p to work; but in our >>>> experimentations this is not the case - it is possible to establish >>>> direct vehicle-to-vehicle IP-over-802.11p communications without the >>>> presence of a fixed 802.11p Access Point). >>>> >>>> For another example - will IP prefer that the 802.11p channel in >>>> France be 176, 178 or 180? (with WiFi, IP does not care because it >>>> can work on any of the 11 channels equally well, but with 802.11p >>>> each of these three channels seem to be reserved for "Services", >>>> "Control" and "Services"). >>>> >>>> For another example - is all the security on these links entirely >>>> relaying on IP layer security (IPsec, SeND, EAP, PANA)? >>>> >>>> I think finding consensus on some of these questions could lead to >>>> interoperability. >>>> >>>> Alex >>>> >>>>> >>>>> Regards, Thierry >>>>> >>>>> >>>>> >>>>> On 31/01/13 13:55, Alexandru Petrescu wrote: >>>>>> Given current discussions, I think it may be worth considering a >>>>>> work item about how to run IP over 802.11p. >>>>>> >>>>>> One of the things to say would be whether or not this is IPv6 only >>>>>> or IPv4 also. >>>>>> >>>>>> This would say how this would work _without_ GeoNetworking. >>>>>> >>>>>> It would agree on the EtherType and/or whether there are new ones, >>>>>> several or only one, or reusing existing EtherTypes. >>>>>> >>>>>> It could be as simple as to say that IP works over 802.11p just as >>>>>> it works over 802.11b - no modifications. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Alex >>>>>> >>>>>> Le 30/01/2013 11:10, Alexandru Petrescu a écrit : >>>>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a écrit : >>>>>>>> Hi Alexandru, >>>>>>>> >>>>>>>> IEEE talk only hexa in their Ethertype files. >>>>>>> >>>>>>> I tend to agree that #8947 is a hexadecimal notation also because >>>>>>> the sharp sign preceding it, and because if it were decimal it >>>>>>> would convert to 22F3 which is already reserved for trill. >>>>>>> >>>>>>> I just watend to make sure. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>>>>>>> Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>>>> its@ietf.org Subject: Re: [its] What do we need to make ITS WG >>>>>>>>> go forward? - EtherType for ITS >>>>>>>>> >>>>>>>>> Hello Dan, >>>>>>>>> >>>>>>>>> Thank you for the email. >>>>>>>>> >>>>>>>>> I think we definitely need a good interface with IEEE about >>>>>>>>> this. >>>>>>>>> >>>>>>>>> Maybe you could ask them whether this number is hexa or decimal, >>>>>>>>> so we know what to put in implementation (e.g. >>>>>>>>> wireshark packet analyzers, and 802.11p/etsi-its >>>>>>>>> implementations). >>>>>>>>> >>>>>>>>> Also, I am interested to learn whether this deserves being >>>>>>>>> reserved at IANA. >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a écrit : >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> The documents that you are referring (on the ETSI >>>>>>>>>> server) are not freely accessible. A password is required, and >>>>>>>>>> probably only ETSI members have the access information. >>>>>>>>>> >>>>>>>>>> The responsibility for assigning EtherType values is with the >>>>>>>>>> IEEE Registration Authority. They maintain a public list >>>>>>>>>> (updated daily) at >>>>>>>>>> http://standards.ieee.org/develop/regauth/ethertype/eth.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> and according to this list the value 8947 is not allocated. >>>>>>>>>> Now, the public listing information for EtherTypes bears a >>>>>>>>>> disclaimer that says >>>>>>>>>> >>>>>>>>>> * This is a partial listing of all assigned EtherType Fields. >>>>>>>>>> Not >>>>>>>>> all >>>>>>>>>> recipients wish to publish their assignment at this time. >>>>>>>>>> >>>>>>>>>> Did ETSI require for this information not to be published? It >>>>>>>>>> does not look useful if they want to encourage interoperability >>>>>>>>>> >>>>>>>>>> Value 0707 mentioned in the thread is not allocated either. >>>>>>>>>> >>>>>>>>>> Let me know if I can help (as IETF liaison to the IEEE-SA). >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> *From:*its-bounces@ietf.org >>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry Ernst >>>>>>>>>> *Sent:* Wednesday, January 30, 2013 11:11 AM *To:* its@ietf.org >>>>>>>>>> *Subject:* Re: [its] What do we need to make ITS WG go forward? >>>>>>>>>> - EtherType for ITS >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Alex, >>>>>>>>>> >>>>>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS use >>>>>>>>>> (ETSI TC ITS's GeoNetworking). Check the following document >>>>>>>>>> available on the ETSI server: >>>>>>>>>> >>>>>>>>>> ITS(13)000020 >>>>>>>>>> >>>>>>>>> 2900002 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> 0_Ethernet_Type_Field_number_for_GeoNetworking.pdf> >>>>>>>>>> Ethernet Type Field number for GeoNetworking >>>>>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)000 >>>>>>>>>> 020_Eth >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> ernet_Type_Field_number_for_GeoNetworking.pdf >>>>>>>>>> >>>>>>>>>> Regards, Thierry. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote: >>>>>>>>>> >>>>>>>>>> Le 28/01/2013 14:16, Joe Klein a écrit : >>>>>>>>>> >>>>>>>>>> I really dislike the fact that ISO is charging for the ISO >>>>>>>>>> 21217 - Architecture & ISO 21210 - IPv6 Networking. >>>>>>>>>> >>>>>>>>>> Does this make it any better? Safer? Should ISO now have >>>>>>>>>> cybersecurity and safety liability if the specification leads >>>>>>>>>> to deaths and damage to property? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Does it make any better interoperable as well? >>>>>>>>>> >>>>>>>>>> EtherType 0x0707 described in ITS documents, implemented, but >>>>>>>>>> not specified by IEEE nor reserved at IANA - does not make it >>>>>>>>>> interoperable. >>>>>>>>>> >>>>>>>>>> One wouldn't think that this 0x0707 ethertype be reserved by >>>>>>>>> somebody >>>>>>>>>> who is not IANA nor IEEE? >>>>>>>>>> >>>>>>>>>> (see a good example of interoperability: IPv6 0x86dd ethertype >>>>>>>>>> is reserved at IEEE and at IANA >>>>>>>>>> >>>>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbe >>>>>>>>>> rs.xml) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> Alex >>>>>>>>>> >>>>>>>>>> Or should these standards remain in >>>>>>>>>> >>>>>>>>>> the public domain, for researches to review and validate? >>>>>>>>>> >>>>>>>>>> Just my 2 cents. >>>>>>>>>> >>>>>>>>>> Joe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Dear all, >>>>>>>>>> >>>>>>>>>> At this stage, I don't think a new working group is needed. >>>>>>>>>> First, it would need a charter, and support from the industry. >>>>>>>>>> But more importantly, IETF WGs are not usually sector-driven, >>>>>>>>>> so it means the different issues pertaining to ITS should be >>>>>>>>>> brought to >>>>>>>>> VARIOUS >>>>>>>>>> existing WGs, and a WG should only be created if there is an >>>>>>>>>> important issue for which there is no existing WG that could >>>>>>>>>> work on it. >>>>>>>>>> >>>>>>>>>> This said, as mentioned earlier, ITS is not only about >>>>>>>>>> vehicular communications, though the issues listed by Alexandru >>>>>>>>>> below mostly consider vehicular communications. >>>>>>>>>> >>>>>>>>>> What ITS really needs is the definition of a common >>>>>>>>>> communication architecture and the definition of what features >>>>>>>>>> should be comprised for an IPv6 networking stack deployed for >>>>>>>>>> ITS use cases. This cannot be done at IETF, and actually >>>>>>>>>> already exists at ISO: - ISO 21217 - Architecture - ISO 21210 - >>>>>>>>>> IPv6 Networking >>>>>>>>>> >>>>>>>>>> As an input to the discussion, please consider reading >>>>>>>>>> documents D2.1 and D2.2 available on the ITSSv6 project web >>>>>>>>>> page: http://www.itssv6.eu/documentation/ D2.2 provides an >>>>>>>>>> analysis of the currently published version of ISO 21210, but >>>>>>>>>> new work items have been launched since then to address >>>>>>>>>> remaining issues. >>>>>>>>>> >>>>>>>>>> Regards, Thierry. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a écrit : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> All, >>>>>>>>>> >>>>>>>>>> This is just one opinion, but I'd like to understand why ITS >>>>>>>>>> would need its own IETF group. The work here is the same (IMO) >>>>>>>>>> as what is taking place in MANET. I would vote that this work >>>>>>>>>> be taken up in MANET. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Stan, >>>>>>>>>> >>>>>>>>>> Thank you for the offer. I considered this offer since some >>>>>>>>>> time. >>>>>>>>>> >>>>>>>>>> I try to understand whether some of these items on which I >>>>>>>>>> have interest could be brought in in MANET WG: - V2V using >>>>>>>>>> prefix exchange - VIN-based IP addressing scheme - ND Prefix >>>>>>>>>> Delegation - PMIP-based network mobility - >>>>>>>>>> IPv6 single-address connecion 'sharing' with a cellular >>>>>>>>>> operator and a vehicular moving network (type '64share' >>>>>>>>>> of v6ops). - Default Route with DHCPv6. >>>>>>>>>> >>>>>>>>>> Please let me know. >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> >>>>>>>>>> Alex >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, Stan >>>>>>>>>> >>>>>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Nabil, >>>>>>>>>> >>>>>>>>>> I think we already done some steps but not sure how far now. We >>>>>>>>>> will need to propose the WG and provide the WG charter, as use >>>>>>>>>> cases and work to be done in this group. >>>>>>>>>> This charter needs to be approved by the IESG. I have not >>>>>>>>>> attended the last meeting so not sure about the status now, >>>>>>>>>> >>>>>>>>>> AB >>>>>>>>>> >>>>>>>>>> On 1/26/13, Nabil Benamar >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> I'm still interested in this list and want to join voices >>>>>>>>>> previously heard to make it a working group. So what should we >>>>>>>>>> exactly do, to achieve this goal ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> I was interested in this group but not sure where are we so >>>>>>>>>> far. Is there progress, or is there issues/efforts that need to >>>>>>>>>> be completed and volunteered. >>>>>>>>>> >>>>>>>>>> AB _______________________________________________ its mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- * * *ÊÍíÇÊí ¡ **Cordialement, Regards* * * * * *äÈíá >>>>>>>>>> ÈäÚãÑæNabil Benamar* Professor of computer sciences Simulation >>>>>>>>>> and Modelisation Laboratory Human Sciences Faculty of Meknes >>>>>>>>>> Moulay Ismail* *University* Meknes, Morocco *GSM: * *+ 212 6 >>>>>>>>>> 70832236 http://nabilbenamar.com/ >>>>>>>>>> >>>>>>>>>> * >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>> ------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> ---------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> * >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>> its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its mailing >>>>>>>>> list >>>>>>>>>> its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> _______________________________________________ its mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its mailing >>>>>>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its mailing >>>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing list >>>>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing list >>>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>>> >>>> _______________________________________________ its mailing list >>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its The >>>> information contained within this e-mail and any files attached to >>>> this e-mail is private and in addition may include commercially >>>> sensitive information. The contents of this e-mail are for the >>>> intended recipient only and therefore if you wish to disclose the >>>> information contained within this e-mail or attached files, please >>>> contact the sender prior to any such disclosure. If you are not the >>>> intended recipient, any disclosure, copying or distribution is >>>> prohibited. Please also contact the sender and inform them of the >>>> error and delete the e-mail, including any attached files from your >>>> system. Cassidian Limited, Registered Office : Quadrant House, Celtic >>>> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 >>>> http://www.cassidian.com >>>> >>>> >>> >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >> >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> ************************************************************************************************** >> >> E-mail Confidentiality Notice and Disclaimer. >> >> This e-mail and any files transmitted with it are confidential and are >> intended solely for the use >> of the individual or entity to which they are addressed. Access to >> this e-mail by anyone else is >> unauthorised. If you are not the intended recipient, any disclosure, >> copying, distribution or any >> action taken or omitted to be taken in reliance on it, is prohibited. >> E-mail messages are not >> necessarily secure. Hitachi does not accept responsibility for any >> changes made to this message >> after it was sent. >> Hitachi checks outgoing e-mail messages for the presence of computer >> viruses. >> ************************************************************************************************** >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Tue Jun 11 06:23:30 2013 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 799C321F96FF for ; Tue, 11 Jun 2013 06:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.249 X-Spam-Level: X-Spam-Status: No, score=-11.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpP+as3gtdJZ for ; Tue, 11 Jun 2013 06:23:22 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id BB85121F96DF for ; Tue, 11 Jun 2013 06:23:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5BDNIor020504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 11 Jun 2013 15:23:18 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5BDNHTG031894 for ; Tue, 11 Jun 2013 15:23:17 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5BDNE4k026370 for ; Tue, 11 Jun 2013 15:23:17 +0200 Message-ID: <51B724C2.2010305@gmail.com> Date: Tue, 11 Jun 2013 15:23:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] Potential modifications for IPv6-straight-over-802.11p (from IPv6-over-802.11) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 13:23:30 -0000 Hello participants to the ITS email list, The potential modifications on the use of IPv6 over 802.11p (beyond the way IPv6-over-80211 already works) may be: (1) issued by the fact that the BSSID is always 48 1 bits, (2) on the NTP and/or frequency of RA for timestamps, because Timestamps are required by 802.11p for being in synch, (3) on MIB, because 802.11p has EDCA parameters for STA QoS. (4) do ND security (or other layer?) because 802.11p does not do Authentication Req/Resp. (5) have a means for a mobile node to distinguish between two different 802.11p Access Routers, because 802.11p works outside the context of an BSS. This would facilitate the handover procedure of protocol Mobile IPv6. In detail, below: The modifications needed for a driver to go from 802.11 to 802.11p are the following. This is for a driver like Atheros 5K for linux. - work 'outside a BSS', i.e. use the BSSID as 48 1 bits. This is present in every MAC header of data and control frames, in the field BSSID. It is not the dst MAC address. This may or may not have an influence on the way ND, ICMP and MLD use the multicast addresses (typically they assume 33::1 instead of 48 1s, but that's only for dst, BSSID being not used by these protocols). - send periodic timestamps. This could have a relationship on the way NTP works, or maybe send RAs containing a timestamp. - EDCA parameter set for STAs transmitting QoS frames - maybe have entries in MIB. - do not do Authentication Request, and no other Auth message. - modify the 'regulatory domain' such as the PHY works on the vehicular frequencies valid in the respective country. This is typically somewhere between 5860MHz to 5920MHz. These frequencies are dedicated to only vehicular settings. - half-rate (or half-clocking) - the band width must be 10MHz, instead of the typical 802.11 20MHz. - Tx Power - go to as high as 33dBm in some countries (instead of 20dBm of 802.11). - deactivate emission of Beacons. Thoughts on these aspects? Alex From mcr@sandelman.ca Tue Jun 11 10:27:39 2013 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 A24FB21F9695 for ; Tue, 11 Jun 2013 10:27:39 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CpFiWSzUAPb for ; Tue, 11 Jun 2013 10:27:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEE221F957B for ; Tue, 11 Jun 2013 10:27:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F3E120191; Tue, 11 Jun 2013 13:40:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E503463A8C; Tue, 11 Jun 2013 13:26:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D48F9639DF; Tue, 11 Jun 2013 13:26:40 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <51B724C2.2010305@gmail.com> References: <51B724C2.2010305@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "its@ietf.org" Subject: Re: [its] Potential modifications for IPv6-straight-over-802.11p (from IPv6-over-802.11) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 17:27:39 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Alexandru" =3D=3D Alexandru Petrescu = writes: Alexandru> Hello participants to the ITS email list, Alexandru> The potential modifications on the use of IPv6 over 802.11p = (beyond the Alexandru> way IPv6-over-80211 already works) may be: Alexandru> (1) issued by the fact that the BSSID is always 48 1 bits, that, from the IPv6-over-802.11 point of view, is a layer-2 issue. Alexandru> (2) on the NTP and/or frequency of RA for timestamps, because Alexandru> Timestamps are required by 802.11p for being in synch, I don't understand. Alexandru> (3) on MIB, because 802.11p has EDCA parameters for STA QoS. Maybe, but first, can you show me who has a MIB on client side 802.11 devic= e? (11p has no access point...) Alexandru> (4) do ND security (or other layer?) because 802.11p does no= t do Alexandru> Authentication Req/Resp. seems like a layer-3 (IPv6) issue, not an IPv6-over-foo issue. Alexandru> (5) have a means for a mobile node to distinguish between tw= o different Alexandru> 802.11p Access Routers, because 802.11p works outside the co= ntext Alexandru> of an BSS. This would facilitate the handover procedure of Alexandru> protocol Mobile IPv6. I don't see how this has anything to do with anything. Mobile IPv6 cares about the IP address of Home Agents. Alexandru> - work 'outside a BSS', i.e. use the BSSID as 48 1 bits. Th= is is Alexandru> present in every MAC header of data and control frames, in t= he field Alexandru> BSSID. It is not the dst MAC address. This may or may not = have an Alexandru> influence on the way ND, ICMP and MLD use the multicast addr= esses Alexandru> (typically they assume 33::1 instead of 48 1s, but that's on= ly for Alexandru> dst, BSSID being not used by these protocols). huh? The BSSID is not the MAC header. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUbdd0IqHRg3pndX9AQIDeQP/UDyFi4WtonYvM/yvQ+NyjGDyUEeWctuP fGXtTLpUz4KFeyTn4z0WE6OBuap/CLfVAJcXU1pKdiQugowObCIjUBS1cS5gYMVo ZKybJ+XWbIS0TTzrERFBr4RCPhcL+igy4ZEfQR4BBjedBoAY+hFYXKOcbSG9Zzb4 BgzhYvbTSoQ= =diKJ -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Wed Jun 12 03:16:05 2013 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 E1BC221F9BA7 for ; Wed, 12 Jun 2013 03:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.749 X-Spam-Level: X-Spam-Status: No, score=-10.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGHZjUfsNvMj for ; Wed, 12 Jun 2013 03:15:58 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5136B21F9BC7 for ; Wed, 12 Jun 2013 03:15:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5CAFuGo004331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 12:15:56 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5CAFueF015293; Wed, 12 Jun 2013 12:15:56 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5CAFkhI024053; Wed, 12 Jun 2013 12:15:55 +0200 Message-ID: <51B84A51.6050602@gmail.com> Date: Wed, 12 Jun 2013 12:15:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Richardson References: <51B724C2.2010305@gmail.com> <12413.1370971600@sandelman.ca> In-Reply-To: <12413.1370971600@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" Subject: Re: [its] Potential modifications for IPv6-straight-over-802.11p (from IPv6-over-802.11) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 10:16:05 -0000 Le 11/06/2013 19:26, Michael Richardson a écrit : > >>>>>> "Alexandru" == Alexandru Petrescu >>>>>> writes: > Alexandru> Hello participants to the ITS email list, > > Alexandru> The potential modifications on the use of IPv6 over > 802.11p (beyond the Alexandru> way IPv6-over-80211 already works) may > be: > > Alexandru> (1) issued by the fact that the BSSID is always 48 1 > bits, > > that, from the IPv6-over-802.11 point of view, is a layer-2 issue. Yes, there's a layer 2 issue, and layer 3 may map to it. E.g. map an IPv6 multicast address into a link-layer multicast address. It may be that the BSSID 48 1 bits (ff:ff:ff:ff:ff:ff) may be needed for something that IP needs, at which time there would be a need for a mapping method. > Alexandru> (2) on the NTP and/or frequency of RA for timestamps, > because Alexandru> Timestamps are required by 802.11p for being in > synch, > > I don't understand. By spec, 802.11p (as opposed to 802.11) needs to transmit periodically a Timestamp. That is a link-layer message. Its goal is for the stations around to synchronize their time. To program that in the 802.11p driver is difficult, because it is very low level. I havent seen this Timestamp 802.11p message, despite having access to some 802.11p stacks. But it may be easier to do it at IP layer. This could be done in various ways: maybe have a timestamp field in a RA? (there isnt currently any). Maybe have NTP protcol realize that? > Alexandru> (3) on MIB, because 802.11p has EDCA parameters for STA > QoS. > > Maybe, but first, can you show me who has a MIB on client side 802.11 > device? Good question - I dont know. I can only suppose there could exist. I think MIBs exist on end nodes, not necessarily routers or managed access points. > (11p has no access point...) Well yes, 11p does not have managed mode, nor adhoc mode, nor any meaningful form of BSS. However, nothing stops somebody from putting a 802.11p and a Ethernet interface on a Router. That is an Access Router. There are some products on the market named RSU (Road-Side Unit) which are built that way. The RSUs all send data on a particular frequency at 5.9GHz range, without first forming a BSS. Everybody hears everybody else, and everybody talks to everybody else. > Alexandru> (4) do ND security (or other layer?) because 802.11p does > not do Alexandru> Authentication Req/Resp. > > seems like a layer-3 (IPv6) issue, not an IPv6-over-foo issue. Well, security being still important, the fact that 802.11p does not have security (no Auth Req/Resp, no Probe Req/Resp, no Ass'n Req/Resp) means that upper layer security is even more important than before. Before 802.11p, we were saying that ND security (e.g. SeND) may not be needed because 802.11 already had WEP and WPA. But now, since 802.11p does not have neither WEP nor WPA, ND security is even more important. The problem here is: which ND security? SeND? Other? > Alexandru> (5) have a means for a mobile node to distinguish between > two different Alexandru> 802.11p Access Routers, because 802.11p > works outside the context Alexandru> of an BSS. This would > facilitate the handover procedure of Alexandru> protocol Mobile > IPv6. > > I don't see how this has anything to do with anything. Mobile IPv6 > cares about the IP address of Home Agents. By RFC, the movement detection of Mobile IPv6 relies on the comparison of prefixes received in Router Advertisements. But in implementation, often this detection is guided by the change in ESSID (provoke a different Ass'n Req to a different ESSID, then receive RA, then compare to old prefix). But with 802.11p we don't have Ass'n Req. Basically a Mobile Node receives RAs from all other Access Routers who send RAs on that 5900MHz frequency (802.11p is all 'outside a BSS'). With the current movement detection of RFC Mobile IPv6 and without a BSS, it's hard for a Mobile Node to detect movement consistently. The end result is that the Mobile Node may choose the default route to an Access Router which may not necessarily be the good one (not the closest, not the approaching, etc.). > Alexandru> - work 'outside a BSS', i.e. use the BSSID as 48 1 bits. > This is Alexandru> present in every MAC header of data and control > frames, in the field Alexandru> BSSID. It is not the dst MAC > address. This may or may not have an Alexandru> influence on the way > ND, ICMP and MLD use the multicast addresses Alexandru> (typically > they assume 33::1 instead of 48 1s, but that's only for Alexandru> > dst, BSSID being not used by these protocols). > > huh? The BSSID is not the MAC header. Right, the BSSID is in the 802.11 header (not the Ethernet header). It may be that this BSSID all 1s may not have any influence on IPv6. Alex > From mcr@sandelman.ca Wed Jun 12 07:44:19 2013 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 DCF8921F995A for ; Wed, 12 Jun 2013 07:44:19 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aC5CC4bCt83 for ; Wed, 12 Jun 2013 07:44:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 18A0921F98AD for ; Wed, 12 Jun 2013 07:44:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3695620191; Wed, 12 Jun 2013 10:57:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 360E263A8C; Wed, 12 Jun 2013 10:43:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 25419639DF; Wed, 12 Jun 2013 10:43:22 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <51B84A51.6050602@gmail.com> References: <51B724C2.2010305@gmail.com> <12413.1370971600@sandelman.ca> <51B84A51.6050602@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Wed, 12 Jun 2013 07:45:04 -0700 Cc: "its@ietf.org" Subject: Re: [its] Potential modifications for IPv6-straight-over-802.11p (from IPv6-over-802.11) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 14:44:20 -0000 >>>>> "Alexandru" == Alexandru Petrescu writes: >>>>>>> "Alexandru" == Alexandru Petrescu >>>>>>> writes: Alexandru> Hello participants to the ITS email list, >> Alexandru> The potential modifications on the use of IPv6 over >> 802.11p (beyond the Alexandru> way IPv6-over-80211 already works) may >> be: >> Alexandru> (1) issued by the fact that the BSSID is always 48 1 >> bits, >> >> that, from the IPv6-over-802.11 point of view, is a layer-2 issue. Alexandru> Yes, there's a layer 2 issue, and layer 3 may map to it. E.g. map an Alexandru> IPv6 multicast address into a link-layer multicast Alexandru> address. No, it does not. The BSSID is not used by layer3, and is not even visible to it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From prvs=0876574288=varadi@lesswire.com Thu Jun 13 08:05:49 2013 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 0E03E21F99B0 for ; Thu, 13 Jun 2013 08:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMJc4UYnVCyg for ; Thu, 13 Jun 2013 08:05:45 -0700 (PDT) Received: from radmz1.prettl-elektronik.de (radmz1.prettl-elektronik.de [212.185.50.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5E21821F91B7 for ; Thu, 13 Jun 2013 08:05:32 -0700 (PDT) Received: from rasrv02.prettl-elektronik.de ([10.76.0.20]:56431) by utm.prettl-electronics.com with esmtp (Exim 4.76) (envelope-from ) id 1Un95V-0002qQ-2o for its@ietf.org; Thu, 13 Jun 2013 17:05:23 +0200 X-CTCH-RefID: str=0001.0A0C0209.51B9DFB3.01CE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 13 Jun 2013 17:04:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [its] Updated list of suppliers of 802.11p-compatible equipment Thread-Index: Ac5monZ13dYH8CG4TnWIixj+xA1DSgBoaeOg References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com><51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr><51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr><9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com><5108EF0B.5050002@gmail.com><9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com><5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com><510A75F8.7080508@inria.fr><603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp><511F7968.7090309@gmail.com> <5177C6BA.6020805@gmail.com><85C635C4D32378499484B2C61BD297A419E9993E@GSukMHDDCembx02.service.hitachi.net><51952414.1050500@gmail.com> <51B71D4A.2010503@gmail.com> From: "Varadi , Andras \(lesswire AG Ungarn\)" To: Subject: Re: [its] Updated list of suppliers of 802.11p-compatible equipment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:05:49 -0000 RGVhciBBbGV4YW5kZXINCg0KUGxlYXNlIGxldCBtZSBhZGQgc29tZSBpbmZvIHRvIHRoZSB0b3Bp YyBiZWxvdw0KDQpDb2hkYS9OWFAgYXJlIE5PVCBVTkVYIGJhc2VkLCBidXQgdXNlIHRoZWlyIG93 biBTb0MgaW5jbHVkaW5nIGVuaGFuY2VkIFBIWStNQUMgZm9yIGJldHRlciBlcnJvciB0b2xlcmFu Y2UgYXQgaGlnaCBzcGVlZC4gKHRoZSBzYW1lIGdvZXMgZm9yIEF1dG9UYWxrcykNCg0Kw5xkdsO2 emxldHRlbCAvIEJlc3QgcmVnYXJkcywNCsKgwqAgQW5kcsOhcyBWw6FyYWRpDQoNCsKgwqDCoMKg IFByb2plY3QgTWFuYWdlciA6OiBUZWNobmljYWwgQ3VzdG9tZXIgU3VwcG9ydA0KwqDCoMKgwqAg QXV0b21vdGl2ZSAmIFdMQU4gR3JvdXAgDQrCoMKgwqDCoCBsZXNzd2lyZcKgwqAgSHVuZ2FyeSB8 IE9mZmljZTogKzM2IDIzNTIxIDY2NyB8IEVtYWlsOiBWYXJhZGlAbGVzc3dpcmUuY29tIA0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpdHMtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJ1IFBldHJl c2N1DQpTZW50OiBUdWVzZGF5LCBKdW5lIDExLCAyMDEzIDI6NTEgUE0NClRvOiBpdHNAaWV0Zi5v cmcNClN1YmplY3Q6IFtpdHNdIFVwZGF0ZWQgbGlzdCBvZiBzdXBwbGllcnMgb2YgODAyLjExcC1j b21wYXRpYmxlIGVxdWlwbWVudA0KDQpIZWxsbyBwYXJ0aWNpcGFudHMgdG8gSVRTIGVtYWlsIGxp c3QsDQoNCkkgYWRkZWQgQXJhZGEgU3lzdGVtcyB0byB0aGUgbGlzdCBvZiBzdXBwbGllcnMgb2Yg ODAyLjExcC1jb21wYXRpYmxlIGVxdWlwbWVudC4gIEFkZGl0aW9uYWxseSwgSSBoYXZlIGJlZW4g cG9pbnRlZCB0aGF0IG1hbnkgaWYgbm90IGFsbCAoPykgdGhlc2Ugc3lzdGVtcyB1c2UgODAyLjEx cCBtaW5pUENJIGJvYXJkcyBmcm9tIFVORVguDQoNClRoZSBsaXN0IGlzIG5vdyB0aGUgZm9sbG93 aW5nOg0KDQpBcmFkYSBTeXN0ZW1zIExvY29NYXRlIE9CVQ0KUkVORVNBUyBFTEVDVFJPTklDUw0K TkVDDQpOWFAvQ29oZGEgV2lyZWxlc3MNCkNpc2NvL0NvaGRhIFdpcmVsZXNzDQpEZW5zbw0KRGVs cGhpDQpTYXZhcmkNCkthcHNjaA0KU2llbWVucw0KSVRSSQ0KQXV0b1RhbGtzDQpDb21tc2lnbmlh DQoNCllvdXJzLA0KDQpBbGV4DQoNCkxlIDE2LzA1LzIwMTMgMjA6MjMsIEFsZXhhbmRydSBQZXRy ZXNjdSBhIMOpY3JpdCA6DQo+IFllcywgdGhhbmsgeW91LiAgVGhlIGxpc3QgaXMgbm93Og0KPg0K PiBSRU5FU0FTIEVMRUNUUk9OSUNTDQo+IE5FQw0KPiBOWFAvQ29oZGEgV2lyZWxlc3MNCj4gQ2lz Y28vQ29oZGEgV2lyZWxlc3MNCj4gRGVuc28NCj4gRGVscGhpDQo+IFNhdmFyaQ0KPiBLYXBzY2gN Cj4gU2llbWVucw0KPiBJVFJJDQo+IEF1dG9UYWxrcw0KPiBDb21tc2lnbmlhDQo+DQo+IFlvdXJz LA0KPg0KPiBBbGV4DQo+DQo+IExlIDAzLzA1LzIwMTMgMTg6MzIsIExlbmFyZGksIE1hc3NpbWls aWFubyBhIMOpY3JpdCA6DQo+PiBEZWFyIEFsbCwNCj4+IHBsZWFzZSBhbHNvIGFkZCAgIFJFTkVT QVMgRUxFQ1RST05JQ1MgICB0byB0aGUgbGlzdCBiZWxvdyBvZiBwb3RlbnRpYWwNCj4+IHN1cHBs aWVycyBvZiAxMXAvRFNSQyBlbmFibGVkIHJhZGlvIGRldmljZXMuDQo+PiBCZXN0LA0KPj4gLQ0K Pj4gTWF4DQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBp dHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgDQo+PiBBbGV4YW5kcnUgUGV0cmVzY3UNCj4+IFNlbnQ6IDI0IEFwcmlsIDIwMTMgMTM6 NDkNCj4+IFRvOiBpdHNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbaXRzXSBzdXBwbGllcnMg b2YgODAyLjExcC1vdmVyLUlUUy1HNTsgDQo+PiA4MDIuMTFzLW92ZXItNTg3NS01OTA1TUh6DQo+ Pg0KPj4gUmVjZW50bHkgSSBkaXNjb3ZlcmVkIHRoYXQgaW4gYWRkaXRpb24gdG8gdGhlIHBvc3Rl ZCBsaXN0IHRoZXJlIGlzIA0KPj4gYWxzbyBDb21tc2lnbmlhIGFzIGEgbWFudWZhY3R1cmVyIG9m IDgwMi4xMXAgY29tcGF0aWJsZSBPQlUgYW5kIFJTVS4NCj4+IFRoZSBsaXN0IGlzIG5vdzoNCj4+ DQo+PiBORUMNCj4+IE5YUC9Db2hkYSBXaXJlbGVzcw0KPj4gQ2lzY28vQ29oZGEgV2lyZWxlc3MN Cj4+IERlbnNvDQo+PiBEZWxwaGkNCj4+IFNhdmFyaQ0KPj4gS2Fwc2NoDQo+PiBTaWVtZW5zDQo+ PiBJVFJJDQo+PiBBdXRvVGFsa3MNCj4+IENvbW1zaWduaWENCj4+DQo+PiBZb3VycywNCj4+DQo+ PiBBbGV4DQo+Pg0KPj4gTGUgMTYvMDIvMjAxMyAxMzoxOSwgQWxleGFuZHJ1IFBldHJlc2N1IGEg w6ljcml0IDoNCj4+PiBMZSAxMS8wMi8yMDEzIDE0OjUwLCBEb3dkZWxsLCBKb2huIGEgw6ljcml0 IDoNCj4+Pj4gQWxleA0KPj4+Pg0KPj4+PiBJcyBhbnlvbmUgbWFraW5nIDgwMi4xMXAgcmFkaW9z IGNvbW1lcmNpYWxseSBhdCByZWFzb25hYmxlIGNvc3Q/IA0KPj4+PiBUaGUgZmV3IEkgaGF2ZSBz ZWVuIHNlZW0gdG8gYmUgdmVyeSBleHBlbnNpdmUgKGZldyBrJCkgYW5kIHRoZXJlIA0KPj4+PiBh cHBlYXJzIHRvIGJlIGxpdHRsZSBzdXBwb3J0IGluIExpbnV4Lg0KPj4+DQo+Pj4gSm9obiwNCj4+ Pg0KPj4+IEEgcGVyc29uIHdhcyBraW5kIGVub3VnaCB0byBnYXRoZXIgaW4gb25lIHBsYWNlIGlu Zm9ybWF0aW9uIHdoaWNoIGlzIA0KPj4+IG90aGVyd2lzZSBzcGFyc2VseSBidXQgcHVibGljbHkg YXZhaWxhYmxlOyB0aGlzIGluZm9ybWF0aW9uIGlzIGFib3V0IA0KPj4+IHN1cHBsaWVycyBvZiA4 MDIuMTFwLW92ZXItSVRTLUc1IGZyZXF1ZW5jaWVzICg1ODc1LTU5MDVNSHosIA0KPj4+IDU4NTUt NTg3NU1IeiwgNTQ3MC01NzI1TUh6OyBjYXZlYXQgLSBvbmx5IHNvbWUgYXJlIGFsbG93ZWQgaW4g c29tZSANCj4+PiBjb3VudHJpZXMsIGNoZWNrIHRoZSBsb2NhbCByZWd1bGF0b3IgYmVmb3JlIHR1 cm5pbmcgdGhlc2Ugb24pLg0KPj4+DQo+Pj4gTkVDDQo+Pj4gTlhQL0NvaGRhIFdpcmVsZXNzDQo+ Pj4gQ2lzY28vQ29oZGEgV2lyZWxlc3MNCj4+PiBEZW5zbw0KPj4+IERlbHBoaQ0KPj4+IFNhdmFy aQ0KPj4+IEthcHNjaA0KPj4+IFNpZW1lbnMNCj4+PiBJVFJJDQo+Pj4gQXV0b1RhbGtzDQo+Pj4N Cj4+PiBJIGhhdmUgc29tZSBleHBlcmllbmNlIHdpdGggSVRSSSBlcXVpcG1lbnQuICBJbiB0aGVp ciBvZmZlciB0aGVyZSBpcyANCj4+PiBhIGZ1bGwtYmxvd24gUlNVLCBmb3IgYXJvdW5kIDE1MDBF VVIuICBUaGlzIGlzIGZvciBhIFJTVSBoYXJkZW5lZCANCj4+PiBib3ggZm9yIG91dGRvb3JzLCBw b3dlcnBjLCBHUFMtZW5hYmxlZCwgMnggODAyLjExcCBpbnRlcmZhY2VzLCANCj4+PiBFdGhlcm5l dCB3aXRoIFBvRSwgVVNCLCBhbmQgbGludXggMi42LiAgQW1vbmcgdGhlc2UsIGl0IGlzIHRoZSAN Cj4+PiBzb2Z0d2FyZSB3aGljaCBpcyBleHBlbnNpdmU7IHRoaXMgaW5jbHVkZXMgQXRoZXJvcyBk cml2ZXIgDQo+Pj4gbW9kaWZpY2F0aW9ucywgbmV3IGtlcm5lbCBtb2R1bGVzIGZvciAiQlRQIiAo QmFzZSBUcmFuc21pc3Npb24gDQo+Pj4gUHJvdG9jb2w/KSwgJ2dlb25ldHdvcmtpbmcnLCAnd2F2 ZScuDQo+Pj4NCj4+PiBPVGhlciB0aGFuIGEgZnVsbC1ibG93biBSU1UsIG9uZSBjb3VsZCBhY3F1 aXJlIGFsc28gSVRSSSBpbmRpdmlkdWFsIA0KPj4+ICc4MDIuMTFwJyBtaW5pUENJIGNhcmRzIHdo aWNoIGFyZSBpbiB0aGUgb3JkZXIgb2YgY291cGxlIGh1bmRyZWRzIG9mIA0KPj4+IGV1cm9zLg0K Pj4+DQo+Pj4gVGhpcyBpcyBub3QgYSBjb21tZXJjaWFsIGFkdmVydGlzZW1lbnQuICBUZWNobmlj YWxseSBzcGVha2luZyB0aGlzIA0KPj4+IG1lYW5zIG1hbnkgdGhpbmdzIGZvciBkZXNpZ25pbmcg cHJvdG9jb2xzLiAgRm9yIGV4YW1wbGU6DQo+Pj4NCj4+PiBJdCBtZWFucyBpdCBpcyBlYXNpbHkg cG9zc2libGUgdG8gcnVuIGxpbnV4IHdpdGggSVB2NiBvdmVyIGEgJ3dhdmUwJw0KPj4+IGludGVy ZmFjZS4gICBKdXN0IHR1cm4gaXQgb24sIHdhdGNoIHRoZSBJUHY2IGxpbmstbG9jYWwgYWRkcmVz cywgZWNobw0KPj4+IHRoZSBmcmVxdWVuY3kgdmFsdWUgYW5kIHBpbmcuIChubyBuZWVkIHRvIHNl dCBFU1NJRCwgbm9yIHNlY3VyaXR5KS4NCj4+Pg0KPj4+IEluIGFkZGl0aW9uIHRvIHRoZSBFdGhl cm5ldCBpbnRlcmZhY2VzLCB0aGUgUlNVIGhhcyBfMl8gODAyLjExcCANCj4+PiBkaWZmZXJlbnQg aW50ZXJmYWNlcywgYW5kIG9uZSBFdGhlcm5ldC4gIE5vdCBqdXN0IHR3byBhbnRlbm5hcywgYnV0 IA0KPj4+IHR3byBpbnRlcmZhY2VzIChpZmNvbmZpZyAnd2F2ZTAnIGFuZCAnd2F2ZTEnKS4gVGhp cyBtZWFucyBvbmUgDQo+Pj4gZG9lc24ndCBuZWVkIHRvICdyZWxheScgcGFja2V0cyBhbmQgdGhh dCBvbmUgbmVlZHMgdG8gJ3JvdXRlJyANCj4+PiBwYWNrZXRzLCBpbiB0aGUgdHJhZGl0aW9uYWwg c2Vuc2Ugb2YgJ3JvdXRpbmcnLiAgKGNvbXBhcmUgdGhpcyBmb3IgDQo+Pj4gZXhhbXBsZSB0byBS UEwgY29udGV4dCB3aGVyZSBhIHNlbnNvciBoYXMgYSBfc2luZ2xlXyBpbnRlcmZhY2UgYW5kIA0K Pj4+IHRoZXJlIGlzIG5vIHJvdXRpbmcsIGJ1dCAncmVsYXlpbmcnKS4NCj4+Pg0KPj4+IEFsc28g dGhpcyBvdXRkb29ycyBSU1UgaGFzIDEgR1BTIGFudGVubmEuICBUaGlzIG1lYW5zIHRoYXQgDQo+ Pj4gZ2VvbmV0d29ya2luZyBkb2VzIG5vdCB3b3JrIGlmIG9uZSB0cmllcyB0byB1c2UgdGhpcyBp bmRvb3JzIGluIGEgDQo+Pj4gbGFiIHdoZXJlIEdQUyBzaWduYWwgZG9lcyBub3QgcmVhY2guICh1 bmxlc3Mgb25lIGluc3RhbGxzIGEgR1BTICdyZXBlYXRlcicNCj4+PiAtIGVhc3kgdG8gZG8gYnV0 IGNoZWNrIHdpdGggcmVndWxhdG9yIGluIGNvdW50cnksIG9yIHVzZSBhIEdQUyANCj4+PiAncmVw bGF5ZXInIHNvZnR3YXJlIHRvIHBsYXkgcHJlLXJlY29yZGVkIE5NRUEgc2VudGVuY2VzIG9uIC9k ZXYvdHR5KS4NCj4+Pg0KPj4+IE5vdGUgYWxzbyBpdCBpcyBzdHJhbmdlIHRvIGRlc2lnbiBhbiBS U1UgUm9hZCBTaWRlIFVuaXQgLSBkZXNpZ25lZCANCj4+PiB0byBiZSBmaXhlZCB3aXRoIHJlc3Bl Y3QgdG8gRWFydGgsIGFuZCBwdXQgYSBHUFMgaW50ZXJmYWNlIG9uIGl0LiAgDQo+Pj4gSXQgd291 bGQgaGF2ZSBiZWVuIGVhc2llciB0byBqdXN0IHJlY29yZCB0aGUgR1BTIGNvb3JkaW5hdGVzIG9u Y2UgDQo+Pj4gYW5kIHNldCB0aGVtIGluIGEgZmlsZSBmb3IgYXMgbG9uZyBhcyB0aGF0IFJTVSBz dGF5cyB0aGVyZS4gIEkgDQo+Pj4gY29uc2lkZXIgaXQgYXMgYW4gZXh0cmEsIGJ1dCBjaGVhcGVy IFJTVSB3aXRob3V0IEdQUyBzaG91bGQgYmUgcG9zc2libGUuDQo+Pj4NCj4+Pj4gODAyLjExcyBv biB0aGUgb3RoZXIgaGFuZCBpcyBhdmFpbGFibGUgb24gc3RhbmRhcmQgV2ktRmkgZG9uZ2xlcyAN Cj4+Pj4gKGZyb20gJDE1KSBhbmQgZHJpdmVycyBhcmUgYWxyZWFkeSBhdmFpbGFibGUgaW4gTGlu dXguIElzIGl0IA0KPj4+PiBjb3JyZWN0IHRoYXQgODAyLjExcCBpcyBtYW5kYXRlZCBmb3IgSVRT IGluIHNvbWUgcmVnaW9ucz8NCj4+Pg0KPj4+IEkgZG91YnQgODAyLjExcCBiZSBtYW5kYXRlZCBm b3IgSVRTLg0KPj4+DQo+Pj4gSSB0aGluayB0aGUgcmVndWxhdG9yIG1hbmRhdGVzIHRoZSBhcHBs aWNhdGlvbiB3aGljaCBjb3VsZCBiZSB1c2VkIA0KPj4+IG9uIHNvbWUgZnJlcXVlbmNpZXMuDQo+ Pj4NCj4+PiBXaGVyZSBJIGxpdmUsIHRoZSByZWd1bGF0b3IgbWFuZGF0ZXMgdGhlIHVzZSBvZiB2 ZWhpY3VsYXIgJ3NhZmV0eScNCj4+PiBhcHBsaWNhdGlvbnMgYXQgNTg3NS01OTA1TUh6LiAgVGhl IHRlY2huaWNhbCAnY29uZGl0aW9ucycgYXJlIA0KPj4+IHJlZmVycmVkIGJ5IHRoZSByZWd1bGF0 b3IgdG8gRVRTSSBkb2N1bWVudHMgKHRoZSByZWd1bGF0b3IgaXMgbm90IA0KPj4+IEVUU0ksIGJ1 dCBvZnRlbiBpbXBsZW1lbnRzIHdoYXQgRVRTSSB3YW50cywgYnV0IG5vdCBhbHdheXMpLiAgSSAN Cj4+PiBkb3VidCB0aGUgcmVndWxhdG9yIG1hbmRhdGVzICdnZW9uZXR3b3JraW5nJyBmb3IgdGhp cyBiYW5kLg0KPj4+DQo+Pj4gSSBkb3VidCAnSVAnIGNvdWxkIGJlIHF1YWxpZmllZCBhcyAnc2Fm ZXR5Jy4NCj4+Pg0KPj4+IEhlbmNlIEkgdGhpbmsgODAyLjExcyBfY291bGRfIGJlIHVzZWQgb24g dGhlIHJhbmdlIDU4NzUtNTkwNU1IeiwgYXMgDQo+Pj4gbG9uZyBhcyBpdCBkb2VzIG5vdCB0cmFu c3BvcnQgSVAuDQo+Pj4NCj4+PiA4MDIuMTFwIGhhcyBzb21lIGZlYXR1cmVzIHdoaWNoIGNvdWxk IHF1YWxpZnkgYXMgJ3NhZmV0eScuICBGb3IgDQo+Pj4gZXhhbXBsZSwgaXQgaGFzIHNvbWUgTUFD LWxheWVyIG1lc3NhZ2VzIGZvciAnZW1lcmdlbmN5JywgYW5kIHdpdGggDQo+Pj4gdGltZXN0YW1w cyAoYWJzZW50IGZyb20gLjExIG5vbi1wIHN0YW5kYXJkKSwgd2hpY2ggZG9uJ3QgdHJhbnNwb3J0 IElQLg0KPj4+DQo+Pj4gJ2dlb25ldHdvcmtpbmcnIGFsc28gaGFzIHNvbWUgZmVhdHVyZXMgd2hp Y2ggY291bGQgcXVhbGlmeSBhcyAnc2FmZXR5Jy4NCj4+PiBJIGp1c3QgZG9uJ3QgcmVtZW1iZXIg d2hpY2guDQo+Pj4NCj4+PiBXaGF0IGZlYXR1cmVzIGluIDgwMi4xMXMgd291bGQgcXVhbGlmeSBh cyAnc2FmZXR5Jz8NCj4+Pg0KPj4+IEFsZXgNCj4+Pg0KPj4+Pg0KPj4+PiBKb2huDQo+Pj4+DQo+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IGl0cy1ib3VuY2VzQGlldGYub3Jn IA0KPj4+PiBbbWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFu ZHJ1IFBldHJlc2N1IFNlbnQ6DQo+Pj4+IDMxIEphbnVhcnkgMjAxMyAxNToxNyBUbzogaXRzQGll dGYub3JnIFN1YmplY3Q6IFJlOiBbaXRzXSBJUCBvdmVyIA0KPj4+PiA4MDIuMTFwDQo+Pj4+DQo+ Pj4+IExlIDMxLzAxLzIwMTMgMTQ6NDcsIFRoaWVycnkgRXJuc3QgYSDDqWNyaXQgOg0KPj4+Pj4N Cj4+Pj4+IFdlbGwsIHdlIGRvIGFjdHVhbGx5IHJ1biBJUHY2IG92ZXIgMTFwICh3aXRoIG9yIHdp dGhvdXQgDQo+Pj4+PiBHZW9OZXR3b3JraW5nKSwgc28gSSBkb24ndCBzZWUgd2hhdCBraW5kIG9m IGlzc3VlcyB0aGVyZSBtaWdodCBiZSANCj4+Pj4+IC4uLg0KPj4+Pg0KPj4+PiBJIGhhdmUgc29t ZSBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9ucyBhYm91dCBFdGhlclR5cGUgYW5kIDgwMi4xMXAgYW5k IA0KPj4+PiBHZW9OZXR3b3JraW5nLg0KPj4+Pg0KPj4+PiBJIGd1ZXNzIHdoZW4geW91IHJ1biBJ UHY2IG92ZXIgMTFwIHdpdGggR2VvTmV0d29ya2luZywgdGhlIEV0aGVybmV0IA0KPj4+PiBoZWFk ZXIgdXNlcyBFdGhlclR5cGUgc29vbi10by1iZS0weDg5NDcsIHdoZXJlYXMgd2hlbiB5b3UgcnVu IElQdjYgDQo+Pj4+IG92ZXIgMTFwIHdpdGhvdXQgR2VvTmV0d29ya2luZywgdGhlIEV0aGVybmV0 IGhlYWRlciB1c2VzIEV0aGVyVHlwZSANCj4+Pj4gMHg4NkRELiBUaGlzIGlzIGp1c3QgYSBzdXBw b3NpdGlvbiwgSSBkb24ndCBrbm93IGhvdyB5b3UgcnVuIGl0Lg0KPj4+Pg0KPj4+PiBBbHNvLCBp ZiBJIHJ1biBJUHY0IG92ZXIgMTFwIHdpdGggR2VvTmV0d29ya2luZyAtIHNob3VsZCBJIHVzZSAN Cj4+Pj4gRXRoZXJUeXBlIHNvb24tdG8tYmUtMHg4OTQ3PyAgT3Igb3RoZXI/ICBJIHN1cHBvc2Ug dGhhdCBpZiBJIHJ1biANCj4+Pj4gSVB2NCBvdmVyIDExcCB3aXRob3V0IEdlb05ldHdvcmtpbmcg SSBzaG91bGQgdXNlIEV0aGVyVHlwZSAweDA4MDAsIA0KPj4+PiBhbmQgaWYgaXQncyBBUlAgb3Zl ciA4MDIuMTFwIHN0aWxsIHdpdGhvdXQgR2VvTmV0d29ya2luZyB0aGVuIEkgDQo+Pj4+IHNob3Vs ZCB1c2UgRXRoZXJUeXBlIDB4MDgwNi4NCj4+Pj4NCj4+Pj4gKHRoZSBsZXR0ZXIgd2UndmUgc2Vl biByZWNlbnRseSBpcyBub3QgY2xlYXIgd2hldGhlciB0aGF0IA0KPj4+PiBhbGxvY2F0aW9uIGlz IGZvciBHZW9OZXR3b3JraW5nLCBmb3IgSVAtb3Zlci04MDIuMTFwLCBmb3IgRVRTSSBJVFMsIA0K Pj4+PiBmb3IgR2VvTmV0d29ya2luZyBmb3IgSVB2NiwgZm9yIEdlb05ldHdvcmtpbmcgZm9yIElQ djQsIGV0Yy4gIEl0IGlzIA0KPj4+PiBub3QgY2xlYXIgZWl0aGVyIHdoZXRoZXIgR2VvTmV0d29y a2luZyBzdXBwb3J0cyBJUHY0IG9yIG5vdCwgb3IgDQo+Pj4+IHVuZGVyIHdoYXQgZm9ybSkuDQo+ Pj4+DQo+Pj4+IEkgYWxzbyBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSByZWxhdGlvbnNo aXAgYmV0d2VlbiB0aGUgDQo+Pj4+IG5hdHVyZSBvZiBzb21lIDgwMi4xMXAgbGlua3MgKG5vIEVT U0lELCBhYnNlbmNlIG9mIGxpbmstbGF5ZXIgDQo+Pj4+IHNlY3VyaXR5IC0gYXMgb3Bwb3NlZCB0 byBXaUZpIHdoaWNoIGhhcyBFU1NJRCBhbmQgbGluay1sYXllciBzZWN1cml0eSkgYW5kIElQLg0K Pj4+Pg0KPj4+PiBGb3IgZXhhbXBsZSAtIHdpbGwgVjJWIHByZWZpeCBleGNoYW5nZSB1c2luZyBS b3V0ZXIgQWR2ZXJ0aXNlbWVudHMgDQo+Pj4+IHdvcmsgZWFzaWVyIG9uIDgwMi4xMXAgbGlua3Mg KGVhc2llciB0aGFuIG9uIFdpRmkpLCBiZWNhdXNlIHRoZSANCj4+Pj4gRVNTSUQgZG9lcyBub3Qg bmVlZCB0byBiZSBkaXNjb3ZlcmVkLCB0aGUgYWQtaG9jIG5ldHdvcmsgZG9lcyBub3QgDQo+Pj4+ IG5lZWQgdG8gYmUgZm9ybWVkIC0gc3VmZmljZXMgaXQgdG8gc2VuZCBwYWNrZXRzIG9uIGEgY2Vy dGFpbiBjaGFubmVsLg0KPj4+Pg0KPj4+PiAoaW4gYSBWMlYgZHJhZnQgb25lIHNlZW1zIHRvIHNh eSB0aGF0IHRoZSBwcmVzZW5jZSBvZiBBY2Nlc3MgUG9pbnQgDQo+Pj4+IGlzIGFic29sdXRlbHkg bmVjZXNzYXJ5IGluIG9yZGVyIGZvciA4MDIuMTFwIHRvIHdvcms7IGJ1dCBpbiBvdXIgDQo+Pj4+ IGV4cGVyaW1lbnRhdGlvbnMgdGhpcyBpcyBub3QgdGhlIGNhc2UgLSBpdCBpcyBwb3NzaWJsZSB0 byBlc3RhYmxpc2ggDQo+Pj4+IGRpcmVjdCB2ZWhpY2xlLXRvLXZlaGljbGUgSVAtb3Zlci04MDIu MTFwIGNvbW11bmljYXRpb25zIHdpdGhvdXQgDQo+Pj4+IHRoZSBwcmVzZW5jZSBvZiBhIGZpeGVk IDgwMi4xMXAgQWNjZXNzIFBvaW50KS4NCj4+Pj4NCj4+Pj4gRm9yIGFub3RoZXIgZXhhbXBsZSAt IHdpbGwgSVAgcHJlZmVyIHRoYXQgdGhlIDgwMi4xMXAgY2hhbm5lbCBpbiANCj4+Pj4gRnJhbmNl IGJlIDE3NiwgMTc4IG9yIDE4MD8gKHdpdGggV2lGaSwgSVAgZG9lcyBub3QgY2FyZSBiZWNhdXNl IGl0IA0KPj4+PiBjYW4gd29yayBvbiBhbnkgb2YgdGhlIDExIGNoYW5uZWxzIGVxdWFsbHkgd2Vs bCwgYnV0IHdpdGggODAyLjExcCANCj4+Pj4gZWFjaCBvZiB0aGVzZSB0aHJlZSBjaGFubmVscyBz ZWVtIHRvIGJlIHJlc2VydmVkIGZvciAiU2VydmljZXMiLCANCj4+Pj4gIkNvbnRyb2wiIGFuZCAi U2VydmljZXMiKS4NCj4+Pj4NCj4+Pj4gRm9yIGFub3RoZXIgZXhhbXBsZSAtIGlzIGFsbCB0aGUg c2VjdXJpdHkgb24gdGhlc2UgbGlua3MgZW50aXJlbHkgDQo+Pj4+IHJlbGF5aW5nIG9uIElQIGxh eWVyIHNlY3VyaXR5IChJUHNlYywgU2VORCwgRUFQLCBQQU5BKT8NCj4+Pj4NCj4+Pj4gSSB0aGlu ayBmaW5kaW5nIGNvbnNlbnN1cyBvbiBzb21lIG9mIHRoZXNlIHF1ZXN0aW9ucyBjb3VsZCBsZWFk IHRvIA0KPj4+PiBpbnRlcm9wZXJhYmlsaXR5Lg0KPj4+Pg0KPj4+PiBBbGV4DQo+Pj4+DQo+Pj4+ Pg0KPj4+Pj4gUmVnYXJkcywgVGhpZXJyeQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24g MzEvMDEvMTMgMTM6NTUsIEFsZXhhbmRydSBQZXRyZXNjdSB3cm90ZToNCj4+Pj4+PiBHaXZlbiBj dXJyZW50IGRpc2N1c3Npb25zLCBJIHRoaW5rIGl0IG1heSBiZSB3b3J0aCBjb25zaWRlcmluZyBh IA0KPj4+Pj4+IHdvcmsgaXRlbSBhYm91dCBob3cgdG8gcnVuIElQIG92ZXIgODAyLjExcC4NCj4+ Pj4+Pg0KPj4+Pj4+IE9uZSBvZiB0aGUgdGhpbmdzIHRvIHNheSB3b3VsZCBiZSB3aGV0aGVyIG9y IG5vdCB0aGlzIGlzIElQdjYgDQo+Pj4+Pj4gb25seSBvciBJUHY0IGFsc28uDQo+Pj4+Pj4NCj4+ Pj4+PiBUaGlzIHdvdWxkIHNheSBob3cgdGhpcyB3b3VsZCB3b3JrIF93aXRob3V0XyBHZW9OZXR3 b3JraW5nLg0KPj4+Pj4+DQo+Pj4+Pj4gSXQgd291bGQgYWdyZWUgb24gdGhlIEV0aGVyVHlwZSBh bmQvb3Igd2hldGhlciB0aGVyZSBhcmUgbmV3IA0KPj4+Pj4+IG9uZXMsIHNldmVyYWwgb3Igb25s eSBvbmUsIG9yIHJldXNpbmcgZXhpc3RpbmcgRXRoZXJUeXBlcy4NCj4+Pj4+Pg0KPj4+Pj4+IEl0 IGNvdWxkIGJlIGFzIHNpbXBsZSBhcyB0byBzYXkgdGhhdCBJUCB3b3JrcyBvdmVyIDgwMi4xMXAg anVzdCANCj4+Pj4+PiBhcyBpdCB3b3JrcyBvdmVyIDgwMi4xMWIgLSBubyBtb2RpZmljYXRpb25z Lg0KPj4+Pj4+DQo+Pj4+Pj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+Pj4+Pj4NCj4+Pj4+PiBBbGV4 DQo+Pj4+Pj4NCj4+Pj4+PiBMZSAzMC8wMS8yMDEzIDExOjEwLCBBbGV4YW5kcnUgUGV0cmVzY3Ug YSDDqWNyaXQgOg0KPj4+Pj4+PiBMZSAzMC8wMS8yMDEzIDExOjA0LCBSb21hc2NhbnUsIERhbiAo RGFuKSBhIMOpY3JpdCA6DQo+Pj4+Pj4+PiBIaSBBbGV4YW5kcnUsDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gSUVFRSB0YWxrIG9ubHkgaGV4YSBpbiB0aGVpciBFdGhlcnR5cGUgZmlsZXMuDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IEkgdGVuZCB0byBhZ3JlZSB0aGF0ICM4OTQ3IGlzIGEgaGV4YWRlY2ltYWwgbm90 YXRpb24gYWxzbyANCj4+Pj4+Pj4gYmVjYXVzZSB0aGUgc2hhcnAgc2lnbiBwcmVjZWRpbmcgaXQs IGFuZCBiZWNhdXNlIGlmIGl0IHdlcmUgDQo+Pj4+Pj4+IGRlY2ltYWwgaXQgd291bGQgY29udmVy dCB0byAyMkYzIHdoaWNoIGlzIGFscmVhZHkgcmVzZXJ2ZWQgZm9yIHRyaWxsLg0KPj4+Pj4+Pg0K Pj4+Pj4+PiBJIGp1c3Qgd2F0ZW5kIHRvIG1ha2Ugc3VyZS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQWxl eA0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gRGFuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IGl0cy1ib3VuY2VzQGlldGYub3JnIA0K Pj4+Pj4+Pj4+IFttYWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4 YW5kcnUgUGV0cmVzY3UNCj4+Pj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMzAsIDIw MTMgMTI6MDAgUE0gVG86DQo+Pj4+Pj4+Pj4gaXRzQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbaXRz XSBXaGF0IGRvIHdlIG5lZWQgdG8gbWFrZSBJVFMgV0cgDQo+Pj4+Pj4+Pj4gZ28gZm9yd2FyZD8g LSBFdGhlclR5cGUgZm9yIElUUw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSGVsbG8gRGFuLA0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhhbmsgeW91IGZvciB0aGUgZW1haWwuDQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+PiBJIHRoaW5rIHdlIGRlZmluaXRlbHkgbmVlZCBhIGdvb2QgaW50ZXJmYWNlIHdpdGgg SUVFRSBhYm91dCANCj4+Pj4+Pj4+PiB0aGlzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gTWF5YmUg eW91IGNvdWxkIGFzayB0aGVtIHdoZXRoZXIgdGhpcyBudW1iZXIgaXMgaGV4YSBvciANCj4+Pj4+ Pj4+PiBkZWNpbWFsLCBzbyB3ZSBrbm93IHdoYXQgdG8gcHV0IGluIGltcGxlbWVudGF0aW9uIChl LmcuDQo+Pj4+Pj4+Pj4gd2lyZXNoYXJrIHBhY2tldCBhbmFseXplcnMsIGFuZCA4MDIuMTFwL2V0 c2ktaXRzIA0KPj4+Pj4+Pj4+IGltcGxlbWVudGF0aW9ucykuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ PiBBbHNvLCBJIGFtIGludGVyZXN0ZWQgdG8gbGVhcm4gd2hldGhlciB0aGlzIGRlc2VydmVzIGJl aW5nIA0KPj4+Pj4+Pj4+IHJlc2VydmVkIGF0IElBTkEuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBB bGV4DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBMZSAzMC8wMS8yMDEzIDEwOjQ5LCBSb21hc2NhbnUs IERhbiAoRGFuKSBhIMOpY3JpdCA6DQo+Pj4+Pj4+Pj4+IEhpLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiBUaGUgZG9jdW1lbnRzIHRoYXQgeW91IGFyZSByZWZlcnJpbmcgKG9uIHRoZSBFVFNJDQo+ Pj4+Pj4+Pj4+IHNlcnZlcikgYXJlIG5vdCBmcmVlbHkgYWNjZXNzaWJsZS4gQSBwYXNzd29yZCBp cyByZXF1aXJlZCwgDQo+Pj4+Pj4+Pj4+IGFuZCBwcm9iYWJseSBvbmx5IEVUU0kgbWVtYmVycyBo YXZlIHRoZSBhY2Nlc3MgaW5mb3JtYXRpb24uDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRoZSBy ZXNwb25zaWJpbGl0eSBmb3IgYXNzaWduaW5nIEV0aGVyVHlwZSB2YWx1ZXMgaXMgd2l0aCB0aGUg DQo+Pj4+Pj4+Pj4+IElFRUUgUmVnaXN0cmF0aW9uIEF1dGhvcml0eS4gVGhleSBtYWludGFpbiBh IHB1YmxpYyBsaXN0IA0KPj4+Pj4+Pj4+PiAodXBkYXRlZCBkYWlseSkgYXQgDQo+Pj4+Pj4+Pj4+ IGh0dHA6Ly9zdGFuZGFyZHMuaWVlZS5vcmcvZGV2ZWxvcC9yZWdhdXRoL2V0aGVydHlwZS9ldGgu dHh0DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+DQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4gYW5kIGFjY29yZGluZyB0byB0aGlzIGxpc3QgdGhlIHZhbHVl IDg5NDcgaXMgbm90IGFsbG9jYXRlZC4NCj4+Pj4+Pj4+Pj4gTm93LCB0aGUgcHVibGljIGxpc3Rp bmcgaW5mb3JtYXRpb24gZm9yIEV0aGVyVHlwZXMgYmVhcnMgIGEgDQo+Pj4+Pj4+Pj4+IGRpc2Ns YWltZXIgdGhhdCBzYXlzDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICogVGhpcyBpcyBhIHBhcnRp YWwgbGlzdGluZyBvZiBhbGwgYXNzaWduZWQgRXRoZXJUeXBlIEZpZWxkcy4NCj4+Pj4+Pj4+Pj4g Tm90DQo+Pj4+Pj4+Pj4gYWxsDQo+Pj4+Pj4+Pj4+IHJlY2lwaWVudHMgd2lzaCB0byBwdWJsaXNo IHRoZWlyIGFzc2lnbm1lbnQgYXQgdGhpcyB0aW1lLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBE aWQgRVRTSSByZXF1aXJlIGZvciB0aGlzIGluZm9ybWF0aW9uIG5vdCB0byBiZSBwdWJsaXNoZWQ/ IEl0IA0KPj4+Pj4+Pj4+PiBkb2VzIG5vdCBsb29rIHVzZWZ1bCBpZiB0aGV5IHdhbnQgdG8gZW5j b3VyYWdlIA0KPj4+Pj4+Pj4+PiBpbnRlcm9wZXJhYmlsaXR5DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IFZhbHVlIDA3MDcgbWVudGlvbmVkIGluIHRoZSB0aHJlYWQgaXMgbm90IGFsbG9jYXRlZCBl aXRoZXIuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IExldCBtZSBrbm93IGlmIEkgY2FuIGhlbHAg KGFzIElFVEYgbGlhaXNvbiB0byB0aGUgSUVFRS1TQSkuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IERhbg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiAqRnJvbToqaXRzLWJvdW5jZXNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4gW21haWx0bzppdHMt Ym91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqVGhpZXJyeSBFcm5zdA0KPj4+Pj4+Pj4+ PiAqU2VudDoqIFdlZG5lc2RheSwgSmFudWFyeSAzMCwgMjAxMyAxMToxMSBBTSAqVG86KiANCj4+ Pj4+Pj4+Pj4gaXRzQGlldGYub3JnDQo+Pj4+Pj4+Pj4+ICpTdWJqZWN0OiogUmU6IFtpdHNdIFdo YXQgZG8gd2UgbmVlZCB0byBtYWtlIElUUyBXRyBnbyBmb3J3YXJkPw0KPj4+Pj4+Pj4+PiAtIEV0 aGVyVHlwZSBmb3IgSVRTDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEFsZXgs DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IElFRUUgaGF2ZSBhc3NpZ25lZCBFdGhlcm5ldCBUeXBl IEZpZWxkIG51bWJlciAjODk0NyBmb3IgSVRTIA0KPj4+Pj4+Pj4+PiB1c2UgKEVUU0kgVEMgSVRT J3MgR2VvTmV0d29ya2luZykuIENoZWNrIHRoZSBmb2xsb3dpbmcgDQo+Pj4+Pj4+Pj4+IGRvY3Vt ZW50IGF2YWlsYWJsZSBvbiB0aGUgRVRTSSBzZXJ2ZXI6DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ IElUUygxMykwMDAwMjANCj4+Pj4+Pj4+Pj4gPGh0dHA6Ly9kb2Nib3guZXRzaS5vcmcvSVRTL0lU Uy8wNS1DT05UUklCVVRJT05TLzIwMTMvSVRTJTI4MQ0KPj4+Pj4+Pj4+PiAzJQ0KPj4+Pj4+Pj4+ PiAyOTAwMDAyDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4NCj4+PiAwX0V0aGVybmV0X1R5cGVfRmllbGRfbnVtYmVyX2Zvcl9HZW9OZXR3b3JraW5nLnBk Zj4NCj4+Pj4+Pj4+Pj4gRXRoZXJuZXQgVHlwZSBGaWVsZCBudW1iZXIgZm9yIEdlb05ldHdvcmtp bmcNCj4+Pj4+Pj4+Pj4gaHR0cDovL2RvY2JveC5ldHNpLm9yZy9JVFMvSVRTLzA1LUNPTlRSSUJV VElPTlMvMjAxMy9JVFMoMTMpMA0KPj4+Pj4+Pj4+PiAwMA0KPj4+Pj4+Pj4+PiAwMjBfRXRoDQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+PiBlcm5l dF9UeXBlX0ZpZWxkX251bWJlcl9mb3JfR2VvTmV0d29ya2luZy5wZGYNCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4gUmVnYXJkcywgVGhpZXJyeS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4gT24gMjgvMDEvMTMgMTQ6MjgsIEFsZXhhbmRydSBQZXRyZXNjdSB3cm90ZToNCj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4gTGUgMjgvMDEvMjAxMyAxNDoxNiwgSm9lIEtsZWluIGEgw6ljcml0 IDoNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSSByZWFsbHkgZGlzbGlrZSB0aGUgZmFjdCB0aGF0 IElTTyBpcyBjaGFyZ2luZyBmb3IgdGhlIElTTw0KPj4+Pj4+Pj4+PiAyMTIxNyAtIEFyY2hpdGVj dHVyZSAmIElTTyAyMTIxMCAtIElQdjYgTmV0d29ya2luZy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4gRG9lcyB0aGlzIG1ha2UgaXQgYW55IGJldHRlcj8gU2FmZXI/ICBTaG91bGQgSVNPIG5vdyBo YXZlIA0KPj4+Pj4+Pj4+PiBjeWJlcnNlY3VyaXR5IGFuZCBzYWZldHkgbGlhYmlsaXR5IGlmIHRo ZSBzcGVjaWZpY2F0aW9uIGxlYWRzIA0KPj4+Pj4+Pj4+PiB0byBkZWF0aHMgYW5kIGRhbWFnZSB0 byBwcm9wZXJ0eT8NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gRG9lcyBpdCBt YWtlIGFueSBiZXR0ZXIgaW50ZXJvcGVyYWJsZSBhcyB3ZWxsPw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiBFdGhlclR5cGUgMHgwNzA3IGRlc2NyaWJlZCBpbiBJVFMgZG9jdW1lbnRzLCBpbXBsZW1l bnRlZCwgYnV0IA0KPj4+Pj4+Pj4+PiBub3Qgc3BlY2lmaWVkIGJ5IElFRUUgbm9yIHJlc2VydmVk IGF0IElBTkEgLSBkb2VzIG5vdCBtYWtlIGl0IA0KPj4+Pj4+Pj4+PiBpbnRlcm9wZXJhYmxlLg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBPbmUgd291bGRuJ3QgdGhpbmsgdGhhdCB0aGlzIDB4MDcw NyBldGhlcnR5cGUgYmUgcmVzZXJ2ZWQgYnkNCj4+Pj4+Pj4+PiBzb21lYm9keQ0KPj4+Pj4+Pj4+ PiB3aG8gaXMgbm90IElBTkEgbm9yIElFRUU/DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IChzZWUg YSBnb29kIGV4YW1wbGUgb2YgaW50ZXJvcGVyYWJpbGl0eTogSVB2NiAweDg2ZGQgDQo+Pj4+Pj4+ Pj4+IGV0aGVydHlwZSBpcyByZXNlcnZlZCBhdCBJRUVFIGFuZCBhdCBJQU5BDQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaWVlZS04MDItbnVt YmVycy9pZWVlLTgwMi1udW0NCj4+Pj4+Pj4+Pj4gYmUNCj4+Pj4+Pj4+Pj4gcnMueG1sKQ0KPj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ DQo+Pj4gQWxleA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBPciBzaG91bGQgdGhlc2Ugc3RhbmRh cmRzIHJlbWFpbiBpbg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiB0aGUgcHVibGljIGRvbWFpbiwg Zm9yIHJlc2VhcmNoZXMgdG8gcmV2aWV3IGFuZCB2YWxpZGF0ZT8NCj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4gSnVzdCBteSAyIGNlbnRzLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBKb2UNCj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gT24gTW9uLCBKYW4gMjgs IDIwMTMgYXQgNjozMSBBTSwgVGhpZXJyeSBFcm5zdCANCj4+Pj4+Pj4+Pj4gPHRoaWVycnkuZXJu c3RAaW5yaWEuZnI+IDxtYWlsdG86dGhpZXJyeS5lcm5zdEBpbnJpYS5mcj4NCj4+Pj4+Pj4+Pj4g d3JvdGU6DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IERlYXIgYWxsLA0KPj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBBdCB0aGlzIHN0YWdlLCBJIGRvbid0IHRoaW5rIGEgbmV3IHdv cmtpbmcgZ3JvdXAgaXMgbmVlZGVkLg0KPj4+Pj4+Pj4+PiBGaXJzdCwgaXQgd291bGQgbmVlZCBh IGNoYXJ0ZXIsIGFuZCBzdXBwb3J0IGZyb20gIHRoZSBpbmR1c3RyeS4NCj4+Pj4+Pj4+Pj4gQnV0 IG1vcmUgaW1wb3J0YW50bHksIElFVEYgV0dzIGFyZSBub3QgdXN1YWxseSBzZWN0b3ItZHJpdmVu LCANCj4+Pj4+Pj4+Pj4gc28gaXQgbWVhbnMgdGhlIGRpZmZlcmVudCBpc3N1ZXMgcGVydGFpbmlu ZyB0byBJVFMgc2hvdWxkIGJlIA0KPj4+Pj4+Pj4+PiBicm91Z2h0IHRvDQo+Pj4+Pj4+Pj4gVkFS SU9VUw0KPj4+Pj4+Pj4+PiBleGlzdGluZyBXR3MsIGFuZCBhIFdHIHNob3VsZCBvbmx5IGJlIGNy ZWF0ZWQgaWYgdGhlcmUgaXMgYW4gDQo+Pj4+Pj4+Pj4+IGltcG9ydGFudCBpc3N1ZSBmb3Igd2hp Y2ggdGhlcmUgaXMgbm8gZXhpc3RpbmcgV0cgdGhhdCBjb3VsZCANCj4+Pj4+Pj4+Pj4gd29yayBv biBpdC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVGhpcyBzYWlkLCBhcyBtZW50aW9uZWQgZWFy bGllciwgSVRTIGlzIG5vdCBvbmx5IGFib3V0IA0KPj4+Pj4+Pj4+PiB2ZWhpY3VsYXIgY29tbXVu aWNhdGlvbnMsIHRob3VnaCB0aGUgaXNzdWVzIGxpc3RlZCBieSANCj4+Pj4+Pj4+Pj4gQWxleGFu ZHJ1IGJlbG93IG1vc3RseSBjb25zaWRlciB2ZWhpY3VsYXIgY29tbXVuaWNhdGlvbnMuDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFdoYXQgSVRTIHJlYWxseSBuZWVkcyBpcyB0aGUgZGVmaW5pdGlv biBvZiBhIGNvbW1vbiANCj4+Pj4+Pj4+Pj4gY29tbXVuaWNhdGlvbiBhcmNoaXRlY3R1cmUgYW5k IHRoZSBkZWZpbml0aW9uIG9mIHdoYXQgDQo+Pj4+Pj4+Pj4+IGZlYXR1cmVzIHNob3VsZCBiZSBj b21wcmlzZWQgZm9yIGFuIElQdjYgbmV0d29ya2luZyBzdGFjayANCj4+Pj4+Pj4+Pj4gZGVwbG95 ZWQgZm9yIElUUyB1c2UgY2FzZXMuIFRoaXMgY2Fubm90IGJlIGRvbmUgYXQgSUVURiwgYW5kIA0K Pj4+Pj4+Pj4+PiBhY3R1YWxseSBhbHJlYWR5IGV4aXN0cyBhdCBJU086IC0gSVNPIDIxMjE3IC0g QXJjaGl0ZWN0dXJlIC0gDQo+Pj4+Pj4+Pj4+IElTTyAyMTIxMCAtDQo+Pj4+Pj4+Pj4+IElQdjYg TmV0d29ya2luZw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBBcyBhbiBpbnB1dCB0byB0aGUgZGlz Y3Vzc2lvbiwgcGxlYXNlIGNvbnNpZGVyIHJlYWRpbmcgDQo+Pj4+Pj4+Pj4+IGRvY3VtZW50cyBE Mi4xIGFuZCBEMi4yIGF2YWlsYWJsZSBvbiB0aGUgSVRTU3Y2IHByb2plY3Qgd2ViDQo+Pj4+Pj4+ Pj4+IHBhZ2U6IGh0dHA6Ly93d3cuaXRzc3Y2LmV1L2RvY3VtZW50YXRpb24vIEQyLjIgcHJvdmlk ZXMgYW4gDQo+Pj4+Pj4+Pj4+IGFuYWx5c2lzIG9mIHRoZSBjdXJyZW50bHkgcHVibGlzaGVkIHZl cnNpb24gb2YgSVNPIDIxMjEwLCBidXQgDQo+Pj4+Pj4+Pj4+IG5ldyB3b3JrIGl0ZW1zIGhhdmUg YmVlbiBsYXVuY2hlZCBzaW5jZSB0aGVuIHRvIGFkZHJlc3MgDQo+Pj4+Pj4+Pj4+IHJlbWFpbmlu ZyBpc3N1ZXMuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFJlZ2FyZHMsIFRoaWVycnkuDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+IE9uIDI4LzAxLzEzIDExOjA4LCBBbGV4YW5kcnUgUGV0cmVzY3Ugd3JvdGU6DQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IExlIDI4LzAxLzIwMTMgMDU6MDIsIFN0 YW4gUmF0bGlmZiAoc3JhdGxpZmYpIGEgw6ljcml0IDoNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4gQWxsLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBUaGlzIGlzIGp1c3Qgb25l IG9waW5pb24sIGJ1dCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIHdoeSBJVFMgDQo+Pj4+Pj4+Pj4+ IHdvdWxkIG5lZWQgaXRzIG93biBJRVRGIGdyb3VwLiBUaGUgd29yayBoZXJlIGlzIHRoZSBzYW1l IA0KPj4+Pj4+Pj4+PiAoSU1PKSBhcyB3aGF0IGlzIHRha2luZyBwbGFjZSBpbiBNQU5FVC4gSSB3 b3VsZCB2b3RlIHRoYXQgDQo+Pj4+Pj4+Pj4+IHRoaXMgd29yayBiZSB0YWtlbiB1cCBpbiBNQU5F VC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gU3RhbiwN Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVGhhbmsgeW91IGZvciB0aGUgb2ZmZXIuICBJIGNvbnNp ZGVyZWQgdGhpcyBvZmZlciBzaW5jZSBzb21lIA0KPj4+Pj4+Pj4+PiB0aW1lLg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiBJIHRyeSB0byB1bmRlcnN0YW5kIHdoZXRoZXIgc29tZSBvZiB0aGVzZSBp dGVtcyBvbiB3aGljaCAgSSANCj4+Pj4+Pj4+Pj4gaGF2ZSBpbnRlcmVzdCBjb3VsZCBiZSBicm91 Z2h0IGluIGluIE1BTkVUIFdHOiAtIFYyViB1c2luZyANCj4+Pj4+Pj4+Pj4gcHJlZml4IGV4Y2hh bmdlIC0gVklOLWJhc2VkIElQIGFkZHJlc3Npbmcgc2NoZW1lIC0gIE5EIFByZWZpeCANCj4+Pj4+ Pj4+Pj4gRGVsZWdhdGlvbiAtIFBNSVAtYmFzZWQgbmV0d29yayBtb2JpbGl0eSAtDQo+Pj4+Pj4+ Pj4+IElQdjYgc2luZ2xlLWFkZHJlc3MgY29ubmVjaW9uICdzaGFyaW5nJyB3aXRoIGEgY2VsbHVs YXIgDQo+Pj4+Pj4+Pj4+IG9wZXJhdG9yIGFuZCBhIHZlaGljdWxhciBtb3ZpbmcgbmV0d29yayAo dHlwZSAnNjRzaGFyZScNCj4+Pj4+Pj4+Pj4gb2YgdjZvcHMpLiAtIERlZmF1bHQgUm91dGUgd2l0 aCBESENQdjYuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFBsZWFzZSBsZXQgbWUga25vdy4NCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gWW91cnMsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEFsZXgN Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gUmVnYXJkcywg U3Rhbg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBPbiBKYW4gMjYsIDIwMTMsIGF0IDk6MzQgQU0s IEFiZHVzc2FsYW0gQmFyeXVuIHdyb3RlOg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiBIaSBOYWJpbCwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSSB0aGluayB3ZSBhbHJlYWR5 IGRvbmUgc29tZSBzdGVwcyBidXQgbm90IHN1cmUgaG93IGZhciBub3cuIA0KPj4+Pj4+Pj4+PiBX ZSB3aWxsIG5lZWQgdG8gcHJvcG9zZSB0aGUgV0cgYW5kIHByb3ZpZGUgdGhlIFdHIGNoYXJ0ZXIs IGFzIA0KPj4+Pj4+Pj4+PiB1c2UgY2FzZXMgYW5kIHdvcmsgdG8gYmUgZG9uZSBpbiB0aGlzIGdy b3VwLg0KPj4+Pj4+Pj4+PiBUaGlzIGNoYXJ0ZXIgbmVlZHMgdG8gYmUgYXBwcm92ZWQgYnkgdGhl IElFU0cuIEkgaGF2ZSBub3QgDQo+Pj4+Pj4+Pj4+IGF0dGVuZGVkIHRoZSBsYXN0IG1lZXRpbmcg c28gbm90IHN1cmUgYWJvdXQgdGhlIHN0YXR1cyBub3csDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ IEFCDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE9uIDEvMjYvMTMsIE5hYmlsIEJlbmFtYXIgPGJl bmFtYXI3M0BnbWFpbC5jb20+IA0KPj4+Pj4+Pj4+PiA8bWFpbHRvOmJlbmFtYXI3M0BnbWFpbC5j b20+IHdyb3RlOg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBIaSBBbGwsDQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEknbSBzdGlsbCBpbnRlcmVzdGVkIGluIHRoaXMgbGlzdCBh bmQgd2FudCB0byBqb2luIHZvaWNlcyANCj4+Pj4+Pj4+Pj4gcHJldmlvdXNseSBoZWFyZCB0byBt YWtlIGl0IGEgd29ya2luZyBncm91cC4gU28gd2hhdCBzaG91bGQgDQo+Pj4+Pj4+Pj4+IHdlIGV4 YWN0bHkgZG8sIHRvIGFjaGlldmUgdGhpcyBnb2FsID8NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4gMjAxMy8xLzI2IEFiZHVzc2FsYW0gQmFyeXVuIDxhYmR1c3NhbGFtYmFyeXVu QGdtYWlsLmNvbT4gDQo+Pj4+Pj4+Pj4+IDxtYWlsdG86YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5j b20+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEhpIEFsbCwNCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gSSB3YXMgaW50ZXJlc3RlZCBpbiB0aGlzIGdyb3VwIGJ1dCBub3Qgc3Vy ZSB3aGVyZSBhcmUgd2UgIHNvIA0KPj4+Pj4+Pj4+PiBmYXIuIElzIHRoZXJlIHByb2dyZXNzLCBv ciBpcyB0aGVyZSBpc3N1ZXMvZWZmb3J0cyB0aGF0IG5lZWQgDQo+Pj4+Pj4+Pj4+IHRvIGJlIGNv bXBsZXRlZCBhbmQgdm9sdW50ZWVyZWQuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEFCIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGl0cyANCj4+Pj4+Pj4+ Pj4gbWFpbGluZyBsaXN0IGl0c0BpZXRmLm9yZyA8bWFpbHRvOml0c0BpZXRmLm9yZz4gDQo+Pj4+ Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tICog KiAq2KrYrdmK2KfYqtmKINiMICoqQ29yZGlhbGVtZW50LCBSZWdhcmRzKiAqICogKiAqICrZhtio 2YrZhCANCj4+Pj4+Pj4+Pj4g2KjZhti52YXYsdmITmFiaWwgQmVuYW1hciogUHJvZmVzc29yIG9m IGNvbXB1dGVyIHNjaWVuY2VzIA0KPj4+Pj4+Pj4+PiBTaW11bGF0aW9uIGFuZCBNb2RlbGlzYXRp b24gTGFib3JhdG9yeSBIdW1hbiBTY2llbmNlcyBGYWN1bHR5IA0KPj4+Pj4+Pj4+PiBvZiBNZWtu ZXMgTW91bGF5IElzbWFpbCogKlVuaXZlcnNpdHkqIE1la25lcywgTW9yb2NjbyAqR1NNOiAqIA0K Pj4+Pj4+Pj4+PiAqKyAyMTIgNg0KPj4+Pj4+Pj4+PiA3MDgzMjIzNiBodHRwOi8vbmFiaWxiZW5h bWFyLmNvbS8NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gKg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4+IC0tDQo+Pj4+Pj4+Pj4+IC0tLS0tLS0NCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+IC0tLS0t LS0tLS0NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gKg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IGl0cw0KPj4+ Pj4+Pj4+PiBtYWlsaW5nIGxpc3QgaXRzQGlldGYub3JnIDxtYWlsdG86aXRzQGlldGYub3JnPiAN Cj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRzDQo+Pj4+Pj4+Pj4gbWFpbGlu Zw0KPj4+Pj4+Pj4+PiBsaXN0IGl0c0BpZXRmLm9yZyA8bWFpbHRvOml0c0BpZXRmLm9yZz4gDQo+ Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGl0cw0KPj4+Pj4+Pj4+IG1haWxpbmcN Cj4+Pj4+Pj4+Pj4gbGlzdCBpdHNAaWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+IA0KPj4+ Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBpdHMgbWFpbGluZw0K Pj4+Pj4+Pj4+IGxpc3QNCj4+Pj4+Pj4+Pj4gaXRzQGlldGYub3JnIDxtYWlsdG86aXRzQGlldGYu b3JnPiANCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p dHMNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gaXRzIG1haWxpbmcgDQo+Pj4+Pj4+Pj4+IGxpc3QgaXRzQGlldGYu b3JnIDxtYWlsdG86aXRzQGlldGYub3JnPiANCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18gaXRzIG1haWxpbmcgDQo+Pj4+Pj4+Pj4+IGxpc3QgaXRzQGlldGYub3JnIDxtYWlsdG86 aXRzQGlldGYub3JnPiANCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pdHMNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRzIG1h aWxpbmcgDQo+Pj4+Pj4+Pj4+IGxpc3QgaXRzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IGl0cyBtYWlsaW5nIA0KPj4+Pj4+Pj4+IGxpc3QgaXRzQGlldGYub3JnIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGl0cyBtYWlsaW5n IGxpc3QgDQo+Pj4+Pj4+IGl0c0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2l0cw0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyBpdHMgbWFpbGluZyBsaXN0IA0KPj4+Pj4+IGl0 c0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gaXRzIG1haWxpbmcgbGlzdCANCj4+Pj4+IGl0c0BpZXRmLm9yZyBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4+Pj4NCj4+Pj4NCj4+Pj4N Cj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRz IG1haWxpbmcgbGlzdCANCj4+Pj4gaXRzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXRzIFRoZSANCj4+Pj4gaW5mb3JtYXRpb24gY29udGFpbmVkIHdpdGhp biB0aGlzIGUtbWFpbCBhbmQgYW55IGZpbGVzIGF0dGFjaGVkIHRvIA0KPj4+PiB0aGlzIGUtbWFp bCBpcyBwcml2YXRlIGFuZCBpbiBhZGRpdGlvbiBtYXkgaW5jbHVkZSBjb21tZXJjaWFsbHkgDQo+ Pj4+IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGFy ZSBmb3IgdGhlIA0KPj4+PiBpbnRlbmRlZCByZWNpcGllbnQgb25seSBhbmQgdGhlcmVmb3JlIGlm IHlvdSB3aXNoIHRvIGRpc2Nsb3NlIHRoZSANCj4+Pj4gaW5mb3JtYXRpb24gY29udGFpbmVkIHdp dGhpbiB0aGlzIGUtbWFpbCBvciBhdHRhY2hlZCBmaWxlcywgcGxlYXNlIA0KPj4+PiBjb250YWN0 IHRoZSBzZW5kZXIgcHJpb3IgdG8gYW55IHN1Y2ggZGlzY2xvc3VyZS4gSWYgeW91IGFyZSBub3Qg dGhlIA0KPj4+PiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9y IGRpc3RyaWJ1dGlvbiBpcyANCj4+Pj4gcHJvaGliaXRlZC4gUGxlYXNlIGFsc28gY29udGFjdCB0 aGUgc2VuZGVyIGFuZCBpbmZvcm0gdGhlbSBvZiB0aGUgDQo+Pj4+IGVycm9yIGFuZCBkZWxldGUg dGhlIGUtbWFpbCwgaW5jbHVkaW5nIGFueSBhdHRhY2hlZCBmaWxlcyBmcm9tIHlvdXIgDQo+Pj4+ IHN5c3RlbS4gQ2Fzc2lkaWFuIExpbWl0ZWQsIFJlZ2lzdGVyZWQgT2ZmaWNlIDogUXVhZHJhbnQg SG91c2UsIA0KPj4+PiBDZWx0aWMgU3ByaW5ncywgQ29lZGtlcm5ldywgTmV3cG9ydCwgTlAxMCA4 RlogQ29tcGFueSBObzogMDQxOTEwMzYgDQo+Pj4+IGh0dHA6Ly93d3cuY2Fzc2lkaWFuLmNvbQ0K Pj4+Pg0KPj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+IGl0cyBtYWlsaW5nIGxpc3QNCj4+PiBpdHNAaWV0Zi5vcmcN Cj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4NCj4+DQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gaXRz IG1haWxpbmcgbGlzdA0KPj4gaXRzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+PiAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KPj4NCj4+IEUtbWFpbCBDb25maWRlbnRpYWxpdHkgTm90aWNlIGFuZCBE aXNjbGFpbWVyLg0KPj4NCj4+IFRoaXMgZS1tYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCANCj4+IGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9y IHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIA0KPj4gdGhleSBh cmUgYWRkcmVzc2VkLiBBY2Nlc3MgdG8gdGhpcyBlLW1haWwgYnkgYW55b25lIGVsc2UgaXMgDQo+ PiB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCANCj4+IGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgYWN0aW9uIHRh a2VuIG9yIG9taXR0ZWQgdG8gYmUgdGFrZW4gaW4gDQo+PiByZWxpYW5jZSBvbiBpdCwgaXMgcHJv aGliaXRlZC4NCj4+IEUtbWFpbCBtZXNzYWdlcyBhcmUgbm90DQo+PiBuZWNlc3NhcmlseSBzZWN1 cmUuIEhpdGFjaGkgZG9lcyBub3QgYWNjZXB0IHJlc3BvbnNpYmlsaXR5IGZvciBhbnkgDQo+PiBj aGFuZ2VzIG1hZGUgdG8gdGhpcyBtZXNzYWdlIGFmdGVyIGl0IHdhcyBzZW50Lg0KPj4gSGl0YWNo aSBjaGVja3Mgb3V0Z29pbmcgZS1tYWlsIG1lc3NhZ2VzIGZvciB0aGUgcHJlc2VuY2Ugb2YgY29t cHV0ZXIgDQo+PiB2aXJ1c2VzLg0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+PiAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBpdHMgbWFpbGluZyBsaXN0DQo+PiBpdHNAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpdHMgbWFpbGluZyBs aXN0DQo+IGl0c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2l0cw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQppdHMgbWFpbGluZyBsaXN0DQppdHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXRzDQo= From alexandru.petrescu@gmail.com Mon Jun 17 06:00:02 2013 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 679D821F9BEB for ; Mon, 17 Jun 2013 06:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.582 X-Spam-Level: X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NznlU9vfU-jx for ; Mon, 17 Jun 2013 05:59:57 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0CF21F9BE5 for ; Mon, 17 Jun 2013 05:59:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5HCxsum014393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 17 Jun 2013 14:59:54 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5HCxr6V030047 for ; Mon, 17 Jun 2013 14:59:54 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.33]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5HCxn50009264 for ; Mon, 17 Jun 2013 14:59:53 +0200 Message-ID: <51BF0845.9090107@gmail.com> Date: Mon, 17 Jun 2013 14:59:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: multipart/mixed; boundary="------------060407080700010600090902" Subject: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:00:02 -0000 This is a multi-part message in MIME format. --------------060407080700010600090902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ITSers, In the current charter proposal (see attached), there is an area briefly described as "IPv6-based network-layer distribution of content in a geographic area." My interpretation is the following: This is a potential activity largely inspired from the geonetworking concept. A use case is a vehicle that sends content to entities situated in a particular geographical area. For example, advertise within a range of 5km that there is a traffic incident happening, and not beyond this 5km area. A potential implementation is to have an IPv6 multicast address that represents that particular geographical area. What do you think? Distribution of content in a geographic area is something else? Do you think RFC 5222 "LoST: A Location-to-Service Translation Protocol" may be relevant in this space? Yours, Alex --------------060407080700010600090902 Content-Type: text/plain; charset=windows-1252; name="its-11.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its-11.txt" Intelligent Transportation Systems at IETF Draft Charter Proposal May 29th, 2013 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: Informal Chairs: TBD TBD Assigned Area Director: TBD () Mailing list Address: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: http://www.ietf.org/mail-archive/web/its/current/maillist.html Additional web page http://www.lara.prd.fr/ietf-its Draft Charter Proposal: Context ------- Intelligent Transportation Systems (ITS) ITS is about extending the Internet to mobile vehicular platforms. These platforms include: vehicles and embedded devices (ruggedized units, actuators and sensors), mobile devices carried by passengers (tablets, smartphones) and fixed infrastructure units (Internet access points, charge stations, geo-broadcasting units). The entire system may be connected to the Internet with generic radio-WANs or radio-LANs specific to vehicular communications; in certain cases the vehicles are disconnected from the Internet yet may be inter-connected to each another, in an ad-hoc manner. Each moving vehicle may use disjoint heterogeneous radio systems (e.g. a vehicle employs two or more different radios which may be used simultaneously, or alternatively). They radios have the following characteristics: - lower capacity, higher noise than customary Internet plumbing. - presence of mission critical needs and safety applications. - stable in-vehicle network structure. - volatile topology as vehicles (and the routers they contain) move. An example scenario of vehicular communications is the following: an instrumented ambulance is connected to the Internet and offers access to individual equipments deployed in-vehicle; it moves through a traffic jam and may signal its direction by multicasting IP communication packets over IEEE 802.11p direct links, or it establishes direct subnets to vehicles to request their position. Other similar scenarios are described in a dedicated document. The areas addressed by the group are the following: (1) establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol, (2) layering of IPv6 over IEEE 802.11p communication technology and (3) IPv6-based network-layer distribution of content in a geographic area. For each of the three areas, security aspects will be considered: authenticity of routing message exchanges, influence of the absence of link-layer security of IEEE 802.11p, and security of multicast distribution. In each of these areas, the problem space will be identified in detail, in a dedicated draft. The problem will be expressed in terms of protocol behaviour and point precisely to the lack of feature or other breaking points. For the IP addressing and mobility aspects of in-vehicle subnetworks, single-subnet V2V, and single-subnet V2I, the WG will consider and if necessary, profile, existing IPv6 network protocols. The protocols considered are: MANET protocols, ICMPv6, MLDv2. Other higher layer protocols, although relevant to geo-localization, will be considered as a complete reuse (e.g. RFC 5222). Establishment of networking from vehicle to ground is considered achieved to a large extent, by using existing IPv6 protocols (Mobile IPv6). This would be out of scope of work. Several Standards Development Organizations outside IETF work towards developing protocols for vehicular communications, in a non overlapping manner. In some cases IP protocols are used for transport, in other cases IP protocols are modified for purposes particular to vehicular communications. The group ISO TC204 describes ITS station architecture, IPv6 networking and security, and optimizations. The group ETSI ITS describes IPv6 for networking in vehicles. IEEE TGp, AUTOSAR, GENIVI and IPSO describe other aspects of vehicular communications. When possible, liaisons will be established with these organizations. This group will survey these SDO's documents to identify how it relates to this group's work. Potential new work items ------------------------ The following potential work items exist: Scenarios and requirements for vehicular communications will be developed which introduce at IETF the terms V2V, V2I, V2R and intra-vehicular paradigms. Define various possible scenarios for IP vehicular communications and identify requirements that are essential to support the defined scenarios. Practices and gap analysis for IP vehicular communications: document practices for the deployment of existing IP protocols and identify any limitation of the existing IP protocols to fulfill the scenarios and requirements for IP vehicular communications. The use of IP over 802.11p - with or without intermediary layers, with or without modifications - will de described. One particular practice to document is the IP addressing architecture within a vehicle, between vehicles, and between vehicle and infrastructure: the preferred address auto-configuration methods, the requirements for address stability and scope of visibility (in-vehicle, to vehicles nearby, to infrastructure, to Internet, etc.) A problem statement draft should be written which documents the problem which is a real-world problem, points precisely to the protocols which may break, and may easily lead to a solution that can be designed in a straightforward manner. Milestones: Jul 2013 - Meet in Berlin Jul 2013 - Present drafts "Scenarios and Requirements for IP in Intelligent Transportation Systems", and Gap Analysis Jul 2013 - Present drafts on Route Exchange between vehicles Jul 2013 - Present MANET landscape for V2V2V Nov 2013 - Present status from ISO Nov 2013 - Present gap analysis and requirements Mar 2014 - Present problem statement Jul 2014 - Present solution drafts Nov 2014 - Present solution drafts --------------060407080700010600090902-- From william.d.ivancic@nasa.gov Mon Jun 17 06:13:43 2013 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 84C2321F9C23 for ; Mon, 17 Jun 2013 06:13:42 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrYnKmi53g+n for ; Mon, 17 Jun 2013 06:13:34 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id B322121F9C19 for ; Mon, 17 Jun 2013 06:13:34 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (NDJSPPT103.ndc.nasa.gov [198.117.1.197]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id B033D26003A; Mon, 17 Jun 2013 08:13:33 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r5HDDXUS031451; Mon, 17 Jun 2013 08:13:33 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Mon, 17 Jun 2013 08:13:33 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Alexandru Petrescu , "its@ietf.org" Date: Mon, 17 Jun 2013 08:13:20 -0500 Thread-Topic: [its] IP-based content distribution in geo area Thread-Index: Ac5rWpbSug0S+HMKTf+Cb+uHyJGNNQAAdkmL Message-ID: In-Reply-To: <51BF0845.9090107@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-17_02:2013-06-17, 2013-06-17, 1970-01-01 signatures=0 Subject: Re: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:13:43 -0000 I think you are best off letting the ICN research group handle this. If yo= u understand your use case, you might want to articulate that use case the th= e ICN research group. http://irtf.org/icnrg -- Will > From: Alexandru Petrescu > Date: Mon, 17 Jun 2013 07:59:49 -0500 > To: "its@ietf.org" > Subject: [its] IP-based content distribution in geo area >=20 > ITSers, >=20 > In the current charter proposal (see attached), there is an area briefly > described as "IPv6-based network-layer distribution of content in a > geographic area." >=20 > My interpretation is the following: >=20 > This is a potential activity largely inspired from the geonetworking > concept. A use case is a vehicle that sends content to entities > situated in a particular geographical area. For example, advertise > within a range of 5km that there is a traffic incident happening, and > not beyond this 5km area. >=20 > A potential implementation is to have an IPv6 multicast address that > represents that particular geographical area. >=20 > What do you think? >=20 > Distribution of content in a geographic area is something else? >=20 > Do you think > RFC 5222 "LoST: A Location-to-Service Translation Protocol" > may be relevant in this space? >=20 > Yours, >=20 > Alex From maxpassion@gmail.com Mon Jun 17 20:26:49 2013 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 D4BE421F9B29 for ; Mon, 17 Jun 2013 20:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ1Duxacz9u1 for ; Mon, 17 Jun 2013 20:26:49 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 44EDA21F8C40 for ; Mon, 17 Jun 2013 20:26:49 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id 12so2484196vbf.8 for ; Mon, 17 Jun 2013 20:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1z2Ex2qJ0nzPOYm1Yve9maoOadRw4VNjV+ln0Q0a8V0=; b=r2WJe7XTgEWgKxzvXvHngx+IUIsZHrX0L9gmDJTN6REOG20IKBfwCgqRR+FeM6XZ7j pGT6LYhwAaBUSOsay12niI3PbupI9Qk9DkeyRoA4U9ilZ3lIdAUXdAilauh6wowd7Qrh ocXEHjlejw0zxzTE2Ev8+k6PicK+TLyaYtKZbHlaRuYy82fhqEqvgkd5UeS2C88pJJTa fob/PrRHp0kRHteydgGJJ+AE73HlVn6daMV4buwHEKS4G7uoxHhogesJFjGPqnue5F4J Glz3zh/DiRIBUIYw2t3SQEet28TwPz+C2AOX9/NmcQYcSIZR/icKWWab+jecC5z7MeCx mLAA== MIME-Version: 1.0 X-Received: by 10.58.236.70 with SMTP id us6mr4475085vec.89.1371526008562; Mon, 17 Jun 2013 20:26:48 -0700 (PDT) Received: by 10.220.123.65 with HTTP; Mon, 17 Jun 2013 20:26:48 -0700 (PDT) In-Reply-To: <51BF0845.9090107@gmail.com> References: <51BF0845.9090107@gmail.com> Date: Tue, 18 Jun 2013 11:26:48 +0800 Message-ID: From: Liu Dapeng To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 03:26:49 -0000 Hi Alex, RFC 5222 specifies the mechanism of mapping a service identifier and location information to one or more service URIs. It does not provide the multicast mechanism that maybe needed in your use case. What do you think? thanks, Dapeng Liu 2013/6/17 Alexandru Petrescu : > ITSers, > > In the current charter proposal (see attached), there is an area briefly > described as "IPv6-based network-layer distribution of content in a > geographic area." > > My interpretation is the following: > > This is a potential activity largely inspired from the geonetworking > concept. A use case is a vehicle that sends content to entities > situated in a particular geographical area. For example, advertise > within a range of 5km that there is a traffic incident happening, and > not beyond this 5km area. > > A potential implementation is to have an IPv6 multicast address that > represents that particular geographical area. > > What do you think? > > Distribution of content in a geographic area is something else? > > Do you think > RFC 5222 "LoST: A Location-to-Service Translation Protocol" > may be relevant in this space? > > Yours, > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- ------ Best Regards, Dapeng Liu From alison@she-devel.com Tue Jun 18 00:03:07 2013 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 17B1521F99DC for ; Tue, 18 Jun 2013 00:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPS9YPmH-lGP for ; Tue, 18 Jun 2013 00:03:06 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 54E0521F9A6E for ; Tue, 18 Jun 2013 00:02:58 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so9218919iec.41 for ; Tue, 18 Jun 2013 00:02:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=4q8hDSL87k5BDWLNtdRNKiqelC6op5nbL4ajxEahMkM=; b=BJBwZE7IipGMTIVS2iAoG0z1mWxcJ5Xu2sDcmmwgvT5KA4oQlz4OGE4TxyTkcRt3jA iwhWoGWSESgsIF2ZKd0LFqZJUMmRAKhVHs08ZZriamNapfDbYgrvu4H0gADYHeAYUC1L ha13ClJe9dRFJcga87y84942j1cerYwJZJ/UUQgIYmUJpw47wrz1oalgjaxod/A+3EYD jidEnvS25JvxWJrJdAETZG4QPRVtjnAHn2iX4++8dTToQXtYrAmJrG1XxtDZ88NVS0Xj 2/sMYH8ah8lftpJPvNFyVcPWxbrpIKphJx4ZlbvzL9kTiq9boKMuKww8IFa7xKbkx4UG hpMg== MIME-Version: 1.0 X-Received: by 10.50.66.129 with SMTP id f1mr6820388igt.63.1371538978241; Tue, 18 Jun 2013 00:02:58 -0700 (PDT) Received: by 10.42.25.70 with HTTP; Tue, 18 Jun 2013 00:02:58 -0700 (PDT) Date: Tue, 18 Jun 2013 00:02:58 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlrEnyIMft0q6UFp2ryPM7ysK0RlwL13317YXOZl4wUDidl3nce2/1Ud8rVCsGAk73WPMaf Subject: Re: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 07:03:07 -0000 Alexandru asks: > In the current charter proposal (see attached), there is an area briefly > described as "IPv6-based network-layer distribution of content in a > geographic area." [ . . . ] > For example, advertise > within a range of 5km that there is a traffic incident happening, and > not beyond this 5km area. I thought that Safety Applications were supposed to be sent via IEEE-1609.3, the WAVE (Wireless Access in Vehicular Environment) Short Message Protocol, which is not IP at all? Or is that plan a North American one? Does E.U. plan on sending traffic safety messages over IPV6? Perhaps, Alexandru, you refer to traffic messages used by navigation systems sent over IPV6 to a local area of the kind exemplified by "The Boulevard has heavy traffic; 3rd street is alternate", as opposed to "Vehicle in your blind spot: do not change lanes!" which are sent by WSMP. -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou From alexandru.petrescu@gmail.com Tue Jun 18 07:50:35 2013 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 3267821F9EDD for ; Tue, 18 Jun 2013 07:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMgnyZ6ksXHp for ; Tue, 18 Jun 2013 07:50:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7A121E8088 for ; Tue, 18 Jun 2013 07:50:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5IEoRdj019806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jun 2013 16:50:27 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5IEoQon012173; Tue, 18 Jun 2013 16:50:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5IEoQOT008546; Tue, 18 Jun 2013 16:50:26 +0200 Message-ID: <51C073B2.8050606@gmail.com> Date: Tue, 18 Jun 2013 16:50:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Liu Dapeng References: <51BF0845.9090107@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" Subject: Re: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:50:35 -0000 Hi Dapeng, The IP multicast mechanism I was talking about came up in a discussion with Thierry. This may be indeed different than the mapping of a service identifier and location information into service URIs. Currently I do not have a clear view of this need, but it may change. Geonetworking is something considered as very promising vehicular technology at ETSI ITS, and it is not the only ETSI ITS need of IP networking. Thoughts? Alex Le 18/06/2013 05:26, Liu Dapeng a écrit : > Hi Alex, > > RFC 5222 specifies the mechanism of mapping a service identifier and > location information to one or more service URIs. It does not > provide the multicast mechanism that maybe needed in your use case. > What do you think? > > thanks, Dapeng Liu > > 2013/6/17 Alexandru Petrescu : >> ITSers, >> >> In the current charter proposal (see attached), there is an area >> briefly described as "IPv6-based network-layer distribution of >> content in a geographic area." >> >> My interpretation is the following: >> >> This is a potential activity largely inspired from the >> geonetworking concept. A use case is a vehicle that sends content >> to entities situated in a particular geographical area. For >> example, advertise within a range of 5km that there is a traffic >> incident happening, and not beyond this 5km area. >> >> A potential implementation is to have an IPv6 multicast address >> that represents that particular geographical area. >> >> What do you think? >> >> Distribution of content in a geographic area is something else? >> >> Do you think RFC 5222 "LoST: A Location-to-Service Translation >> Protocol" may be relevant in this space? >> >> Yours, >> >> Alex >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > > From alexandru.petrescu@gmail.com Tue Jun 18 08:11:28 2013 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 DFD1221F991E for ; Tue, 18 Jun 2013 08:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I032scLpcEzm for ; Tue, 18 Jun 2013 08:11:22 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 83A4321F94DF for ; Tue, 18 Jun 2013 08:11:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5IFBIj7009052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Jun 2013 17:11:19 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5IFBIol020603 for ; Tue, 18 Jun 2013 17:11:18 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5IFBAKi007666 for ; Tue, 18 Jun 2013 17:11:18 +0200 Message-ID: <51C0788E.6000107@gmail.com> Date: Tue, 18 Jun 2013 17:11:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 15:11:29 -0000 Alison, Thank you for the reply. Le 18/06/2013 09:02, Alison Chaiken a écrit : > Alexandru asks: >> In the current charter proposal (see attached), there is an area >> briefly described as "IPv6-based network-layer distribution of >> content in a geographic area." > > [ . . . ] > >> For example, advertise within a range of 5km that there is a >> traffic incident happening, and not beyond this 5km area. > > I thought that Safety Applications were supposed to be sent via > IEEE-1609.3, the WAVE (Wireless Access in Vehicular Environment) > Short Message Protocol, which is not IP at all? I tend to agree. The document IEEE P1609.3 "Networking Services" does use some 'WaveShortMessage' which is not IP. I am not sure though whether that is a header over an IP packet or just a WSM without IP packet at all. > Or is that plan a North American one? Does E.U. plan on sending > traffic safety messages over IPV6? I dont know. Maybe I shoudl ask whether the ETSI ITS Geonetworkign safety messages are sent as IPv6 packets. > Perhaps, Alexandru, you refer to traffic messages used by navigation > systems sent over IPV6 to a local area of the kind exemplified by > "The Boulevard has heavy traffic; 3rd street is alternate", as > opposed to "Vehicle in your blind spot: do not change lanes!" which > are sent by WSMP. The example use case 1 is that of the ambulance through a traffic jam signalling its presence within a limited area. The 2nd is the crash data sent by the crashing vehicles to the vehicles surrounding them in a given range. Alex From jkenney@us.toyota-itc.com Tue Jun 18 16:17:35 2013 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 0EE1A21E809B for ; Tue, 18 Jun 2013 16:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6y--BOg0IAm for ; Tue, 18 Jun 2013 16:17:30 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with SMTP id 12E5121F896D for ; Tue, 18 Jun 2013 16:17:29 -0700 (PDT) Received: from mail-pb0-f52.google.com ([209.85.160.52]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUcDqiW3CliGbcrlEWgdrKUEmK/7Q2hyN@postini.com; Tue, 18 Jun 2013 16:17:30 PDT Received: by mail-pb0-f52.google.com with SMTP id xa12so4397282pbc.11 for ; Tue, 18 Jun 2013 16:17:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=L+dNX+Khm7OsJMWFwcih6fBHoQGSazsv4lDpA619bqQ=; b=JKRUZFvZlEJVBLmFdfv/e/AI8N2tTKKEW7Ku1lgJyZNdwLJqoOA5eQNNFov9HM+Pym mnmhCH1LTaoHXzTXPswsGngvObOiYoWUU8q4TjJzoe8h2+zAzw+IhotdgjSUZEPdeD98 asVUjB8tkh+arp8VjbAtxOPlL2CqNvuVhw2P4Y5P00o08bKFWR+ArwD/63xRDKEB3SSs fvqfQkP0xisnAhKUku6qwVEoA0rbqYwnZO3DaK2p7mvVKT2w0pHjSBMm+23I6RS+/AtH aiHQPLNesFFJ95FWNNLqGvegj4dtoiFYtds+I/MaddLw5znpztmVo4nc885d5HB0hScf md9Q== X-Received: by 10.66.218.168 with SMTP id ph8mr3826605pac.47.1371597449034; Tue, 18 Jun 2013 16:17:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.218.168 with SMTP id ph8mr3826600pac.47.1371597448907; Tue, 18 Jun 2013 16:17:28 -0700 (PDT) Received: by 10.68.222.197 with HTTP; Tue, 18 Jun 2013 16:17:28 -0700 (PDT) In-Reply-To: <51C0788E.6000107@gmail.com> References: <51C0788E.6000107@gmail.com> Date: Tue, 18 Jun 2013 16:17:28 -0700 Message-ID: From: John Kenney To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7b5d51b4b7a4e204df75eae6 X-Gm-Message-State: ALoCoQkdlg8UR0+Su+qnUZARMCFQqkUbUWguEYZFLoSrbIGc0xzCNa9F0cvPtslaHrLiqXIb6h521VLr3BHg+dyhW0bQBNcZQhYLm3vnuTNTwL0q1FlOun8K8gNKlPMfawnmVLctkqWO Cc: its@ietf.org Subject: Re: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:17:35 -0000 --047d7b5d51b4b7a4e204df75eae6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alexandru and Alison, In the US we haven't tackled multi-hop DSRC yet. For the two use cases you mention, emergency vehicle alert and crash data, I would expect WSMP to be a good candidate for the initial broadcast, which could be expected to cover a few hundred meters. If dissemination beyond that were desirable, it could use a TBD DSRC-specific multi-hop forwarding protocol like ETSI GeoNetworking, or something else (including IP). Also, to answer another question, WSMP is a lightweight Network & Transport protocol, not a shim header on top of IP. Best Regards, John On Tue, Jun 18, 2013 at 8:11 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Alison, > > Thank you for the reply. > > Le 18/06/2013 09:02, Alison Chaiken a =E9crit : > > Alexandru asks: >> >>> In the current charter proposal (see attached), there is an area >>> briefly described as "IPv6-based network-layer distribution of >>> content in a geographic area." >>> >> >> [ . . . ] >> >> For example, advertise within a range of 5km that there is a >>> traffic incident happening, and not beyond this 5km area. >>> >> >> I thought that Safety Applications were supposed to be sent via >> IEEE-1609.3, the WAVE (Wireless Access in Vehicular Environment) >> Short Message Protocol, which is not IP at all? >> > > I tend to agree. The document IEEE P1609.3 "Networking Services" does > use some 'WaveShortMessage' which is not IP. I am not sure though > whether that is a header over an IP packet or just a WSM without IP > packet at all. > > > Or is that plan a North American one? Does E.U. plan on sending >> traffic safety messages over IPV6? >> > > I dont know. Maybe I shoudl ask whether the ETSI ITS Geonetworkign > safety messages are sent as IPv6 packets. > > > Perhaps, Alexandru, you refer to traffic messages used by navigation >> systems sent over IPV6 to a local area of the kind exemplified by >> "The Boulevard has heavy traffic; 3rd street is alternate", as >> opposed to "Vehicle in your blind spot: do not change lanes!" which >> are sent by WSMP. >> > > The example use case 1 is that of the ambulance through a traffic jam > signalling its presence within a limited area. The 2nd is the crash > data sent by the crashing vehicles to the vehicles surrounding them in a > given range. > > Alex > > > ______________________________**_________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/**listinfo/its > --=20 John Kenney Sr. Research Manager Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --047d7b5d51b4b7a4e204df75eae6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alexandru and Alison,
=A0
In the US we haven= 9;t tackled multi-hop DSRC yet.=A0 For the two use cases you mention, emerg= ency vehicle alert and crash data, I would expect WSMP to be a good candida= te for the initial broadcast, which could be expected to cover a few hundre= d meters. If dissemination beyond that were desirable, it could use a TBD D= SRC-specific multi-hop forwarding protocol like ETSI GeoNetworking, or some= thing else (including IP).=A0
=A0
Also, to answer another question, WSMP is a lightweight = Network & Transport protocol, not a shim header on top of IP.
=A0
Best Regards,
John
=A0
On Tue, Jun 18, 2013 at 8:11 AM, Alexandru Petrescu <<= a href=3D"mailto:alexandru.petrescu@gmail.com" target=3D"_blank">alexandru.= petrescu@gmail.com> wrote:
Alison,

Thank you for the reply.

Le 18/06/2013 09:02, Alison Chaiken a =E9crit :

Alexandru asks:
In the current charter proposal (see attached), there is an area
briefly described as "IPv6-based network-layer distribution of
content in a geographic area."

[ . =A0. =A0. ]

For example, advertise within a range of 5km that there is a
traffic incident happening, and not beyond this 5km area.

I thought that Safety Applications were supposed to be sent via
IEEE-1609.3, the WAVE (Wireless Access in Vehicular Environment)
Short Message Protocol, which is not IP at all?

I tend to agree. The document IEEE P1609.3 "Networking Services" = does
use some 'WaveShortMessage' which is not IP. =A0I am not sure thoug= h
whether that is a header over an IP packet or just a WSM without IP
packet at all.


Or is that plan a North American one? =A0 Does E.U. plan on sending
traffic safety messages over IPV6?

I dont know. =A0Maybe I shoudl ask whether the ETSI ITS Geonetworkign
safety messages are sent as IPv6 packets.


Perhaps, Alexandru, you refer to traffic messages used by navigation
systems sent over IPV6 to a local area of the kind exemplified by
"The Boulevard has heavy traffic; 3rd street is alternate", as opposed to "Vehicle in your blind spot: do not change lanes!" whi= ch
are sent by WSMP.

The example use case 1 is that of the ambulance through a traffic jam
signalling its presence within a limited area. =A0The 2nd is the crash
data sent by the crashing vehicles to the vehicles surrounding them in a given range.

Alex


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



--
John K= enney
Sr. Research Manager
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--047d7b5d51b4b7a4e204df75eae6-- From buddenbergr@gmail.com Tue Jun 18 16:21:24 2013 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 523CC21F997A for ; Tue, 18 Jun 2013 16:21:24 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1szJPuXVFzI for ; Tue, 18 Jun 2013 16:21:23 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A1A9B21F92B8 for ; Tue, 18 Jun 2013 16:21:23 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so4430708pbb.28 for ; Tue, 18 Jun 2013 16:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=bUWf3uCXtXQ0tUFI19O4gt3JhQb3bHBemSaMLg1dpRY=; b=WRzO9WS7eaqAFQpzsT8Fr+f/ODFkuMVDfi4ahd3AWMxmx333+ap5OrWO5qBmjmHKCZ tqu9k3XJbU5OMsKZMMU0Jz3KA03rn+//1W/koANcZrEStFCGzBrImWUNZmR/SPkU2yO+ hdTphGpn0PKwQUc9tBIRsbNxkkkyJs9IuS4vK0Ggdw5Ejg8G6Iwn+q7zM+3MI9O+pIls 3W5U7wX6X51ce7IDMDnq3kGV2pGJzXOxNpSJIprStcBjmZkwdKxjom3Z3PVCWset04RF rW9IFcDfB4GeHAMsetuxQ3uJhy9uGgkzO8Z13YtVUvmxGxBY/4MTqZw+t75+FWnKrB6W 8WGw== X-Received: by 10.66.87.5 with SMTP id t5mr4087298paz.169.1371597683090; Tue, 18 Jun 2013 16:21:23 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id vv6sm21693151pab.6.2013.06.18.16.21.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 18 Jun 2013 16:21:22 -0700 (PDT) Message-ID: <1371597680.1844.143.camel@localhost> From: Rex Buddenberg To: Alison Chaiken Date: Tue, 18 Jun 2013 16:21:20 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:21:24 -0000 Allison, What is status of the IEEE 1609 set of standards? The Google stuff I could unearth shows activity around 2007 with a finalized standard circa 2010 (2 years is normal in IEEE). After that, silence. Did the standards work crash? Did the uptake not happen? Or did all the troops quit talking and start building? What a sojourn through Google unearthed (in no particular order): - there do appear to be two layer 3 protocols -- IP and WSMP (WAVE short message protocol). As you noted. - the IP stack was indeed IPv6 copacetic, per briefing slides. Since the lower layers interface via LLC (passing payload and ethertype up from layer 2 to 3) this didn't trip any layer modularity alarms. - the layer 3 protocol notes mention IP (of course) but no routing information protocols (OSPF, OLSR, whatever). - comments on multicast are germane. The only support mechanism I saw in the Google sweep is UDP. I'd think reliable multicast would be an eventual requirement, if not an immediate one. Layer 3. The slides I found mentioned 'IP' but not multicast IP. Layer 4/5. No mention of reliable protocols ... haven't discovered NORM nor apparently the need for it. No mention, of course, of multicast apps, other than the use cases Alex had. This has been a problem in the wired internet: the infrastructure is largely capable of routing multicast, but there's no uptake and no apps that use it. To get multicast right, it has to be addressed at layers 2, 3, 4/5 and 6/7 and the industry is rather incomplete in this regard. - In what I found, the addressal of security was lacking. This is no surprise, but disappointing. And what there was was targeted at infrastructure protection, not content protection. No end system (WSMP emitters included) should emit data that lacks an authentication signature. (Use the use cases noted and consider if someone were injecting false messages like that into the net...) None of these are earth-shattering omissions; most can be grown into without truckloads (sorry) of rework. On Tue, 2013-06-18 at 00:02 -0700, Alison Chaiken wrote: > Alexandru asks: > > In the current charter proposal (see attached), there is an area briefly > > described as "IPv6-based network-layer distribution of content in a > > geographic area." > > [ . . . ] > > > For example, advertise > > within a range of 5km that there is a traffic incident happening, and > > not beyond this 5km area. > > I thought that Safety Applications were supposed to be sent via > IEEE-1609.3, the WAVE (Wireless Access in Vehicular Environment) Short > Message Protocol, which is not IP at all? Or is that plan a North > American one? Does E.U. plan on sending traffic safety messages over > IPV6? Perhaps, Alexandru, you refer to traffic messages used by > navigation systems sent over IPV6 to a local area of the kind > exemplified by "The Boulevard has heavy traffic; 3rd street is > alternate", as opposed to "Vehicle in your blind spot: do not change > lanes!" which are sent by WSMP. > From jkenney@us.toyota-itc.com Tue Jun 18 16:43:57 2013 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 3B09B21E809B for ; Tue, 18 Jun 2013 16:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.143 X-Spam-Level: X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsTK5HaqUNtJ for ; Tue, 18 Jun 2013 16:43:52 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with SMTP id 17ADC11E811A for ; Tue, 18 Jun 2013 16:43:51 -0700 (PDT) Received: from mail-pb0-f44.google.com ([209.85.160.44]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKUcDwtUZ3ELXmiEYhInwSxrr0bjShHR79@postini.com; Tue, 18 Jun 2013 16:43:52 PDT Received: by mail-pb0-f44.google.com with SMTP id uo1so4414061pbc.31 for ; Tue, 18 Jun 2013 16:43:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3IbwdjYC32pceDMBxDNWyK5RaqqaCw+J8KTmiPWpPcM=; b=lrZoFS75+lW8JCAGSugOm+fzj/MeaoYhear0v1dosZ23rCFWtNiiA+RG1dLjMTBWrn mtgAdDUOcoAdBanIj6gSr54SXdHMuamCbQpEZl47SvezjgQJU7gCev+/PUzyOS5Zz9Ct UB5PiMPwkgkqlRB/4ECcG0KKN7mLUAo+N5htjhcnTGGN22Xmd5IoIFuoyp3L+cBdjwZz jhMJTNtuZL8YK0pHgYYVHQXXug/Mum8DzyXFN0Ge5hBMJk0wajWy4zowSJTLFMmsqmwb NBR8HcU4k3GDoSiuLwZSbN8r+tW8ag/m7Abp4VtqIjPN/MWUf1H9dFfdV6N+cFiFznQV NMFg== X-Received: by 10.68.184.100 with SMTP id et4mr200255pbc.48.1371599028882; Tue, 18 Jun 2013 16:43:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.184.100 with SMTP id et4mr200244pbc.48.1371599028798; Tue, 18 Jun 2013 16:43:48 -0700 (PDT) Received: by 10.68.222.197 with HTTP; Tue, 18 Jun 2013 16:43:48 -0700 (PDT) In-Reply-To: <1371597680.1844.143.camel@localhost> References: <1371597680.1844.143.camel@localhost> Date: Tue, 18 Jun 2013 16:43:48 -0700 Message-ID: From: John Kenney To: Rex Buddenberg Content-Type: multipart/alternative; boundary=047d7bd76abae2da5904df76480a X-Gm-Message-State: ALoCoQkGgeVmEDFTdwpm14fYfAaVvZq/hDkzHvCCy7SWg+T5T89+ad0Tl3Ox2VvQ8RQ6EKF/sua0F3DG3FOgBvm1Aky2v2dVM4mFUXvL09NNyf0Wd3Tbe7vMRwbnk4PQsOQYzViYhSZg Cc: Alison Chaiken , its@ietf.org Subject: Re: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:43:57 -0000 --047d7bd76abae2da5904df76480a Content-Type: text/plain; charset=ISO-8859-1 Hi Rex, Not to preempt Alison's answer, but I'll give you my perspective as an active member of the IEEE 1609 WG. The status of the core 1609 standards is this: 1609.2 Security Services - published April 2013 1609.3 Networking Services (including WSMP and WAVE Service Advertisement) - published 2010 1609.4 Multi-Channel Operation - published 2010 1609.11 Electronic Payment Data Exchange - published 2010 1609.12 Identifier Allocations - published 2012 An informative "architecture" document, IEEE 1609.0, is in ballot and will likely be published around the end of this year. Note that 1609.1, a trial-use version of which was published in 2006, is not being used and will not be updated. The uptake is happening. These protocols (in particular the security authentication in 1609.2 and WSMP in 1609.3) have been implemented and are being tested in a year-long trial called Safety Pilot Model Deployment in Ann Arbor. http://www.umtri.umich.edu/divisionPage.php?pageID=505 Security is, thankfully, not lacking, but rather has been part of the solution from day 1 (see 1609.2) The WG is now considering some extensions and improvements, but the core functionality is stable. I hope that helps. Best Regards, John -- John Kenney Sr. Research Manager Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 On Tue, Jun 18, 2013 at 4:21 PM, Rex Buddenberg wrote: > Allison, > > What is status of the IEEE 1609 set of standards? The Google stuff I > could unearth shows activity around 2007 with a finalized standard circa > 2010 (2 years is normal in IEEE). After that, silence. Did the > standards work crash? Did the uptake not happen? Or did all the troops > quit talking and start building? > > > What a sojourn through Google unearthed (in no particular order): > - there do appear to be two layer 3 protocols -- IP and WSMP (WAVE > short message protocol). As you noted. > - the IP stack was indeed IPv6 copacetic, per briefing slides. Since > the lower layers interface via LLC (passing payload and ethertype up > from layer 2 to 3) this didn't trip any layer modularity alarms. > - the layer 3 protocol notes mention IP (of course) but no routing > information protocols (OSPF, OLSR, whatever). > - comments on multicast are germane. The only support mechanism I saw > in the Google sweep is UDP. I'd think reliable multicast would be an > eventual requirement, if not an immediate one. > Layer 3. The slides I found mentioned 'IP' but not multicast IP. > Layer 4/5. No mention of reliable protocols ... haven't discovered > NORM nor apparently the need for it. > No mention, of course, of multicast apps, other than the use cases > Alex had. This has been a problem in the wired internet: the > infrastructure is largely capable of routing multicast, but there's no > uptake and no apps that use it. To get multicast right, it has to be > addressed at layers 2, 3, 4/5 and 6/7 and the industry is rather > incomplete in this regard. > - In what I found, the addressal of security was lacking. This is no > surprise, but disappointing. And what there was was targeted at > infrastructure protection, not content protection. No end system (WSMP > emitters included) should emit data that lacks an authentication > signature. (Use the use cases noted and consider if someone were > injecting false messages like that into the net...) > > None of these are earth-shattering omissions; most can be grown into > without truckloads (sorry) of rework. > > > > On Tue, 2013-06-18 at 00:02 -0700, Alison Chaiken wrote: > > Alexandru asks: > > > In the current charter proposal (see attached), there is an area > briefly > > > described as "IPv6-based network-layer distribution of content in a > > > geographic area." > > > > [ . . . ] > > > > > For example, advertise > > > within a range of 5km that there is a traffic incident happening, and > > > not beyond this 5km area. > > > > I thought that Safety Applications were supposed to be sent via > > IEEE-1609.3, the WAVE (Wireless Access in Vehicular Environment) Short > > Message Protocol, which is not IP at all? Or is that plan a North > > American one? Does E.U. plan on sending traffic safety messages over > > IPV6? Perhaps, Alexandru, you refer to traffic messages used by > > navigation systems sent over IPV6 to a local area of the kind > > exemplified by "The Boulevard has heavy traffic; 3rd street is > > alternate", as opposed to "Vehicle in your blind spot: do not change > > lanes!" which are sent by WSMP. > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > --047d7bd76abae2da5904df76480a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Rex,
=A0
Not to preempt Alison's answer, bu= t I'll give you my perspective as an active member of the IEEE 1609 WG.= =A0
=A0
The status of the core 1609 standards is this:=
1609.2 Security Services=A0- published April 2013
1609.3 Net= working Services (including WSMP and WAVE Service Advertisement) - publishe= d 2010
1609.4 Multi-Channel Operation - published 2010
1609.11 Electronic Payment Data Exchange - published 2010
1609.12= Identifier Allocations - published 2012
=A0
An informa= tive "architecture" document, IEEE 1609.0, is in ballot and will = likely be published around the end of this year.
=A0
Note that 1609.1, a trial-use version of which was publi= shed in 2006, is not being used and will not be updated.
=A0
The uptake is happening.=A0 These protocols (in particular the securi= ty authentication in 1609.2 and WSMP in 1609.3) have been implemented and a= re being tested in a year-long trial called Safety Pilot Model Deployment i= n Ann Arbor.=A0 http://www.umtri.umich.edu/divisionPage.php?pageID=3D505
=A0
Security is, thankfully, not lacking, but rather has bee= n part of the solution from day 1 (see 1609.2)
=A0
The = WG is now considering some extensions and improvements, but the core functi= onality is stable.
=A0
I hope that helps.

Best Regards,
John

--
John Kenney
Sr. Research M= anager
Toyota InfoTechnology Center, USA
465 Bernardo A= venue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6= 644
On Tue, Jun 18, 2013 at 4:21 = PM, Rex Buddenberg <buddenbergr@gmail.com> wrote:
Allison,

What is status of the IEEE 1609 set of standards? =A0The Google stuff I
could unearth shows activity around 2007 with a finalized standard circa 2010 (2 years is normal in IEEE). =A0After that, silence. =A0Did the
standards work crash? =A0Did the uptake not happen? =A0Or did all the troop= s
quit talking and start building?


What a sojourn through Google unearthed (in no particular order):
=A0 - there do appear to be two layer 3 protocols -- IP and WSMP (WAVE
short message protocol). =A0As you noted.
=A0 - the IP stack was indeed IPv6 copacetic, per briefing slides. =A0Since=
the lower layers interface via LLC (passing payload and ethertype up
from layer 2 to 3) this didn't trip any layer modularity alarms.
=A0 - the layer 3 protocol notes mention IP (of course) but no routing
information protocols (OSPF, OLSR, whatever).
=A0 - comments on multicast are germane. =A0The only support mechanism I sa= w
in the Google sweep is UDP. =A0I'd think reliable multicast would be an=
eventual requirement, if not an immediate one.
=A0 =A0 =A0Layer 3. =A0The slides I found mentioned 'IP' but not mu= lticast IP.
=A0 =A0 =A0Layer 4/5. =A0No mention of reliable protocols ... haven't d= iscovered
NORM nor apparently the need for it.
=A0 =A0 =A0No mention, of course, of multicast apps, other than the use cas= es
Alex had. =A0This has been a problem in the wired internet: the
infrastructure is largely capable of routing multicast, but there's no<= br> uptake and no apps that use it. =A0To get multicast right, it has to be
addressed at layers 2, 3, 4/5 and 6/7 and the industry is rather
incomplete in this regard.
=A0 - In what I found, the addressal of security was lacking. =A0This is no=
surprise, but disappointing. =A0And what there was was targeted at
infrastructure protection, not content protection. =A0No end system (WSMP emitters included) should emit data that lacks an authentication
signature. =A0(Use the use cases noted and consider if someone were
injecting false messages like that into the net...)

None of these are earth-shattering omissions; most can be grown into
without truckloads (sorry) of rework.



On Tue, 2013-06-18 at 00:02 -0700, Alison Chaiken wrote:
> Alexandru asks:
> > In the current charter proposal (see attached), there is an area = briefly
> > described as "IPv6-based network-layer distribution of conte= nt in a
> > geographic area."
>
> [ . =A0. =A0. ]
>
> > For example, advertise
> > within a range of 5km that there is a traffic incident happening,= and
> > not beyond this 5km area.
>
> I thought that Safety Applications were supposed to be sent via
> IEEE-1609.3, the WAVE (Wireless Access in Vehicular Environment) Short=
> Message Protocol, which is not IP at all? =A0 =A0Or is that plan a Nor= th
> American one? =A0 Does E.U. plan on sending traffic safety messages ov= er
> IPV6? =A0 Perhaps, Alexandru, you refer to traffic messages used by > navigation systems sent over IPV6 to a local area of the kind
> exemplified by "The Boulevard has heavy traffic; 3rd street is > alternate", as opposed to "Vehicle in your blind spot: do no= t change
> lanes!" which are sent by WSMP.
>


_____________________________= __________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its

--047d7bd76abae2da5904df76480a-- From jkenney@us.toyota-itc.com Tue Jun 18 17:07:14 2013 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 4822B11E811A for ; Tue, 18 Jun 2013 17:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0TdPBx2mEK2 for ; Tue, 18 Jun 2013 17:07:09 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with SMTP id AC6BB21F9A7B for ; Tue, 18 Jun 2013 17:07:05 -0700 (PDT) Received: from mail-pd0-f176.google.com ([209.85.192.176]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUcD2GzS9pfMA0O8t05Eoc8QHtknH3rXL@postini.com; Tue, 18 Jun 2013 17:07:05 PDT Received: by mail-pd0-f176.google.com with SMTP id t12so4426097pdi.35 for ; Tue, 18 Jun 2013 17:06:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YC0li+6FoFcfm2ilAmkzg3qazL1GCj2FqXxdNw45378=; b=gDwIKZMVOLoHX48UgWGxN6byRkKrtCRBJQqhXABLwdRAF4quCDB86ilRK8LmUOmG2n h17e0s+NZZJ6sDLkhb792iJNf9r8G745tuLubZH86dSdShTTFEA7r0X63wHX3Ot57n5O b+NSdHAZjNKvO00a9Vn8yOmWTkfHZNP0NaXrHALyzbCgBV1h+2JRFmGVTxVx85ylbWXw kXysJEQGDMcVvnPvVVOIO+AGQEvDjoUbL8ECS1YZtpviE+zHevf9454JDyA3l7woeKUW 6sVTyujW3ORhOl44Hsdz8CCogbKQtyOLTt0sjzdpGiWvAa53RksJxM1MH9SI9SuJ/FAm WXSw== X-Received: by 10.68.243.40 with SMTP id wv8mr279506pbc.34.1371600408882; Tue, 18 Jun 2013 17:06:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.243.40 with SMTP id wv8mr279498pbc.34.1371600408790; Tue, 18 Jun 2013 17:06:48 -0700 (PDT) Received: by 10.68.222.197 with HTTP; Tue, 18 Jun 2013 17:06:48 -0700 (PDT) In-Reply-To: <51B84A51.6050602@gmail.com> References: <51B724C2.2010305@gmail.com> <12413.1370971600@sandelman.ca> <51B84A51.6050602@gmail.com> Date: Tue, 18 Jun 2013 17:06:48 -0700 Message-ID: From: John Kenney To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7b2e14eb23db0904df769bb2 X-Gm-Message-State: ALoCoQlhQlpDEaWRtIpWiDH/XiGKDD5KCafVhQlqJPLvMdt7ZX58pK5KmMo6GFpI6+rqQ5+o/1j73Y6GnbvF7uNPi4kf+d2RZHsI3MeDC4vb70gK+I0huEQFQXIhvDo3YcT4xzNFItbN Cc: Michael Richardson , "its@ietf.org" Subject: Re: [its] Potential modifications for IPv6-straight-over-802.11p (from IPv6-over-802.11) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 00:07:14 -0000 --047d7b2e14eb23db0904df769bb2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Just a small clarification that 802.11p does not require a timestamp to be sent. It defines an optional Timing Advertisement frame, but I'm not aware that it has been implemented. Most DSRC devices will get time estimates from GPS. Best Regards, John On Wed, Jun 12, 2013 at 3:15 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 11/06/2013 19:26, Michael Richardson a =E9crit : > > >> "Alexandru" =3D=3D Alexandru Petrescu >>>>>>> writes: >>>>>>> >>>>>> Alexandru> Hello participants to the ITS email list, >> >> Alexandru> The potential modifications on the use of IPv6 over >> 802.11p (beyond the Alexandru> way IPv6-over-80211 already works) may >> be: >> >> Alexandru> (1) issued by the fact that the BSSID is always 48 1 >> bits, >> >> that, from the IPv6-over-802.11 point of view, is a layer-2 issue. >> > > Yes, there's a layer 2 issue, and layer 3 may map to it. E.g. map an > IPv6 multicast address into a link-layer multicast address. > > It may be that the BSSID 48 1 bits (ff:ff:ff:ff:ff:ff) may be needed for > something that IP needs, at which time there would be a need for a > mapping method. > > > Alexandru> (2) on the NTP and/or frequency of RA for timestamps, >> because Alexandru> Timestamps are required by 802.11p for being in >> synch, >> >> I don't understand. >> > > By spec, 802.11p (as opposed to 802.11) needs to transmit periodically a > Timestamp. That is a link-layer message. Its goal is for the stations > around to synchronize their time. > > To program that in the 802.11p driver is difficult, because it is very > low level. I havent seen this Timestamp 802.11p message, despite having > access to some 802.11p stacks. > > But it may be easier to do it at IP layer. This could be done in > various ways: maybe have a timestamp field in a RA? (there isnt > currently any). Maybe have NTP protcol realize that? > > > Alexandru> (3) on MIB, because 802.11p has EDCA parameters for STA >> QoS. >> >> Maybe, but first, can you show me who has a MIB on client side 802.11 >> device? >> > > Good question - I dont know. I can only suppose there could exist. I > think MIBs exist on end nodes, not necessarily routers or managed access > points. > > > (11p has no access point...) >> > > Well yes, 11p does not have managed mode, nor adhoc mode, nor any > meaningful form of BSS. > > However, nothing stops somebody from putting a 802.11p and a Ethernet > interface on a Router. That is an Access Router. There are some > products on the market named RSU (Road-Side Unit) which are built that wa= y. > > The RSUs all send data on a particular frequency at 5.9GHz range, > without first forming a BSS. Everybody hears everybody else, and > everybody talks to everybody else. > > > Alexandru> (4) do ND security (or other layer?) because 802.11p does >> not do Alexandru> Authentication Req/Resp. >> >> seems like a layer-3 (IPv6) issue, not an IPv6-over-foo issue. >> > > Well, security being still important, the fact that 802.11p does not > have security (no Auth Req/Resp, no Probe Req/Resp, no Ass'n Req/Resp) > means that upper layer security is even more important than before. > > Before 802.11p, we were saying that ND security (e.g. SeND) may not be > needed because 802.11 already had WEP and WPA. But now, since 802.11p > does not have neither WEP nor WPA, ND security is even more important. > > The problem here is: which ND security? SeND? Other? > > > Alexandru> (5) have a means for a mobile node to distinguish between >> two different Alexandru> 802.11p Access Routers, because 802.11p >> works outside the context Alexandru> of an BSS. This would >> facilitate the handover procedure of Alexandru> protocol Mobile >> IPv6. >> >> I don't see how this has anything to do with anything. Mobile IPv6 >> cares about the IP address of Home Agents. >> > > By RFC, the movement detection of Mobile IPv6 relies on the comparison > of prefixes received in Router Advertisements. But in implementation, > often this detection is guided by the change in ESSID (provoke a > different Ass'n Req to a different ESSID, then receive RA, then compare > to old prefix). > > But with 802.11p we don't have Ass'n Req. Basically a Mobile Node > receives RAs from all other Access Routers who send RAs on that 5900MHz > frequency (802.11p is all 'outside a BSS'). With the current movement > detection of RFC Mobile IPv6 and without a BSS, it's hard for a Mobile > Node to detect movement consistently. The end result is that the Mobile > Node may choose the default route to an Access Router which may not > necessarily be the good one (not the closest, not the approaching, etc.). > > > Alexandru> - work 'outside a BSS', i.e. use the BSSID as 48 1 bits. >> This is Alexandru> present in every MAC header of data and control >> frames, in the field Alexandru> BSSID. It is not the dst MAC >> address. This may or may not have an Alexandru> influence on the way >> ND, ICMP and MLD use the multicast addresses Alexandru> (typically >> they assume 33::1 instead of 48 1s, but that's only for Alexandru> >> dst, BSSID being not used by these protocols). >> >> huh? The BSSID is not the MAC header. >> > > Right, the BSSID is in the 802.11 header (not the Ethernet header). > > It may be that this BSSID all 1s may not have any influence on IPv6. > > > Alex > > >> > > ______________________________**_________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/**listinfo/its > --=20 John Kenney Sr. Research Manager Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --047d7b2e14eb23db0904df769bb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
Just a small clarification that 802.11p does not require= a timestamp to be sent.=A0 It defines an optional Timing Advertisement fra= me, but I'm not aware that it has been implemented.=A0 Most DSRC device= s will get time estimates from GPS.=A0
=A0
Best Regards,
John
On Wed, Jun 12, 2013 at 3:15 AM, Alexandru Petrescu <= ;alexandr= u.petrescu@gmail.com> wrote:
Le 11/06/2013 19:26, Michael Richardson a =E9crit :


"Alexandru" =3D=3D Alexandru Petrescu
<alexa= ndru.petrescu@gmail.com> writes:
Alexandru> Hello participants to the ITS email list,

Alexandru> The potential modifications on the use of IPv6 over
802.11p (beyond the Alexandru> way IPv6-over-80211 already works) may be:

Alexandru> (1) issued by the fact that the BSSID is always 48 1
bits,

that, from the IPv6-over-802.11 point of view, is a layer-2 issue.

Yes, there's a layer 2 issue, and layer 3 may map to it. =A0E.g. map an=
IPv6 multicast address into a link-layer multicast address.

It may be that the BSSID 48 1 bits (ff:ff:ff:ff:ff:ff) may be needed for something that IP needs, at which time there would be a need for a
mapping method.


Alexandru> (2) on the NTP and/or frequency of RA for timestamps,
because Alexandru> Timestamps are required by 802.11p for being in
synch,

I don't understand.

By spec, 802.11p (as opposed to 802.11) needs to transmit periodically a Timestamp. =A0That is a link-layer message. =A0Its goal is for the stations=
around to synchronize their time.

To program that in the 802.11p driver is difficult, because it is very
low level. =A0I havent seen this Timestamp 802.11p message, despite having<= br> access to some 802.11p stacks.

But it may be easier to do it at IP layer. =A0This could be done in
various ways: maybe have a timestamp field in a RA? =A0(there isnt
currently any). =A0Maybe have NTP protcol realize that?

Alexandru> (3) on MIB, because 802.11p has EDCA parameters for STA
QoS.

Maybe, but first, can you show me who has a MIB on client side 802.11
device?

Good question - I dont know. =A0I can only suppose there could exist. =A0I<= br> think MIBs exist on end nodes, not necessarily routers or managed access points.


(11p has no access point...)

Well yes, 11p does not have managed mode, nor adhoc mode, nor any
meaningful form of BSS.

However, nothing stops somebody from putting a 802.11p and a Ethernet
interface on a Router. =A0That is an Access Router. =A0There are some
products on the market named RSU (Road-Side Unit) which are built that way.=

The RSUs all send data on a particular frequency at 5.9GHz range,
without first forming a BSS. =A0Everybody hears everybody else, and
everybody talks to everybody else.


Alexandru> (4) do ND security (or other layer?) because 802.11p does
not do Alexandru> Authentication Req/Resp.

seems like a layer-3 (IPv6) issue, not an IPv6-over-foo issue.

Well, security being still important, the fact that 802.11p does not
have security (no Auth Req/Resp, no Probe Req/Resp, no Ass'n Req/Resp)<= br> means that upper layer security is even more important than before.

Before 802.11p, we were saying that ND security (e.g. SeND) may not be
needed because 802.11 already had WEP and WPA. =A0But now, since 802.11p does not have neither WEP nor WPA, ND security is even more important.

The problem here is: which ND security? =A0SeND? =A0Other?


Alexandru> (5) have a means for a mobile node to distinguish between
two different Alexandru> 802.11p Access Routers, because 802.11p
works outside the context Alexandru> of an BSS. =A0This would
facilitate the handover procedure of Alexandru> protocol Mobile
IPv6.

I don't see how this has anything to do with anything. Mobile IPv6
cares about the IP address of Home Agents.

By RFC, the movement detection of Mobile IPv6 relies on the comparison
of prefixes received in Router Advertisements. =A0But in implementation, often this detection is guided by the change in ESSID (provoke a
different Ass'n Req to a different ESSID, then receive RA, then compare=
to old prefix).

But with 802.11p we don't have Ass'n Req. =A0Basically a Mobile Nod= e
receives RAs from all other Access Routers who send RAs on that 5900MHz
frequency (802.11p is all 'outside a BSS'). =A0With the current mov= ement
detection of RFC Mobile IPv6 and without a BSS, it's hard for a Mobile<= br> Node to detect movement consistently. =A0The end result is that the Mobile<= br> Node may choose the default route to an Access Router which may =A0not
necessarily be the good one (not the closest, not the approaching, etc.).

Alexandru> - work 'outside a BSS', i.e. use the BSSID as 48 1 bi= ts.
This is Alexandru> present in every MAC header of data and control
frames, in the field Alexandru> BSSID. =A0It is not the dst MAC
address. =A0This may or may not have an Alexandru> influence on the way<= br> ND, ICMP and MLD use the multicast addresses Alexandru> (typically
they assume 33::1 instead of 48 1s, but that's only for Alexandru> dst, BSSID being not used by these protocols).

huh? =A0The BSSID is not the MAC header.

Right, the BSSID is in the 802.11 header (not the Ethernet header).

It may be that this BSSID all 1s may not have any influence on IPv6.


Alex




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



--
John K= enney
Sr. Research Manager
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--047d7b2e14eb23db0904df769bb2-- From alison@she-devel.com Tue Jun 18 22:49:30 2013 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 22B3221F9E88 for ; Tue, 18 Jun 2013 22:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpJC0r27ZKrZ for ; Tue, 18 Jun 2013 22:49:28 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4A68021F9D0A for ; Tue, 18 Jun 2013 22:49:28 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so12194394iec.19 for ; Tue, 18 Jun 2013 22:49:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=qYCfBli8r7mdq3xEf2D5zJWJhrbmGsIIB5jkzgyh+Dk=; b=HpITAn9WKfANVzBm3V7J/j1LU04u47uVYClyUEAJ0kAzYgi/oG9p8R55X1WNJl1cnU fFXKHyMrFj4i7YvHZWVZ4+kTI5BUwi4y2FeNpXB9qbRu6PJ+Zfjyi1zzEQ4K/pE6K71/ TN0xH7Rz7N4FoGjjhlxMFufdI35y/hXMQDe1j61d6i15KNZ4R9gj0m4Sc18MWI0Hb/tx 7QdRYwW29Fqvo1wwa8NZODta0lyLKw/YlBlHUFSptuqnmZ8igkzS5+Q7WxX6TGftLW22 KT7NRBhknhnsp+wDRNcxRRO5SIQ1VWrCKlsff92mhmMpP8iA+/NBI6zzcpX3QC5X/mT5 EVmQ== MIME-Version: 1.0 X-Received: by 10.50.1.33 with SMTP id 1mr615705igj.33.1371620967586; Tue, 18 Jun 2013 22:49:27 -0700 (PDT) Received: by 10.42.25.70 with HTTP; Tue, 18 Jun 2013 22:49:27 -0700 (PDT) In-Reply-To: References: <1371597680.1844.143.camel@localhost> Date: Tue, 18 Jun 2013 22:49:27 -0700 Message-ID: From: Alison Chaiken To: John Kenney Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmcF+ZyiZkPEtcjqE+kYEU6HuYja4Jgzc9ujHXX9a4BG9yM0euavM+dawWwF+3WLVi7qHCK Cc: Rex Buddenberg , its@ietf.org Subject: Re: [its] IP-based content distribution in geo area X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 05:49:30 -0000 Thanks John for the authoritative response! Perhaps Hans-Joachim Fischer or Thierry Ernst could comment on the status of 1609.x at ETSI? I see the logo at http://its-standards.eu/ -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou From alexandru.petrescu@gmail.com Wed Jun 19 00:13:58 2013 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 2039221F9F7D for ; Wed, 19 Jun 2013 00:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMUajrE2jYMB for ; Wed, 19 Jun 2013 00:13:53 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9D16C21F9EA7 for ; Wed, 19 Jun 2013 00:13:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5J7DkFp023716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 09:13:46 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5J7DjHD002272; Wed, 19 Jun 2013 09:13:46 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5J7DVZs014023; Wed, 19 Jun 2013 09:13:45 +0200 Message-ID: <51C15A1B.8030901@gmail.com> Date: Wed, 19 Jun 2013 09:13:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Kenney References: <51B724C2.2010305@gmail.com> <12413.1370971600@sandelman.ca> <51B84A51.6050602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Michael Richardson , "its@ietf.org" Subject: Re: [its] Potential modifications for IPv6-straight-over-802.11p (from IPv6-over-802.11) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:13:58 -0000 Hi John, Thank you for the clarification on the absence of requirement for timestamp presence. Indeed, the 802.11p implementations I am aware of do not send that Timing Advertisement, nor any other periodic advertisements. (just that the ETSI ITS implementation sends a 1second periodic advertisement.) Getting time estimates from GPS is a good alternative, although not sure how well it would work in uncovered areas (e.g. tunnel). I can only suppose that 802.11p continues working in tunnels, underground, etc. and that its reliance on synchronized time is not critical. Alex Le 19/06/2013 02:06, John Kenney a écrit : > Hi, Just a small clarification that 802.11p does not require a > timestamp to be sent. It defines an optional Timing Advertisement > frame, but I'm not aware that it has been implemented. Most DSRC > devices will get time estimates from GPS. Best Regards, John On Wed, > Jun 12, 2013 at 3:15 AM, Alexandru Petrescu > > > wrote: > > Le 11/06/2013 19:26, Michael Richardson a écrit : > > > "Alexandru" == Alexandru Petrescu > writes: > > Alexandru> Hello participants to the ITS email list, > > Alexandru> The potential modifications on the use of IPv6 over > 802.11p (beyond the Alexandru> way IPv6-over-80211 already works) > may be: > > Alexandru> (1) issued by the fact that the BSSID is always 48 1 > bits, > > that, from the IPv6-over-802.11 point of view, is a layer-2 issue. > > > Yes, there's a layer 2 issue, and layer 3 may map to it. E.g. map > an IPv6 multicast address into a link-layer multicast address. > > It may be that the BSSID 48 1 bits (ff:ff:ff:ff:ff:ff) may be needed > for something that IP needs, at which time there would be a need for > a mapping method. > > > Alexandru> (2) on the NTP and/or frequency of RA for timestamps, > because Alexandru> Timestamps are required by 802.11p for being in > synch, > > I don't understand. > > > By spec, 802.11p (as opposed to 802.11) needs to transmit > periodically a Timestamp. That is a link-layer message. Its goal is > for the stations around to synchronize their time. > > To program that in the 802.11p driver is difficult, because it is > very low level. I havent seen this Timestamp 802.11p message, > despite having access to some 802.11p stacks. > > But it may be easier to do it at IP layer. This could be done in > various ways: maybe have a timestamp field in a RA? (there isnt > currently any). Maybe have NTP protcol realize that? > > > Alexandru> (3) on MIB, because 802.11p has EDCA parameters for STA > QoS. > > Maybe, but first, can you show me who has a MIB on client side > 802.11 device? > > > Good question - I dont know. I can only suppose there could exist. > I think MIBs exist on end nodes, not necessarily routers or managed > access points. > > > (11p has no access point...) > > > Well yes, 11p does not have managed mode, nor adhoc mode, nor any > meaningful form of BSS. > > However, nothing stops somebody from putting a 802.11p and a > Ethernet interface on a Router. That is an Access Router. There are > some products on the market named RSU (Road-Side Unit) which are > built that way. > > The RSUs all send data on a particular frequency at 5.9GHz range, > without first forming a BSS. Everybody hears everybody else, and > everybody talks to everybody else. > > > Alexandru> (4) do ND security (or other layer?) because 802.11p does > not do Alexandru> Authentication Req/Resp. > > seems like a layer-3 (IPv6) issue, not an IPv6-over-foo issue. > > > Well, security being still important, the fact that 802.11p does not > have security (no Auth Req/Resp, no Probe Req/Resp, no Ass'n > Req/Resp) means that upper layer security is even more important than > before. > > Before 802.11p, we were saying that ND security (e.g. SeND) may not > be needed because 802.11 already had WEP and WPA. But now, since > 802.11p does not have neither WEP nor WPA, ND security is even more > important. > > The problem here is: which ND security? SeND? Other? > > > Alexandru> (5) have a means for a mobile node to distinguish between > two different Alexandru> 802.11p Access Routers, because 802.11p > works outside the context Alexandru> of an BSS. This would > facilitate the handover procedure of Alexandru> protocol Mobile > IPv6. > > I don't see how this has anything to do with anything. Mobile IPv6 > cares about the IP address of Home Agents. > > > By RFC, the movement detection of Mobile IPv6 relies on the > comparison of prefixes received in Router Advertisements. But in > implementation, often this detection is guided by the change in ESSID > (provoke a different Ass'n Req to a different ESSID, then receive RA, > then compare to old prefix). > > But with 802.11p we don't have Ass'n Req. Basically a Mobile Node > receives RAs from all other Access Routers who send RAs on that > 5900MHz frequency (802.11p is all 'outside a BSS'). With the current > movement detection of RFC Mobile IPv6 and without a BSS, it's hard > for a Mobile Node to detect movement consistently. The end result is > that the Mobile Node may choose the default route to an Access Router > which may not necessarily be the good one (not the closest, not the > approaching, etc.). > > > Alexandru> - work 'outside a BSS', i.e. use the BSSID as 48 1 bits. > This is Alexandru> present in every MAC header of data and control > frames, in the field Alexandru> BSSID. It is not the dst MAC > address. This may or may not have an Alexandru> influence on the > way ND, ICMP and MLD use the multicast addresses Alexandru> > (typically they assume 33::1 instead of 48 1s, but that's only for > Alexandru> dst, BSSID being not used by these protocols). > > huh? The BSSID is not the MAC header. > > > Right, the BSSID is in the 802.11 header (not the Ethernet header). > > It may be that this BSSID all 1s may not have any influence on IPv6. > > > Alex > > > > > _________________________________________________ its mailing list > its@ietf.org > https://www.ietf.org/mailman/__listinfo/its > > > > > > -- John Kenney Sr. Research Manager Toyota InfoTechnology Center, > USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. > Mobile: 650-224-6644 From alexandru.petrescu@gmail.com Wed Jun 19 02:21:41 2013 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 205D621F99D9 for ; Wed, 19 Jun 2013 02:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoyyWOte8V36 for ; Wed, 19 Jun 2013 02:21:33 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 21B1321F9992 for ; Wed, 19 Jun 2013 02:21:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5J9LVAT011948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Jun 2013 11:21:32 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5J9LVOW007060 for ; Wed, 19 Jun 2013 11:21:31 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5J9LICa028538 for ; Wed, 19 Jun 2013 11:21:31 +0200 Message-ID: <51C1780D.4020109@gmail.com> Date: Wed, 19 Jun 2013 11:21:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] P1609.3 Networking Services and IPv6 Address Auto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:21:41 -0000 ITSsers, Following the mentioning of IEEE P1609.3 'Networking Services'. It is good that we have a contact with IEEE about P1609 and I look forward for closer collaboration. To that end, let me mention technical aspects of IPv6 Address Auto-Configuration. The document IEEE P1609.3/D5.0 Draft Standard for Wireless Access in Vehicular 3 Environments (WAVE) - Networking Services, March 2010, describes among other things aspects related to IPv6 address auto-configuration. > For WAVE devices supporting dynamic IP addressing, the WME shall > calculate the global IPv6 address 18 via a stateless configuration > procedure. This is the procedure described in RFC 3513, For more precision, instead of the Proposed Standard RFC3513 "IPv6 Addressing Architecture" one would rather mention the Draft Standard RFC4291 of same title. At IETF a Draft Standard status witnesses wider adoption than Proposed Standard status. Moreover, if the intent of the text is to refer to the procedure of stateless address autoconfiguration then the more precise reference would rather be RFC4862 "Stateless Address Autoconfiguration". In addition, there is another tool for dynamic IP addressing: DHCPv6 in RFC3315. > except the WAVE device uses its MAC address in conjunction with the > IpPrefix received in the WaveRoutingAdvertisement of a WAVE Service > Advertisement, rather than that received in an RFC 4861 Router > Advertisement message. This may be an unncessarily new way to do same functionality. The use of RA is widely implemented and it should be preferred over the use of link-layer specific mechanisms to realize address autoconfiguration. In the past we have seen in the cellular space a similar mechanism to configure IPv6 addresses with RANAP protocol. At IEEE also we seem to be seing the same thing in 802.11ai for Fast Initial Link Setup. These alternative ways to configure IP addresses are obviously incompatible and may need to converge. > WAVE provides this IP configuration information in the WAVE Service > Advertisement to minimize the need for neighbor and router discovery > with their associated overhead and latency. The ND and router discovery may function quite fast. > Note that IP transmissions are prohibited on the control channel. It may be that IP transmissions are not prohibited on the control channel. Some of the 'road safety' and 'traffic efficiency applications' of ETSI ITS may not be prohibited from using IP, hence transmitted on the control channel. Alex From dromasca@avaya.com Wed Jun 19 03:48:23 2013 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 9524021F9AB8 for ; Wed, 19 Jun 2013 03:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.97 X-Spam-Level: X-Spam-Status: No, score=-102.97 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHcXfslrlEox for ; Wed, 19 Jun 2013 03:48:18 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE3621F8F7B for ; Wed, 19 Jun 2013 03:48:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAD+MwVHGmAcF/2dsb2JhbABagmghMUm/GH4WdIIjAQEBAQMBAQEPKDQXBAIBCA0EAQMBAQsUCQcnCxQDBggCBAESCBqHbAELnwybaRMEjwo4BoJ6YQOeBIsAgw+CKA X-IronPort-AV: E=Sophos;i="4.87,896,1363147200"; d="scan'208";a="16746175" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 Jun 2013 06:48:14 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Jun 2013 06:46:16 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 06:48:13 -0400 From: "Romascanu, Dan (Dan)" To: Alexandru Petrescu , "its@ietf.org" Thread-Topic: [its] P1609.3 Networking Services and IPv6 Address Auto-Configuration Thread-Index: AQHObM57VoqR+mUf5ky9qi8ycdROdZk82myQ Date: Wed, 19 Jun 2013 10:48:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1A5259@AZ-FFEXMB04.global.avaya.com> References: <51C1780D.4020109@gmail.com> In-Reply-To: <51C1780D.4020109@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [its] P1609.3 Networking Services and IPv6 Address Auto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:48:23 -0000 Hi,=20 For the information of the participants in this work. The IETF has a formal= liaison channel with the IEEE Standards Association. I am the Liaison Mana= ger of the IETF to the IEEE-SA. I see that several participants already pro= vided answers and information that seems reliable. If there is a need for m= ore information, contacts, formal communication - please let me know I will= try to help.=20 Dan > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Wednesday, June 19, 2013 12:21 PM > To: its@ietf.org > Subject: [its] P1609.3 Networking Services and IPv6 Address Auto- > Configuration >=20 > ITSsers, >=20 > Following the mentioning of IEEE P1609.3 'Networking Services'. It is > good that we have a contact with IEEE about P1609 and I look forward for > closer collaboration. >=20 > To that end, let me mention technical aspects of IPv6 Address Auto- > Configuration. >=20 > The document IEEE P1609.3/D5.0 Draft Standard for Wireless Access in > Vehicular 3 Environments (WAVE) - Networking Services, March 2010, > describes among other things aspects related to IPv6 address auto- > configuration. >=20 > > For WAVE devices supporting dynamic IP addressing, the WME shall > > calculate the global IPv6 address 18 via a stateless configuration > > procedure. This is the procedure described in RFC 3513, >=20 > For more precision, instead of the Proposed Standard RFC3513 "IPv6 > Addressing Architecture" one would rather mention the Draft Standard > RFC4291 of same title. At IETF a Draft Standard status witnesses wider > adoption than Proposed Standard status. >=20 > Moreover, if the intent of the text is to refer to the procedure of > stateless address autoconfiguration then the more precise reference > would rather be RFC4862 "Stateless Address Autoconfiguration". >=20 > In addition, there is another tool for dynamic IP addressing: DHCPv6 in > RFC3315. >=20 > > except the WAVE device uses its MAC address in conjunction with the > > IpPrefix received in the WaveRoutingAdvertisement of a WAVE Service > > Advertisement, rather than that received in an RFC 4861 Router > > Advertisement message. >=20 > This may be an unncessarily new way to do same functionality. The use > of RA is widely implemented and it should be preferred over the use of > link-layer specific mechanisms to realize address autoconfiguration. >=20 > In the past we have seen in the cellular space a similar mechanism to > configure IPv6 addresses with RANAP protocol. At IEEE also we seem to > be seing the same thing in 802.11ai for Fast Initial Link Setup. These > alternative ways to configure IP addresses are obviously incompatible > and may need to converge. >=20 > > WAVE provides this IP configuration information in the WAVE Service > > Advertisement to minimize the need for neighbor and router discovery > > with their associated overhead and latency. >=20 > The ND and router discovery may function quite fast. >=20 > > Note that IP transmissions are prohibited on the control channel. >=20 > It may be that IP transmissions are not prohibited on the control > channel. Some of the 'road safety' and 'traffic efficiency > applications' of ETSI ITS may not be prohibited from using IP, hence > transmitted on the control channel. >=20 > Alex >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From Roberto.Baldessari@neclab.eu Fri Jun 21 09:08:30 2013 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 852F921F9F75 for ; Fri, 21 Jun 2013 09:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LokjiSJNKZlr for ; Fri, 21 Jun 2013 09:08:18 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C579611E8193 for ; Fri, 21 Jun 2013 09:08:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3494110460D; Fri, 21 Jun 2013 18:07:51 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMGYblnXZfzI; Fri, 21 Jun 2013 18:07:51 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 16A131045FE; Fri, 21 Jun 2013 18:07:41 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.234]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 21 Jun 2013 18:08:02 +0200 From: Roberto Baldessari To: "Varadi , Andras (lesswire AG Ungarn)" , "its@ietf.org" Thread-Topic: [its] Updated list of suppliers of 802.11p-compatible equipment Thread-Index: Ac5monZ1/jy5wEC0SUOEMmCDxGNfgQBoaeOgAZVEkZA= Date: Fri, 21 Jun 2013 16:06:31 +0000 Message-ID: <81154EB5875DC143AFAA75562B06D1F85A11C64B@DAPHNIS.office.hd> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com><51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr><51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr><9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com><5108EF0B.5050002@gmail.com><9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com><5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com><510A75F8.7080508@inria.fr><603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp><511F7968.7090309@gmail.com> <5177C6BA.6020805@gmail.com><85C635C4D32378499484B2C61BD297A419E9993E@GSukMHDDCembx02.service.hitachi.net><51952414.1050500@gmail.com> <51B71D4A.2010503@gmail.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.127] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [its] Updated list of suppliers of 802.11p-compatible equipment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:08:30 -0000 WWVzLCB3aG9ldmVyIHByb3ZpZGVkIHRoZSBpbmZvIGFib3V0IHRoZSBtYWpvcml0eSBvZiB2ZW5k b3JzIHVzaW5nIFVORVggaXMgd3JvbmcuDQoNClJvYmVydG8NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGl0cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXRzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWYXJhZGkgLCBBbmRyYXMgKGxlc3N3aXJlIEFHIFVuZ2Fy bikNClNlbnQ6IDEzIEp1bmUgMjAxMyAxNzowNA0KVG86IGl0c0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtpdHNdIFVwZGF0ZWQgbGlzdCBvZiBzdXBwbGllcnMgb2YgODAyLjExcC1jb21wYXRpYmxl IGVxdWlwbWVudA0KDQpEZWFyIEFsZXhhbmRlcg0KDQpQbGVhc2UgbGV0IG1lIGFkZCBzb21lIGlu Zm8gdG8gdGhlIHRvcGljIGJlbG93DQoNCkNvaGRhL05YUCBhcmUgTk9UIFVORVggYmFzZWQsIGJ1 dCB1c2UgdGhlaXIgb3duIFNvQyBpbmNsdWRpbmcgZW5oYW5jZWQgUEhZK01BQyBmb3IgYmV0dGVy IGVycm9yIHRvbGVyYW5jZSBhdCBoaWdoIHNwZWVkLiAodGhlIHNhbWUgZ29lcyBmb3IgQXV0b1Rh bGtzKQ0KDQrDnGR2w7Z6bGV0dGVsIC8gQmVzdCByZWdhcmRzLA0KwqDCoCBBbmRyw6FzIFbDoXJh ZGkNCg0KwqDCoMKgwqAgUHJvamVjdCBNYW5hZ2VyIDo6IFRlY2huaWNhbCBDdXN0b21lciBTdXBw b3J0DQrCoMKgwqDCoCBBdXRvbW90aXZlICYgV0xBTiBHcm91cCANCsKgwqDCoMKgIGxlc3N3aXJl wqDCoCBIdW5nYXJ5IHwgT2ZmaWNlOiArMzYgMjM1MjEgNjY3IHwgRW1haWw6IFZhcmFkaUBsZXNz d2lyZS5jb20gDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGl0cy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBB bGV4YW5kcnUgUGV0cmVzY3UNClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTEsIDIwMTMgMjo1MSBQTQ0K VG86IGl0c0BpZXRmLm9yZw0KU3ViamVjdDogW2l0c10gVXBkYXRlZCBsaXN0IG9mIHN1cHBsaWVy cyBvZiA4MDIuMTFwLWNvbXBhdGlibGUgZXF1aXBtZW50DQoNCkhlbGxvIHBhcnRpY2lwYW50cyB0 byBJVFMgZW1haWwgbGlzdCwNCg0KSSBhZGRlZCBBcmFkYSBTeXN0ZW1zIHRvIHRoZSBsaXN0IG9m IHN1cHBsaWVycyBvZiA4MDIuMTFwLWNvbXBhdGlibGUgZXF1aXBtZW50LiAgQWRkaXRpb25hbGx5 LCBJIGhhdmUgYmVlbiBwb2ludGVkIHRoYXQgbWFueSBpZiBub3QgYWxsICg/KSB0aGVzZSBzeXN0 ZW1zIHVzZSA4MDIuMTFwIG1pbmlQQ0kgYm9hcmRzIGZyb20gVU5FWC4NCg0KVGhlIGxpc3QgaXMg bm93IHRoZSBmb2xsb3dpbmc6DQoNCkFyYWRhIFN5c3RlbXMgTG9jb01hdGUgT0JVDQpSRU5FU0FT IEVMRUNUUk9OSUNTDQpORUMNCk5YUC9Db2hkYSBXaXJlbGVzcw0KQ2lzY28vQ29oZGEgV2lyZWxl c3MNCkRlbnNvDQpEZWxwaGkNClNhdmFyaQ0KS2Fwc2NoDQpTaWVtZW5zDQpJVFJJDQpBdXRvVGFs a3MNCkNvbW1zaWduaWENCg0KWW91cnMsDQoNCkFsZXgNCg0KTGUgMTYvMDUvMjAxMyAyMDoyMywg QWxleGFuZHJ1IFBldHJlc2N1IGEgw6ljcml0IDoNCj4gWWVzLCB0aGFuayB5b3UuICBUaGUgbGlz dCBpcyBub3c6DQo+DQo+IFJFTkVTQVMgRUxFQ1RST05JQ1MNCj4gTkVDDQo+IE5YUC9Db2hkYSBX aXJlbGVzcw0KPiBDaXNjby9Db2hkYSBXaXJlbGVzcw0KPiBEZW5zbw0KPiBEZWxwaGkNCj4gU2F2 YXJpDQo+IEthcHNjaA0KPiBTaWVtZW5zDQo+IElUUkkNCj4gQXV0b1RhbGtzDQo+IENvbW1zaWdu aWENCj4NCj4gWW91cnMsDQo+DQo+IEFsZXgNCj4NCj4gTGUgMDMvMDUvMjAxMyAxODozMiwgTGVu YXJkaSwgTWFzc2ltaWxpYW5vIGEgw6ljcml0IDoNCj4+IERlYXIgQWxsLA0KPj4gcGxlYXNlIGFs c28gYWRkICAgUkVORVNBUyBFTEVDVFJPTklDUyAgIHRvIHRoZSBsaXN0IGJlbG93IG9mIHBvdGVu dGlhbA0KPj4gc3VwcGxpZXJzIG9mIDExcC9EU1JDIGVuYWJsZWQgcmFkaW8gZGV2aWNlcy4NCj4+ IEJlc3QsDQo+PiAtDQo+PiBNYXgNCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IGl0cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXRzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4+IEFsZXhhbmRydSBQZXRyZXNjdQ0KPj4gU2VudDogMjQg QXByaWwgMjAxMyAxMzo0OQ0KPj4gVG86IGl0c0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtp dHNdIHN1cHBsaWVycyBvZiA4MDIuMTFwLW92ZXItSVRTLUc1OyANCj4+IDgwMi4xMXMtb3Zlci01 ODc1LTU5MDVNSHoNCj4+DQo+PiBSZWNlbnRseSBJIGRpc2NvdmVyZWQgdGhhdCBpbiBhZGRpdGlv biB0byB0aGUgcG9zdGVkIGxpc3QgdGhlcmUgaXMgDQo+PiBhbHNvIENvbW1zaWduaWEgYXMgYSBt YW51ZmFjdHVyZXIgb2YgODAyLjExcCBjb21wYXRpYmxlIE9CVSBhbmQgUlNVLg0KPj4gVGhlIGxp c3QgaXMgbm93Og0KPj4NCj4+IE5FQw0KPj4gTlhQL0NvaGRhIFdpcmVsZXNzDQo+PiBDaXNjby9D b2hkYSBXaXJlbGVzcw0KPj4gRGVuc28NCj4+IERlbHBoaQ0KPj4gU2F2YXJpDQo+PiBLYXBzY2gN Cj4+IFNpZW1lbnMNCj4+IElUUkkNCj4+IEF1dG9UYWxrcw0KPj4gQ29tbXNpZ25pYQ0KPj4NCj4+ IFlvdXJzLA0KPj4NCj4+IEFsZXgNCj4+DQo+PiBMZSAxNi8wMi8yMDEzIDEzOjE5LCBBbGV4YW5k cnUgUGV0cmVzY3UgYSDDqWNyaXQgOg0KPj4+IExlIDExLzAyLzIwMTMgMTQ6NTAsIERvd2RlbGws IEpvaG4gYSDDqWNyaXQgOg0KPj4+PiBBbGV4DQo+Pj4+DQo+Pj4+IElzIGFueW9uZSBtYWtpbmcg ODAyLjExcCByYWRpb3MgY29tbWVyY2lhbGx5IGF0IHJlYXNvbmFibGUgY29zdD8gDQo+Pj4+IFRo ZSBmZXcgSSBoYXZlIHNlZW4gc2VlbSB0byBiZSB2ZXJ5IGV4cGVuc2l2ZSAoZmV3IGskKSBhbmQg dGhlcmUgDQo+Pj4+IGFwcGVhcnMgdG8gYmUgbGl0dGxlIHN1cHBvcnQgaW4gTGludXguDQo+Pj4N Cj4+PiBKb2huLA0KPj4+DQo+Pj4gQSBwZXJzb24gd2FzIGtpbmQgZW5vdWdoIHRvIGdhdGhlciBp biBvbmUgcGxhY2UgaW5mb3JtYXRpb24gd2hpY2ggaXMgDQo+Pj4gb3RoZXJ3aXNlIHNwYXJzZWx5 IGJ1dCBwdWJsaWNseSBhdmFpbGFibGU7IHRoaXMgaW5mb3JtYXRpb24gaXMgYWJvdXQgDQo+Pj4g c3VwcGxpZXJzIG9mIDgwMi4xMXAtb3Zlci1JVFMtRzUgZnJlcXVlbmNpZXMgKDU4NzUtNTkwNU1I eiwgDQo+Pj4gNTg1NS01ODc1TUh6LCA1NDcwLTU3MjVNSHo7IGNhdmVhdCAtIG9ubHkgc29tZSBh cmUgYWxsb3dlZCBpbiBzb21lIA0KPj4+IGNvdW50cmllcywgY2hlY2sgdGhlIGxvY2FsIHJlZ3Vs YXRvciBiZWZvcmUgdHVybmluZyB0aGVzZSBvbikuDQo+Pj4NCj4+PiBORUMNCj4+PiBOWFAvQ29o ZGEgV2lyZWxlc3MNCj4+PiBDaXNjby9Db2hkYSBXaXJlbGVzcw0KPj4+IERlbnNvDQo+Pj4gRGVs cGhpDQo+Pj4gU2F2YXJpDQo+Pj4gS2Fwc2NoDQo+Pj4gU2llbWVucw0KPj4+IElUUkkNCj4+PiBB dXRvVGFsa3MNCj4+Pg0KPj4+IEkgaGF2ZSBzb21lIGV4cGVyaWVuY2Ugd2l0aCBJVFJJIGVxdWlw bWVudC4gIEluIHRoZWlyIG9mZmVyIHRoZXJlIGlzIA0KPj4+IGEgZnVsbC1ibG93biBSU1UsIGZv ciBhcm91bmQgMTUwMEVVUi4gIFRoaXMgaXMgZm9yIGEgUlNVIGhhcmRlbmVkIA0KPj4+IGJveCBm b3Igb3V0ZG9vcnMsIHBvd2VycGMsIEdQUy1lbmFibGVkLCAyeCA4MDIuMTFwIGludGVyZmFjZXMs IA0KPj4+IEV0aGVybmV0IHdpdGggUG9FLCBVU0IsIGFuZCBsaW51eCAyLjYuICBBbW9uZyB0aGVz ZSwgaXQgaXMgdGhlIA0KPj4+IHNvZnR3YXJlIHdoaWNoIGlzIGV4cGVuc2l2ZTsgdGhpcyBpbmNs dWRlcyBBdGhlcm9zIGRyaXZlciANCj4+PiBtb2RpZmljYXRpb25zLCBuZXcga2VybmVsIG1vZHVs ZXMgZm9yICJCVFAiIChCYXNlIFRyYW5zbWlzc2lvbiANCj4+PiBQcm90b2NvbD8pLCAnZ2VvbmV0 d29ya2luZycsICd3YXZlJy4NCj4+Pg0KPj4+IE9UaGVyIHRoYW4gYSBmdWxsLWJsb3duIFJTVSwg b25lIGNvdWxkIGFjcXVpcmUgYWxzbyBJVFJJIGluZGl2aWR1YWwgDQo+Pj4gJzgwMi4xMXAnIG1p bmlQQ0kgY2FyZHMgd2hpY2ggYXJlIGluIHRoZSBvcmRlciBvZiBjb3VwbGUgaHVuZHJlZHMgb2Yg DQo+Pj4gZXVyb3MuDQo+Pj4NCj4+PiBUaGlzIGlzIG5vdCBhIGNvbW1lcmNpYWwgYWR2ZXJ0aXNl bWVudC4gIFRlY2huaWNhbGx5IHNwZWFraW5nIHRoaXMgDQo+Pj4gbWVhbnMgbWFueSB0aGluZ3Mg Zm9yIGRlc2lnbmluZyBwcm90b2NvbHMuICBGb3IgZXhhbXBsZToNCj4+Pg0KPj4+IEl0IG1lYW5z IGl0IGlzIGVhc2lseSBwb3NzaWJsZSB0byBydW4gbGludXggd2l0aCBJUHY2IG92ZXIgYSAnd2F2 ZTAnDQo+Pj4gaW50ZXJmYWNlLiAgIEp1c3QgdHVybiBpdCBvbiwgd2F0Y2ggdGhlIElQdjYgbGlu ay1sb2NhbCBhZGRyZXNzLCBlY2hvDQo+Pj4gdGhlIGZyZXF1ZW5jeSB2YWx1ZSBhbmQgcGluZy4g KG5vIG5lZWQgdG8gc2V0IEVTU0lELCBub3Igc2VjdXJpdHkpLg0KPj4+DQo+Pj4gSW4gYWRkaXRp b24gdG8gdGhlIEV0aGVybmV0IGludGVyZmFjZXMsIHRoZSBSU1UgaGFzIF8yXyA4MDIuMTFwIA0K Pj4+IGRpZmZlcmVudCBpbnRlcmZhY2VzLCBhbmQgb25lIEV0aGVybmV0LiAgTm90IGp1c3QgdHdv IGFudGVubmFzLCBidXQgDQo+Pj4gdHdvIGludGVyZmFjZXMgKGlmY29uZmlnICd3YXZlMCcgYW5k ICd3YXZlMScpLiBUaGlzIG1lYW5zIG9uZSANCj4+PiBkb2Vzbid0IG5lZWQgdG8gJ3JlbGF5JyBw YWNrZXRzIGFuZCB0aGF0IG9uZSBuZWVkcyB0byAncm91dGUnIA0KPj4+IHBhY2tldHMsIGluIHRo ZSB0cmFkaXRpb25hbCBzZW5zZSBvZiAncm91dGluZycuICAoY29tcGFyZSB0aGlzIGZvciANCj4+ PiBleGFtcGxlIHRvIFJQTCBjb250ZXh0IHdoZXJlIGEgc2Vuc29yIGhhcyBhIF9zaW5nbGVfIGlu dGVyZmFjZSBhbmQgDQo+Pj4gdGhlcmUgaXMgbm8gcm91dGluZywgYnV0ICdyZWxheWluZycpLg0K Pj4+DQo+Pj4gQWxzbyB0aGlzIG91dGRvb3JzIFJTVSBoYXMgMSBHUFMgYW50ZW5uYS4gIFRoaXMg bWVhbnMgdGhhdCANCj4+PiBnZW9uZXR3b3JraW5nIGRvZXMgbm90IHdvcmsgaWYgb25lIHRyaWVz IHRvIHVzZSB0aGlzIGluZG9vcnMgaW4gYSANCj4+PiBsYWIgd2hlcmUgR1BTIHNpZ25hbCBkb2Vz IG5vdCByZWFjaC4gKHVubGVzcyBvbmUgaW5zdGFsbHMgYSBHUFMgJ3JlcGVhdGVyJw0KPj4+IC0g ZWFzeSB0byBkbyBidXQgY2hlY2sgd2l0aCByZWd1bGF0b3IgaW4gY291bnRyeSwgb3IgdXNlIGEg R1BTIA0KPj4+ICdyZXBsYXllcicgc29mdHdhcmUgdG8gcGxheSBwcmUtcmVjb3JkZWQgTk1FQSBz ZW50ZW5jZXMgb24gL2Rldi90dHkpLg0KPj4+DQo+Pj4gTm90ZSBhbHNvIGl0IGlzIHN0cmFuZ2Ug dG8gZGVzaWduIGFuIFJTVSBSb2FkIFNpZGUgVW5pdCAtIGRlc2lnbmVkIA0KPj4+IHRvIGJlIGZp eGVkIHdpdGggcmVzcGVjdCB0byBFYXJ0aCwgYW5kIHB1dCBhIEdQUyBpbnRlcmZhY2Ugb24gaXQu ICANCj4+PiBJdCB3b3VsZCBoYXZlIGJlZW4gZWFzaWVyIHRvIGp1c3QgcmVjb3JkIHRoZSBHUFMg Y29vcmRpbmF0ZXMgb25jZSANCj4+PiBhbmQgc2V0IHRoZW0gaW4gYSBmaWxlIGZvciBhcyBsb25n IGFzIHRoYXQgUlNVIHN0YXlzIHRoZXJlLiAgSSANCj4+PiBjb25zaWRlciBpdCBhcyBhbiBleHRy YSwgYnV0IGNoZWFwZXIgUlNVIHdpdGhvdXQgR1BTIHNob3VsZCBiZSBwb3NzaWJsZS4NCj4+Pg0K Pj4+PiA4MDIuMTFzIG9uIHRoZSBvdGhlciBoYW5kIGlzIGF2YWlsYWJsZSBvbiBzdGFuZGFyZCBX aS1GaSBkb25nbGVzIA0KPj4+PiAoZnJvbSAkMTUpIGFuZCBkcml2ZXJzIGFyZSBhbHJlYWR5IGF2 YWlsYWJsZSBpbiBMaW51eC4gSXMgaXQgDQo+Pj4+IGNvcnJlY3QgdGhhdCA4MDIuMTFwIGlzIG1h bmRhdGVkIGZvciBJVFMgaW4gc29tZSByZWdpb25zPw0KPj4+DQo+Pj4gSSBkb3VidCA4MDIuMTFw IGJlIG1hbmRhdGVkIGZvciBJVFMuDQo+Pj4NCj4+PiBJIHRoaW5rIHRoZSByZWd1bGF0b3IgbWFu ZGF0ZXMgdGhlIGFwcGxpY2F0aW9uIHdoaWNoIGNvdWxkIGJlIHVzZWQgDQo+Pj4gb24gc29tZSBm cmVxdWVuY2llcy4NCj4+Pg0KPj4+IFdoZXJlIEkgbGl2ZSwgdGhlIHJlZ3VsYXRvciBtYW5kYXRl cyB0aGUgdXNlIG9mIHZlaGljdWxhciAnc2FmZXR5Jw0KPj4+IGFwcGxpY2F0aW9ucyBhdCA1ODc1 LTU5MDVNSHouICBUaGUgdGVjaG5pY2FsICdjb25kaXRpb25zJyBhcmUgDQo+Pj4gcmVmZXJyZWQg YnkgdGhlIHJlZ3VsYXRvciB0byBFVFNJIGRvY3VtZW50cyAodGhlIHJlZ3VsYXRvciBpcyBub3Qg DQo+Pj4gRVRTSSwgYnV0IG9mdGVuIGltcGxlbWVudHMgd2hhdCBFVFNJIHdhbnRzLCBidXQgbm90 IGFsd2F5cykuICBJIA0KPj4+IGRvdWJ0IHRoZSByZWd1bGF0b3IgbWFuZGF0ZXMgJ2dlb25ldHdv cmtpbmcnIGZvciB0aGlzIGJhbmQuDQo+Pj4NCj4+PiBJIGRvdWJ0ICdJUCcgY291bGQgYmUgcXVh bGlmaWVkIGFzICdzYWZldHknLg0KPj4+DQo+Pj4gSGVuY2UgSSB0aGluayA4MDIuMTFzIF9jb3Vs ZF8gYmUgdXNlZCBvbiB0aGUgcmFuZ2UgNTg3NS01OTA1TUh6LCBhcyANCj4+PiBsb25nIGFzIGl0 IGRvZXMgbm90IHRyYW5zcG9ydCBJUC4NCj4+Pg0KPj4+IDgwMi4xMXAgaGFzIHNvbWUgZmVhdHVy ZXMgd2hpY2ggY291bGQgcXVhbGlmeSBhcyAnc2FmZXR5Jy4gIEZvciANCj4+PiBleGFtcGxlLCBp dCBoYXMgc29tZSBNQUMtbGF5ZXIgbWVzc2FnZXMgZm9yICdlbWVyZ2VuY3knLCBhbmQgd2l0aCAN Cj4+PiB0aW1lc3RhbXBzIChhYnNlbnQgZnJvbSAuMTEgbm9uLXAgc3RhbmRhcmQpLCB3aGljaCBk b24ndCB0cmFuc3BvcnQgSVAuDQo+Pj4NCj4+PiAnZ2VvbmV0d29ya2luZycgYWxzbyBoYXMgc29t ZSBmZWF0dXJlcyB3aGljaCBjb3VsZCBxdWFsaWZ5IGFzICdzYWZldHknLg0KPj4+IEkganVzdCBk b24ndCByZW1lbWJlciB3aGljaC4NCj4+Pg0KPj4+IFdoYXQgZmVhdHVyZXMgaW4gODAyLjExcyB3 b3VsZCBxdWFsaWZ5IGFzICdzYWZldHknPw0KPj4+DQo+Pj4gQWxleA0KPj4+DQo+Pj4+DQo+Pj4+ IEpvaG4NCj4+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogaXRzLWJv dW5jZXNAaWV0Zi5vcmcgDQo+Pj4+IFttYWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBBbGV4YW5kcnUgUGV0cmVzY3UgU2VudDoNCj4+Pj4gMzEgSmFudWFyeSAyMDEzIDE1 OjE3IFRvOiBpdHNAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtpdHNdIElQIG92ZXIgDQo+Pj4+IDgw Mi4xMXANCj4+Pj4NCj4+Pj4gTGUgMzEvMDEvMjAxMyAxNDo0NywgVGhpZXJyeSBFcm5zdCBhIMOp Y3JpdCA6DQo+Pj4+Pg0KPj4+Pj4gV2VsbCwgd2UgZG8gYWN0dWFsbHkgcnVuIElQdjYgb3ZlciAx MXAgKHdpdGggb3Igd2l0aG91dCANCj4+Pj4+IEdlb05ldHdvcmtpbmcpLCBzbyBJIGRvbid0IHNl ZSB3aGF0IGtpbmQgb2YgaXNzdWVzIHRoZXJlIG1pZ2h0IGJlIA0KPj4+Pj4gLi4uDQo+Pj4+DQo+ Pj4+IEkgaGF2ZSBzb21lIGNsYXJpZmljYXRpb24gcXVlc3Rpb25zIGFib3V0IEV0aGVyVHlwZSBh bmQgODAyLjExcCBhbmQgDQo+Pj4+IEdlb05ldHdvcmtpbmcuDQo+Pj4+DQo+Pj4+IEkgZ3Vlc3Mg d2hlbiB5b3UgcnVuIElQdjYgb3ZlciAxMXAgd2l0aCBHZW9OZXR3b3JraW5nLCB0aGUgRXRoZXJu ZXQgDQo+Pj4+IGhlYWRlciB1c2VzIEV0aGVyVHlwZSBzb29uLXRvLWJlLTB4ODk0Nywgd2hlcmVh cyB3aGVuIHlvdSBydW4gSVB2NiANCj4+Pj4gb3ZlciAxMXAgd2l0aG91dCBHZW9OZXR3b3JraW5n LCB0aGUgRXRoZXJuZXQgaGVhZGVyIHVzZXMgRXRoZXJUeXBlIA0KPj4+PiAweDg2REQuIFRoaXMg aXMganVzdCBhIHN1cHBvc2l0aW9uLCBJIGRvbid0IGtub3cgaG93IHlvdSBydW4gaXQuDQo+Pj4+ DQo+Pj4+IEFsc28sIGlmIEkgcnVuIElQdjQgb3ZlciAxMXAgd2l0aCBHZW9OZXR3b3JraW5nIC0g c2hvdWxkIEkgdXNlIA0KPj4+PiBFdGhlclR5cGUgc29vbi10by1iZS0weDg5NDc/ICBPciBvdGhl cj8gIEkgc3VwcG9zZSB0aGF0IGlmIEkgcnVuIA0KPj4+PiBJUHY0IG92ZXIgMTFwIHdpdGhvdXQg R2VvTmV0d29ya2luZyBJIHNob3VsZCB1c2UgRXRoZXJUeXBlIDB4MDgwMCwgDQo+Pj4+IGFuZCBp ZiBpdCdzIEFSUCBvdmVyIDgwMi4xMXAgc3RpbGwgd2l0aG91dCBHZW9OZXR3b3JraW5nIHRoZW4g SSANCj4+Pj4gc2hvdWxkIHVzZSBFdGhlclR5cGUgMHgwODA2Lg0KPj4+Pg0KPj4+PiAodGhlIGxl dHRlciB3ZSd2ZSBzZWVuIHJlY2VudGx5IGlzIG5vdCBjbGVhciB3aGV0aGVyIHRoYXQgDQo+Pj4+ IGFsbG9jYXRpb24gaXMgZm9yIEdlb05ldHdvcmtpbmcsIGZvciBJUC1vdmVyLTgwMi4xMXAsIGZv ciBFVFNJIElUUywgDQo+Pj4+IGZvciBHZW9OZXR3b3JraW5nIGZvciBJUHY2LCBmb3IgR2VvTmV0 d29ya2luZyBmb3IgSVB2NCwgZXRjLiAgSXQgaXMgDQo+Pj4+IG5vdCBjbGVhciBlaXRoZXIgd2hl dGhlciBHZW9OZXR3b3JraW5nIHN1cHBvcnRzIElQdjQgb3Igbm90LCBvciANCj4+Pj4gdW5kZXIg d2hhdCBmb3JtKS4NCj4+Pj4NCj4+Pj4gSSBhbHNvIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQg dGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSANCj4+Pj4gbmF0dXJlIG9mIHNvbWUgODAyLjEx cCBsaW5rcyAobm8gRVNTSUQsIGFic2VuY2Ugb2YgbGluay1sYXllciANCj4+Pj4gc2VjdXJpdHkg LSBhcyBvcHBvc2VkIHRvIFdpRmkgd2hpY2ggaGFzIEVTU0lEIGFuZCBsaW5rLWxheWVyIHNlY3Vy aXR5KSBhbmQgSVAuDQo+Pj4+DQo+Pj4+IEZvciBleGFtcGxlIC0gd2lsbCBWMlYgcHJlZml4IGV4 Y2hhbmdlIHVzaW5nIFJvdXRlciBBZHZlcnRpc2VtZW50cyANCj4+Pj4gd29yayBlYXNpZXIgb24g ODAyLjExcCBsaW5rcyAoZWFzaWVyIHRoYW4gb24gV2lGaSksIGJlY2F1c2UgdGhlIA0KPj4+PiBF U1NJRCBkb2VzIG5vdCBuZWVkIHRvIGJlIGRpc2NvdmVyZWQsIHRoZSBhZC1ob2MgbmV0d29yayBk b2VzIG5vdCANCj4+Pj4gbmVlZCB0byBiZSBmb3JtZWQgLSBzdWZmaWNlcyBpdCB0byBzZW5kIHBh Y2tldHMgb24gYSBjZXJ0YWluIGNoYW5uZWwuDQo+Pj4+DQo+Pj4+IChpbiBhIFYyViBkcmFmdCBv bmUgc2VlbXMgdG8gc2F5IHRoYXQgdGhlIHByZXNlbmNlIG9mIEFjY2VzcyBQb2ludCANCj4+Pj4g aXMgYWJzb2x1dGVseSBuZWNlc3NhcnkgaW4gb3JkZXIgZm9yIDgwMi4xMXAgdG8gd29yazsgYnV0 IGluIG91ciANCj4+Pj4gZXhwZXJpbWVudGF0aW9ucyB0aGlzIGlzIG5vdCB0aGUgY2FzZSAtIGl0 IGlzIHBvc3NpYmxlIHRvIGVzdGFibGlzaCANCj4+Pj4gZGlyZWN0IHZlaGljbGUtdG8tdmVoaWNs ZSBJUC1vdmVyLTgwMi4xMXAgY29tbXVuaWNhdGlvbnMgd2l0aG91dCANCj4+Pj4gdGhlIHByZXNl bmNlIG9mIGEgZml4ZWQgODAyLjExcCBBY2Nlc3MgUG9pbnQpLg0KPj4+Pg0KPj4+PiBGb3IgYW5v dGhlciBleGFtcGxlIC0gd2lsbCBJUCBwcmVmZXIgdGhhdCB0aGUgODAyLjExcCBjaGFubmVsIGlu IA0KPj4+PiBGcmFuY2UgYmUgMTc2LCAxNzggb3IgMTgwPyAod2l0aCBXaUZpLCBJUCBkb2VzIG5v dCBjYXJlIGJlY2F1c2UgaXQgDQo+Pj4+IGNhbiB3b3JrIG9uIGFueSBvZiB0aGUgMTEgY2hhbm5l bHMgZXF1YWxseSB3ZWxsLCBidXQgd2l0aCA4MDIuMTFwIA0KPj4+PiBlYWNoIG9mIHRoZXNlIHRo cmVlIGNoYW5uZWxzIHNlZW0gdG8gYmUgcmVzZXJ2ZWQgZm9yICJTZXJ2aWNlcyIsIA0KPj4+PiAi Q29udHJvbCIgYW5kICJTZXJ2aWNlcyIpLg0KPj4+Pg0KPj4+PiBGb3IgYW5vdGhlciBleGFtcGxl IC0gaXMgYWxsIHRoZSBzZWN1cml0eSBvbiB0aGVzZSBsaW5rcyBlbnRpcmVseSANCj4+Pj4gcmVs YXlpbmcgb24gSVAgbGF5ZXIgc2VjdXJpdHkgKElQc2VjLCBTZU5ELCBFQVAsIFBBTkEpPw0KPj4+ Pg0KPj4+PiBJIHRoaW5rIGZpbmRpbmcgY29uc2Vuc3VzIG9uIHNvbWUgb2YgdGhlc2UgcXVlc3Rp b25zIGNvdWxkIGxlYWQgdG8gDQo+Pj4+IGludGVyb3BlcmFiaWxpdHkuDQo+Pj4+DQo+Pj4+IEFs ZXgNCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBSZWdhcmRzLCBUaGllcnJ5DQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+PiBPbiAzMS8wMS8xMyAxMzo1NSwgQWxleGFuZHJ1IFBldHJlc2N1IHdyb3RlOg0K Pj4+Pj4+IEdpdmVuIGN1cnJlbnQgZGlzY3Vzc2lvbnMsIEkgdGhpbmsgaXQgbWF5IGJlIHdvcnRo IGNvbnNpZGVyaW5nIGEgDQo+Pj4+Pj4gd29yayBpdGVtIGFib3V0IGhvdyB0byBydW4gSVAgb3Zl ciA4MDIuMTFwLg0KPj4+Pj4+DQo+Pj4+Pj4gT25lIG9mIHRoZSB0aGluZ3MgdG8gc2F5IHdvdWxk IGJlIHdoZXRoZXIgb3Igbm90IHRoaXMgaXMgSVB2NiANCj4+Pj4+PiBvbmx5IG9yIElQdjQgYWxz by4NCj4+Pj4+Pg0KPj4+Pj4+IFRoaXMgd291bGQgc2F5IGhvdyB0aGlzIHdvdWxkIHdvcmsgX3dp dGhvdXRfIEdlb05ldHdvcmtpbmcuDQo+Pj4+Pj4NCj4+Pj4+PiBJdCB3b3VsZCBhZ3JlZSBvbiB0 aGUgRXRoZXJUeXBlIGFuZC9vciB3aGV0aGVyIHRoZXJlIGFyZSBuZXcgDQo+Pj4+Pj4gb25lcywg c2V2ZXJhbCBvciBvbmx5IG9uZSwgb3IgcmV1c2luZyBleGlzdGluZyBFdGhlclR5cGVzLg0KPj4+ Pj4+DQo+Pj4+Pj4gSXQgY291bGQgYmUgYXMgc2ltcGxlIGFzIHRvIHNheSB0aGF0IElQIHdvcmtz IG92ZXIgODAyLjExcCBqdXN0IA0KPj4+Pj4+IGFzIGl0IHdvcmtzIG92ZXIgODAyLjExYiAtIG5v IG1vZGlmaWNhdGlvbnMuDQo+Pj4+Pj4NCj4+Pj4+PiBXaGF0IGRvIHlvdSB0aGluaz8NCj4+Pj4+ Pg0KPj4+Pj4+IEFsZXgNCj4+Pj4+Pg0KPj4+Pj4+IExlIDMwLzAxLzIwMTMgMTE6MTAsIEFsZXhh bmRydSBQZXRyZXNjdSBhIMOpY3JpdCA6DQo+Pj4+Pj4+IExlIDMwLzAxLzIwMTMgMTE6MDQsIFJv bWFzY2FudSwgRGFuIChEYW4pIGEgw6ljcml0IDoNCj4+Pj4+Pj4+IEhpIEFsZXhhbmRydSwNCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBJRUVFIHRhbGsgb25seSBoZXhhIGluIHRoZWlyIEV0aGVydHlwZSBm aWxlcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSSB0ZW5kIHRvIGFncmVlIHRoYXQgIzg5NDcgaXMgYSBo ZXhhZGVjaW1hbCBub3RhdGlvbiBhbHNvIA0KPj4+Pj4+PiBiZWNhdXNlIHRoZSBzaGFycCBzaWdu IHByZWNlZGluZyBpdCwgYW5kIGJlY2F1c2UgaWYgaXQgd2VyZSANCj4+Pj4+Pj4gZGVjaW1hbCBp dCB3b3VsZCBjb252ZXJ0IHRvIDIyRjMgd2hpY2ggaXMgYWxyZWFkeSByZXNlcnZlZCBmb3IgdHJp bGwuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkganVzdCB3YXRlbmQgdG8gbWFrZSBzdXJlLg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBBbGV4DQo+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gUmVnYXJkcywNCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBEYW4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogaXRzLWJvdW5j ZXNAaWV0Zi5vcmcgDQo+Pj4+Pj4+Pj4gW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFsZXhhbmRydSBQZXRyZXNjdQ0KPj4+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwg SmFudWFyeSAzMCwgMjAxMyAxMjowMCBQTSBUbzoNCj4+Pj4+Pj4+PiBpdHNAaWV0Zi5vcmcgU3Vi amVjdDogUmU6IFtpdHNdIFdoYXQgZG8gd2UgbmVlZCB0byBtYWtlIElUUyBXRyANCj4+Pj4+Pj4+ PiBnbyBmb3J3YXJkPyAtIEV0aGVyVHlwZSBmb3IgSVRTDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBI ZWxsbyBEYW4sDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBUaGFuayB5b3UgZm9yIHRoZSBlbWFpbC4N Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEkgdGhpbmsgd2UgZGVmaW5pdGVseSBuZWVkIGEgZ29vZCBp bnRlcmZhY2Ugd2l0aCBJRUVFIGFib3V0IA0KPj4+Pj4+Pj4+IHRoaXMuDQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+PiBNYXliZSB5b3UgY291bGQgYXNrIHRoZW0gd2hldGhlciB0aGlzIG51bWJlciBpcyBo ZXhhIG9yIA0KPj4+Pj4+Pj4+IGRlY2ltYWwsIHNvIHdlIGtub3cgd2hhdCB0byBwdXQgaW4gaW1w bGVtZW50YXRpb24gKGUuZy4NCj4+Pj4+Pj4+PiB3aXJlc2hhcmsgcGFja2V0IGFuYWx5emVycywg YW5kIDgwMi4xMXAvZXRzaS1pdHMgDQo+Pj4+Pj4+Pj4gaW1wbGVtZW50YXRpb25zKS4NCj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+IEFsc28sIEkgYW0gaW50ZXJlc3RlZCB0byBsZWFybiB3aGV0aGVyIHRo aXMgZGVzZXJ2ZXMgYmVpbmcgDQo+Pj4+Pj4+Pj4gcmVzZXJ2ZWQgYXQgSUFOQS4NCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IEFsZXgNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IExlIDMwLzAxLzIwMTMgMTA6 NDksIFJvbWFzY2FudSwgRGFuIChEYW4pIGEgw6ljcml0IDoNCj4+Pj4+Pj4+Pj4gSGksDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRoZSBkb2N1bWVudHMgdGhhdCB5b3UgYXJlIHJlZmVycmluZyAo b24gdGhlIEVUU0kNCj4+Pj4+Pj4+Pj4gc2VydmVyKSBhcmUgbm90IGZyZWVseSBhY2Nlc3NpYmxl LiBBIHBhc3N3b3JkIGlzIHJlcXVpcmVkLCANCj4+Pj4+Pj4+Pj4gYW5kIHByb2JhYmx5IG9ubHkg RVRTSSBtZW1iZXJzIGhhdmUgdGhlIGFjY2VzcyBpbmZvcm1hdGlvbi4NCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4gVGhlIHJlc3BvbnNpYmlsaXR5IGZvciBhc3NpZ25pbmcgRXRoZXJUeXBlIHZhbHVl cyBpcyB3aXRoIHRoZSANCj4+Pj4+Pj4+Pj4gSUVFRSBSZWdpc3RyYXRpb24gQXV0aG9yaXR5LiBU aGV5IG1haW50YWluIGEgcHVibGljIGxpc3QgDQo+Pj4+Pj4+Pj4+ICh1cGRhdGVkIGRhaWx5KSBh dCANCj4+Pj4+Pj4+Pj4gaHR0cDovL3N0YW5kYXJkcy5pZWVlLm9yZy9kZXZlbG9wL3JlZ2F1dGgv ZXRoZXJ0eXBlL2V0aC50eHQNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+ Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+PiBhbmQgYWNjb3JkaW5nIHRvIHRoaXMg bGlzdCB0aGUgdmFsdWUgODk0NyBpcyBub3QgYWxsb2NhdGVkLg0KPj4+Pj4+Pj4+PiBOb3csIHRo ZSBwdWJsaWMgbGlzdGluZyBpbmZvcm1hdGlvbiBmb3IgRXRoZXJUeXBlcyBiZWFycyAgYSANCj4+ Pj4+Pj4+Pj4gZGlzY2xhaW1lciB0aGF0IHNheXMNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gKiBU aGlzIGlzIGEgcGFydGlhbCBsaXN0aW5nIG9mIGFsbCBhc3NpZ25lZCBFdGhlclR5cGUgRmllbGRz Lg0KPj4+Pj4+Pj4+PiBOb3QNCj4+Pj4+Pj4+PiBhbGwNCj4+Pj4+Pj4+Pj4gcmVjaXBpZW50cyB3 aXNoIHRvIHB1Ymxpc2ggdGhlaXIgYXNzaWdubWVudCBhdCB0aGlzIHRpbWUuDQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+IERpZCBFVFNJIHJlcXVpcmUgZm9yIHRoaXMgaW5mb3JtYXRpb24gbm90IHRv IGJlIHB1Ymxpc2hlZD8gSXQgDQo+Pj4+Pj4+Pj4+IGRvZXMgbm90IGxvb2sgdXNlZnVsIGlmIHRo ZXkgd2FudCB0byBlbmNvdXJhZ2UgDQo+Pj4+Pj4+Pj4+IGludGVyb3BlcmFiaWxpdHkNCj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVmFsdWUgMDcwNyBtZW50aW9uZWQgaW4gdGhlIHRocmVhZCBpcyBu b3QgYWxsb2NhdGVkIGVpdGhlci4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gTGV0IG1lIGtub3cg aWYgSSBjYW4gaGVscCAoYXMgSUVURiBsaWFpc29uIHRvIHRoZSBJRUVFLVNBKS4NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gRGFuDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICpGcm9tOippdHMtYm91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+Pj4+ PiBbbWFpbHRvOml0cy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpUaGllcnJ5IEVy bnN0DQo+Pj4+Pj4+Pj4+ICpTZW50OiogV2VkbmVzZGF5LCBKYW51YXJ5IDMwLCAyMDEzIDExOjEx IEFNICpUbzoqIA0KPj4+Pj4+Pj4+PiBpdHNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4gKlN1YmplY3Q6 KiBSZTogW2l0c10gV2hhdCBkbyB3ZSBuZWVkIHRvIG1ha2UgSVRTIFdHIGdvIGZvcndhcmQ/DQo+ Pj4+Pj4+Pj4+IC0gRXRoZXJUeXBlIGZvciBJVFMNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4gQWxleCwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSUVFRSBoYXZlIGFzc2lnbmVk IEV0aGVybmV0IFR5cGUgRmllbGQgbnVtYmVyICM4OTQ3IGZvciBJVFMgDQo+Pj4+Pj4+Pj4+IHVz ZSAoRVRTSSBUQyBJVFMncyBHZW9OZXR3b3JraW5nKS4gQ2hlY2sgdGhlIGZvbGxvd2luZyANCj4+ Pj4+Pj4+Pj4gZG9jdW1lbnQgYXZhaWxhYmxlIG9uIHRoZSBFVFNJIHNlcnZlcjoNCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gSVRTKDEzKTAwMDAyMA0KPj4+Pj4+Pj4+PiA8aHR0cDovL2RvY2JveC5l dHNpLm9yZy9JVFMvSVRTLzA1LUNPTlRSSUJVVElPTlMvMjAxMy9JVFMlMjgxDQo+Pj4+Pj4+Pj4+ IDMlDQo+Pj4+Pj4+Pj4+IDI5MDAwMDINCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+IDBfRXRoZXJuZXRfVHlwZV9GaWVsZF9udW1iZXJfZm9yX0dl b05ldHdvcmtpbmcucGRmPg0KPj4+Pj4+Pj4+PiBFdGhlcm5ldCBUeXBlIEZpZWxkIG51bWJlciBm b3IgR2VvTmV0d29ya2luZw0KPj4+Pj4+Pj4+PiBodHRwOi8vZG9jYm94LmV0c2kub3JnL0lUUy9J VFMvMDUtQ09OVFJJQlVUSU9OUy8yMDEzL0lUUygxMykwDQo+Pj4+Pj4+Pj4+IDAwDQo+Pj4+Pj4+ Pj4+IDAyMF9FdGgNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pg0KPj4+IGVybmV0X1R5cGVfRmllbGRfbnVtYmVyX2Zvcl9HZW9OZXR3b3JraW5nLnBkZg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBSZWdhcmRzLCBUaGllcnJ5Lg0KPj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBPbiAyOC8wMS8xMyAxNDoyOCwgQWxleGFuZHJ1IFBldHJlc2N1 IHdyb3RlOg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBMZSAyOC8wMS8yMDEzIDE0OjE2LCBKb2Ug S2xlaW4gYSDDqWNyaXQgOg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBJIHJlYWxseSBkaXNsaWtl IHRoZSBmYWN0IHRoYXQgSVNPIGlzIGNoYXJnaW5nIGZvciB0aGUgSVNPDQo+Pj4+Pj4+Pj4+IDIx MjE3IC0gQXJjaGl0ZWN0dXJlICYgSVNPIDIxMjEwIC0gSVB2NiBOZXR3b3JraW5nLg0KPj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+PiBEb2VzIHRoaXMgbWFrZSBpdCBhbnkgYmV0dGVyPyBTYWZlcj8gIFNo b3VsZCBJU08gbm93IGhhdmUgDQo+Pj4+Pj4+Pj4+IGN5YmVyc2VjdXJpdHkgYW5kIHNhZmV0eSBs aWFiaWxpdHkgaWYgdGhlIHNwZWNpZmljYXRpb24gbGVhZHMgDQo+Pj4+Pj4+Pj4+IHRvIGRlYXRo cyBhbmQgZGFtYWdlIHRvIHByb3BlcnR5Pw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiBEb2VzIGl0IG1ha2UgYW55IGJldHRlciBpbnRlcm9wZXJhYmxlIGFzIHdlbGw/DQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEV0aGVyVHlwZSAweDA3MDcgZGVzY3JpYmVkIGluIElUUyBkb2N1 bWVudHMsIGltcGxlbWVudGVkLCBidXQgDQo+Pj4+Pj4+Pj4+IG5vdCBzcGVjaWZpZWQgYnkgSUVF RSBub3IgcmVzZXJ2ZWQgYXQgSUFOQSAtIGRvZXMgbm90IG1ha2UgaXQgDQo+Pj4+Pj4+Pj4+IGlu dGVyb3BlcmFibGUuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE9uZSB3b3VsZG4ndCB0aGluayB0 aGF0IHRoaXMgMHgwNzA3IGV0aGVydHlwZSBiZSByZXNlcnZlZCBieQ0KPj4+Pj4+Pj4+IHNvbWVi b2R5DQo+Pj4+Pj4+Pj4+IHdobyBpcyBub3QgSUFOQSBub3IgSUVFRT8NCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4gKHNlZSBhIGdvb2QgZXhhbXBsZSBvZiBpbnRlcm9wZXJhYmlsaXR5OiBJUHY2IDB4 ODZkZCANCj4+Pj4+Pj4+Pj4gZXRoZXJ0eXBlIGlzIHJlc2VydmVkIGF0IElFRUUgYW5kIGF0IElB TkENCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50 cy9pZWVlLTgwMi1udW1iZXJzL2llZWUtODAyLW51bQ0KPj4+Pj4+Pj4+PiBiZQ0KPj4+Pj4+Pj4+ PiBycy54bWwpDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4NCj4+PiBBbGV4DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE9yIHNob3Vs ZCB0aGVzZSBzdGFuZGFyZHMgcmVtYWluIGluDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IHRoZSBw dWJsaWMgZG9tYWluLCBmb3IgcmVzZWFyY2hlcyB0byByZXZpZXcgYW5kIHZhbGlkYXRlPw0KPj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBKdXN0IG15IDIgY2VudHMuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IEpvZQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBP biBNb24sIEphbiAyOCwgMjAxMyBhdCA2OjMxIEFNLCBUaGllcnJ5IEVybnN0IA0KPj4+Pj4+Pj4+ PiA8dGhpZXJyeS5lcm5zdEBpbnJpYS5mcj4gPG1haWx0bzp0aGllcnJ5LmVybnN0QGlucmlhLmZy Pg0KPj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g RGVhciBhbGwsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEF0IHRoaXMgc3RhZ2UsIEkgZG9uJ3Qg dGhpbmsgYSBuZXcgd29ya2luZyBncm91cCBpcyBuZWVkZWQuDQo+Pj4+Pj4+Pj4+IEZpcnN0LCBp dCB3b3VsZCBuZWVkIGEgY2hhcnRlciwgYW5kIHN1cHBvcnQgZnJvbSAgdGhlIGluZHVzdHJ5Lg0K Pj4+Pj4+Pj4+PiBCdXQgbW9yZSBpbXBvcnRhbnRseSwgSUVURiBXR3MgYXJlIG5vdCB1c3VhbGx5 IHNlY3Rvci1kcml2ZW4sIA0KPj4+Pj4+Pj4+PiBzbyBpdCBtZWFucyB0aGUgZGlmZmVyZW50IGlz c3VlcyBwZXJ0YWluaW5nIHRvIElUUyBzaG91bGQgYmUgDQo+Pj4+Pj4+Pj4+IGJyb3VnaHQgdG8N Cj4+Pj4+Pj4+PiBWQVJJT1VTDQo+Pj4+Pj4+Pj4+IGV4aXN0aW5nIFdHcywgYW5kIGEgV0cgc2hv dWxkIG9ubHkgYmUgY3JlYXRlZCBpZiB0aGVyZSBpcyBhbiANCj4+Pj4+Pj4+Pj4gaW1wb3J0YW50 IGlzc3VlIGZvciB3aGljaCB0aGVyZSBpcyBubyBleGlzdGluZyBXRyB0aGF0IGNvdWxkIA0KPj4+ Pj4+Pj4+PiB3b3JrIG9uIGl0Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBUaGlzIHNhaWQsIGFz IG1lbnRpb25lZCBlYXJsaWVyLCBJVFMgaXMgbm90IG9ubHkgYWJvdXQgDQo+Pj4+Pj4+Pj4+IHZl aGljdWxhciBjb21tdW5pY2F0aW9ucywgdGhvdWdoIHRoZSBpc3N1ZXMgbGlzdGVkIGJ5IA0KPj4+ Pj4+Pj4+PiBBbGV4YW5kcnUgYmVsb3cgbW9zdGx5IGNvbnNpZGVyIHZlaGljdWxhciBjb21tdW5p Y2F0aW9ucy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gV2hhdCBJVFMgcmVhbGx5IG5lZWRzIGlz IHRoZSBkZWZpbml0aW9uIG9mIGEgY29tbW9uIA0KPj4+Pj4+Pj4+PiBjb21tdW5pY2F0aW9uIGFy Y2hpdGVjdHVyZSBhbmQgdGhlIGRlZmluaXRpb24gb2Ygd2hhdCANCj4+Pj4+Pj4+Pj4gZmVhdHVy ZXMgc2hvdWxkIGJlIGNvbXByaXNlZCBmb3IgYW4gSVB2NiBuZXR3b3JraW5nIHN0YWNrIA0KPj4+ Pj4+Pj4+PiBkZXBsb3llZCBmb3IgSVRTIHVzZSBjYXNlcy4gVGhpcyBjYW5ub3QgYmUgZG9uZSBh dCBJRVRGLCBhbmQgDQo+Pj4+Pj4+Pj4+IGFjdHVhbGx5IGFscmVhZHkgZXhpc3RzIGF0IElTTzog LSBJU08gMjEyMTcgLSBBcmNoaXRlY3R1cmUgLSANCj4+Pj4+Pj4+Pj4gSVNPIDIxMjEwIC0NCj4+ Pj4+Pj4+Pj4gSVB2NiBOZXR3b3JraW5nDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEFzIGFuIGlu cHV0IHRvIHRoZSBkaXNjdXNzaW9uLCBwbGVhc2UgY29uc2lkZXIgcmVhZGluZyANCj4+Pj4+Pj4+ Pj4gZG9jdW1lbnRzIEQyLjEgYW5kIEQyLjIgYXZhaWxhYmxlIG9uIHRoZSBJVFNTdjYgcHJvamVj dCB3ZWINCj4+Pj4+Pj4+Pj4gcGFnZTogaHR0cDovL3d3dy5pdHNzdjYuZXUvZG9jdW1lbnRhdGlv bi8gRDIuMiBwcm92aWRlcyBhbiANCj4+Pj4+Pj4+Pj4gYW5hbHlzaXMgb2YgdGhlIGN1cnJlbnRs eSBwdWJsaXNoZWQgdmVyc2lvbiBvZiBJU08gMjEyMTAsIGJ1dCANCj4+Pj4+Pj4+Pj4gbmV3IHdv cmsgaXRlbXMgaGF2ZSBiZWVuIGxhdW5jaGVkIHNpbmNlIHRoZW4gdG8gYWRkcmVzcyANCj4+Pj4+ Pj4+Pj4gcmVtYWluaW5nIGlzc3Vlcy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gUmVnYXJkcywg VGhpZXJyeS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gT24gMjgvMDEvMTMgMTE6MDgsIEFsZXhhbmRydSBQZXRy ZXNjdSB3cm90ZToNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gTGUgMjgvMDEv MjAxMyAwNTowMiwgU3RhbiBSYXRsaWZmIChzcmF0bGlmZikgYSDDqWNyaXQgOg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBBbGwsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRo aXMgaXMganVzdCBvbmUgb3BpbmlvbiwgYnV0IEknZCBsaWtlIHRvIHVuZGVyc3RhbmQgd2h5IElU UyANCj4+Pj4+Pj4+Pj4gd291bGQgbmVlZCBpdHMgb3duIElFVEYgZ3JvdXAuIFRoZSB3b3JrIGhl cmUgaXMgdGhlIHNhbWUgDQo+Pj4+Pj4+Pj4+IChJTU8pIGFzIHdoYXQgaXMgdGFraW5nIHBsYWNl IGluIE1BTkVULiBJIHdvdWxkIHZvdGUgdGhhdCANCj4+Pj4+Pj4+Pj4gdGhpcyB3b3JrIGJlIHRh a2VuIHVwIGluIE1BTkVULg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+PiBTdGFuLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBUaGFuayB5b3UgZm9yIHRoZSBv ZmZlci4gIEkgY29uc2lkZXJlZCB0aGlzIG9mZmVyIHNpbmNlIHNvbWUgDQo+Pj4+Pj4+Pj4+IHRp bWUuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEkgdHJ5IHRvIHVuZGVyc3RhbmQgd2hldGhlciBz b21lIG9mIHRoZXNlIGl0ZW1zIG9uIHdoaWNoICBJIA0KPj4+Pj4+Pj4+PiBoYXZlIGludGVyZXN0 IGNvdWxkIGJlIGJyb3VnaHQgaW4gaW4gTUFORVQgV0c6IC0gVjJWIHVzaW5nIA0KPj4+Pj4+Pj4+ PiBwcmVmaXggZXhjaGFuZ2UgLSBWSU4tYmFzZWQgSVAgYWRkcmVzc2luZyBzY2hlbWUgLSAgTkQg UHJlZml4IA0KPj4+Pj4+Pj4+PiBEZWxlZ2F0aW9uIC0gUE1JUC1iYXNlZCBuZXR3b3JrIG1vYmls aXR5IC0NCj4+Pj4+Pj4+Pj4gSVB2NiBzaW5nbGUtYWRkcmVzcyBjb25uZWNpb24gJ3NoYXJpbmcn IHdpdGggYSBjZWxsdWxhciANCj4+Pj4+Pj4+Pj4gb3BlcmF0b3IgYW5kIGEgdmVoaWN1bGFyIG1v dmluZyBuZXR3b3JrICh0eXBlICc2NHNoYXJlJw0KPj4+Pj4+Pj4+PiBvZiB2Nm9wcykuIC0gRGVm YXVsdCBSb3V0ZSB3aXRoIERIQ1B2Ni4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gUGxlYXNlIGxl dCBtZSBrbm93Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBZb3VycywNCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4gQWxleA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+PiBSZWdhcmRzLCBTdGFuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE9uIEphbiAyNiwgMjAx MywgYXQgOTozNCBBTSwgQWJkdXNzYWxhbSBCYXJ5dW4gd3JvdGU6DQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEhpIE5hYmlsLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBJIHRo aW5rIHdlIGFscmVhZHkgZG9uZSBzb21lIHN0ZXBzIGJ1dCBub3Qgc3VyZSBob3cgZmFyIG5vdy4g DQo+Pj4+Pj4+Pj4+IFdlIHdpbGwgbmVlZCB0byBwcm9wb3NlIHRoZSBXRyBhbmQgcHJvdmlkZSB0 aGUgV0cgY2hhcnRlciwgYXMgDQo+Pj4+Pj4+Pj4+IHVzZSBjYXNlcyBhbmQgd29yayB0byBiZSBk b25lIGluIHRoaXMgZ3JvdXAuDQo+Pj4+Pj4+Pj4+IFRoaXMgY2hhcnRlciBuZWVkcyB0byBiZSBh cHByb3ZlZCBieSB0aGUgSUVTRy4gSSBoYXZlIG5vdCANCj4+Pj4+Pj4+Pj4gYXR0ZW5kZWQgdGhl IGxhc3QgbWVldGluZyBzbyBub3Qgc3VyZSBhYm91dCB0aGUgc3RhdHVzIG5vdywNCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gQUINCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gT24gMS8yNi8xMywgTmFi aWwgQmVuYW1hciA8YmVuYW1hcjczQGdtYWlsLmNvbT4gDQo+Pj4+Pj4+Pj4+IDxtYWlsdG86YmVu YW1hcjczQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IEhpIEFsbCwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSSdtIHN0aWxsIGludGVyZXN0ZWQg aW4gdGhpcyBsaXN0IGFuZCB3YW50IHRvIGpvaW4gdm9pY2VzIA0KPj4+Pj4+Pj4+PiBwcmV2aW91 c2x5IGhlYXJkIHRvIG1ha2UgaXQgYSB3b3JraW5nIGdyb3VwLiBTbyB3aGF0IHNob3VsZCANCj4+ Pj4+Pj4+Pj4gd2UgZXhhY3RseSBkbywgdG8gYWNoaWV2ZSB0aGlzIGdvYWwgPw0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAyMDEzLzEvMjYgQWJkdXNzYWxhbSBCYXJ5dW4gPGFi ZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPiANCj4+Pj4+Pj4+Pj4gPG1haWx0bzphYmR1c3NhbGFt YmFyeXVuQGdtYWlsLmNvbT4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSGkg QWxsLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBJIHdhcyBpbnRlcmVzdGVkIGluIHRoaXMgZ3Jv dXAgYnV0IG5vdCBzdXJlIHdoZXJlIGFyZSB3ZSAgc28gDQo+Pj4+Pj4+Pj4+IGZhci4gSXMgdGhl cmUgcHJvZ3Jlc3MsIG9yIGlzIHRoZXJlIGlzc3Vlcy9lZmZvcnRzIHRoYXQgbmVlZCANCj4+Pj4+ Pj4+Pj4gdG8gYmUgY29tcGxldGVkIGFuZCB2b2x1bnRlZXJlZC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4gQUIgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g aXRzIA0KPj4+Pj4+Pj4+PiBtYWlsaW5nIGxpc3QgaXRzQGlldGYub3JnIDxtYWlsdG86aXRzQGll dGYub3JnPiANCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pdHMNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4gLS0gKiAqICrYqtit2YrYp9iq2Yog2IwgKipDb3JkaWFsZW1lbnQsIFJlZ2FyZHMq ICogKiAqICogKtmG2KjZitmEIA0KPj4+Pj4+Pj4+PiDYqNmG2LnZhdix2YhOYWJpbCBCZW5hbWFy KiBQcm9mZXNzb3Igb2YgY29tcHV0ZXIgc2NpZW5jZXMgDQo+Pj4+Pj4+Pj4+IFNpbXVsYXRpb24g YW5kIE1vZGVsaXNhdGlvbiBMYWJvcmF0b3J5IEh1bWFuIFNjaWVuY2VzIEZhY3VsdHkgDQo+Pj4+ Pj4+Pj4+IG9mIE1la25lcyBNb3VsYXkgSXNtYWlsKiAqVW5pdmVyc2l0eSogTWVrbmVzLCBNb3Jv Y2NvICpHU006ICogDQo+Pj4+Pj4+Pj4+ICorIDIxMiA2DQo+Pj4+Pj4+Pj4+IDcwODMyMjM2IGh0 dHA6Ly9uYWJpbGJlbmFtYXIuY29tLw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAqDQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+Pj4gLS0NCj4+Pj4+Pj4+ Pj4gLS0tLS0tLQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+DQo+Pj4gLS0tLS0tLS0tLQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAqDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ Pj4+Pj4gaXRzDQo+Pj4+Pj4+Pj4+IG1haWxpbmcgbGlzdCBpdHNAaWV0Zi5vcmcgPG1haWx0bzpp dHNAaWV0Zi5vcmc+IA0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2l0cw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBpdHMNCj4+ Pj4+Pj4+PiBtYWlsaW5nDQo+Pj4+Pj4+Pj4+IGxpc3QgaXRzQGlldGYub3JnIDxtYWlsdG86aXRz QGlldGYub3JnPiANCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pdHMNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRzDQo+Pj4+ Pj4+Pj4gbWFpbGluZw0KPj4+Pj4+Pj4+PiBsaXN0IGl0c0BpZXRmLm9yZyA8bWFpbHRvOml0c0Bp ZXRmLm9yZz4gDQo+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXRzDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IGl0cyBtYWlsaW5nDQo+Pj4+Pj4+Pj4gbGlzdA0KPj4+Pj4+Pj4+PiBpdHNAaWV0Zi5vcmcgPG1h aWx0bzppdHNAaWV0Zi5vcmc+IA0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2l0cw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBpdHMgbWFpbGluZyANCj4+Pj4+Pj4+Pj4g bGlzdCBpdHNAaWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+IA0KPj4+Pj4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyBpdHMgbWFpbGluZyANCj4+Pj4+Pj4+Pj4gbGlzdCBpdHNAaWV0 Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+IA0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBpdHMgbWFpbGluZyANCj4+Pj4+Pj4+Pj4gbGlzdCBpdHNAaWV0Zi5vcmcgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gaXRzIG1haWxpbmcgDQo+Pj4+Pj4+Pj4gbGlzdCBpdHNAaWV0Zi5vcmcg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4+Pj4+Pj4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18gaXRzIG1haWxpbmcgbGlzdCANCj4+Pj4+Pj4gaXRzQGlldGYub3JnIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGl0cyBtYWlsaW5nIGxp c3QgDQo+Pj4+Pj4gaXRzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXRzDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyBpdHMgbWFpbGluZyBsaXN0IA0KPj4+Pj4gaXRz QGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+ Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBpdHMgbWFpbGluZyBsaXN0IA0KPj4+PiBpdHNAaWV0Zi5vcmcgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMgVGhlIA0KPj4+PiBpbmZvcm1hdGlvbiBj b250YWluZWQgd2l0aGluIHRoaXMgZS1tYWlsIGFuZCBhbnkgZmlsZXMgYXR0YWNoZWQgdG8gDQo+ Pj4+IHRoaXMgZS1tYWlsIGlzIHByaXZhdGUgYW5kIGluIGFkZGl0aW9uIG1heSBpbmNsdWRlIGNv bW1lcmNpYWxseSANCj4+Pj4gc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiBUaGUgY29udGVudHMgb2Yg dGhpcyBlLW1haWwgYXJlIGZvciB0aGUgDQo+Pj4+IGludGVuZGVkIHJlY2lwaWVudCBvbmx5IGFu ZCB0aGVyZWZvcmUgaWYgeW91IHdpc2ggdG8gZGlzY2xvc2UgdGhlIA0KPj4+PiBpbmZvcm1hdGlv biBjb250YWluZWQgd2l0aGluIHRoaXMgZS1tYWlsIG9yIGF0dGFjaGVkIGZpbGVzLCBwbGVhc2Ug DQo+Pj4+IGNvbnRhY3QgdGhlIHNlbmRlciBwcmlvciB0byBhbnkgc3VjaCBkaXNjbG9zdXJlLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgDQo+Pj4+IGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1 cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9uIGlzIA0KPj4+PiBwcm9oaWJpdGVkLiBQbGVhc2Ug YWxzbyBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGluZm9ybSB0aGVtIG9mIHRoZSANCj4+Pj4gZXJy b3IgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsLCBpbmNsdWRpbmcgYW55IGF0dGFjaGVkIGZpbGVzIGZy b20geW91ciANCj4+Pj4gc3lzdGVtLiBDYXNzaWRpYW4gTGltaXRlZCwgUmVnaXN0ZXJlZCBPZmZp Y2UgOiBRdWFkcmFudCBIb3VzZSwgDQo+Pj4+IENlbHRpYyBTcHJpbmdzLCBDb2Vka2VybmV3LCBO ZXdwb3J0LCBOUDEwIDhGWiBDb21wYW55IE5vOiAwNDE5MTAzNiANCj4+Pj4gaHR0cDovL3d3dy5j YXNzaWRpYW4uY29tDQo+Pj4+DQo+Pj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gaXRzIG1haWxpbmcgbGlzdA0KPj4+ IGl0c0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXRzDQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBpdHMgbWFpbGluZyBsaXN0DQo+PiBpdHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+PiAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+Pg0KPj4gRS1tYWlsIENvbmZpZGVudGlhbGl0 eSBOb3RpY2UgYW5kIERpc2NsYWltZXIuDQo+Pg0KPj4gVGhpcyBlLW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KPj4gYXJlIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2ggDQo+PiB0aGV5IGFyZSBhZGRyZXNzZWQuIEFjY2VzcyB0byB0aGlzIGUtbWFpbCBieSBhbnlv bmUgZWxzZSBpcyANCj4+IHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPj4gY29weWluZywgZGlzdHJpYnV0aW9uIG9y IGFueSBhY3Rpb24gdGFrZW4gb3Igb21pdHRlZCB0byBiZSB0YWtlbiBpbiANCj4+IHJlbGlhbmNl IG9uIGl0LCBpcyBwcm9oaWJpdGVkLg0KPj4gRS1tYWlsIG1lc3NhZ2VzIGFyZSBub3QNCj4+IG5l Y2Vzc2FyaWx5IHNlY3VyZS4gSGl0YWNoaSBkb2VzIG5vdCBhY2NlcHQgcmVzcG9uc2liaWxpdHkg Zm9yIGFueSANCj4+IGNoYW5nZXMgbWFkZSB0byB0aGlzIG1lc3NhZ2UgYWZ0ZXIgaXQgd2FzIHNl bnQuDQo+PiBIaXRhY2hpIGNoZWNrcyBvdXRnb2luZyBlLW1haWwgbWVzc2FnZXMgZm9yIHRoZSBw cmVzZW5jZSBvZiBjb21wdXRlciANCj4+IHZpcnVzZXMuDQo+PiAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGl0cyBtYWlsaW5nIGxpc3QNCj4+IGl0c0Bp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4+ DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGl0cyBtYWlsaW5nIGxpc3QNCj4gaXRzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXRzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCml0cyBtYWlsaW5nIGxpc3QNCml0c0BpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQppdHMgbWFpbGluZyBsaXN0DQppdHNAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo= From alexandru.petrescu@gmail.com Fri Jun 21 10:13:03 2013 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 D4FAF21F9FAB for ; Fri, 21 Jun 2013 10:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.954 X-Spam-Level: X-Spam-Status: No, score=-10.954 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qIUrz3rjgGI for ; Fri, 21 Jun 2013 10:12:59 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1831121F9FA1 for ; Fri, 21 Jun 2013 10:12:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5LHCu1Q009654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 21 Jun 2013 19:12:56 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5LHCuN9016912 for ; Fri, 21 Jun 2013 19:12:56 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5LHCsqT005777 for ; Fri, 21 Jun 2013 19:12:56 +0200 Message-ID: <51C48997.1000402@gmail.com> Date: Fri, 21 Jun 2013 19:12:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org References: <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr><51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr><9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com><5108EF0B.5050002@gmail.com><9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com><5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com><510A75F8.7080508@inria.fr><603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp><511F7968.7090309@gmail.com> <5177C6BA.6020805@gmail.com><85C635C4D32378499484B2C61BD297A419E9993E@GSukMHDDCembx02.service.hitachi.net><51952414.1050500@gmail.com> <51B71D4A.2010503@gmail.com> <81154EB5875DC143AFAA75562B06D1F85A11C64B@DAPHNIS.office.hd> In-Reply-To: <81154EB5875DC143AFAA75562B06D1F85A11C64B@DAPHNIS.office.hd> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Updated list of suppliers of 802.11p-compatible equipment X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:13:04 -0000 Hello Roberto, It is not one particular person, but rather an informal discussion here and there that expressed that that particular manufacturer was likely to be known by several people. It is good to know your message below. Yours, Alex Le 21/06/2013 18:06, Roberto Baldessari a écrit : > Yes, whoever provided the info about the majority of vendors using > UNEX is wrong. > > Roberto > > -----Original Message----- From: its-bounces@ietf.org > [mailto:its-bounces@ietf.org] On Behalf Of Varadi , Andras (lesswire > AG Ungarn) Sent: 13 June 2013 17:04 To: its@ietf.org Subject: Re: > [its] Updated list of suppliers of 802.11p-compatible equipment > > Dear Alexander > > Please let me add some info to the topic below > > Cohda/NXP are NOT UNEX based, but use their own SoC including > enhanced PHY+MAC for better error tolerance at high speed. (the same > goes for AutoTalks) > > Ãœdvözlettel / Best regards, András Váradi > > Project Manager :: Technical Customer Support Automotive & WLAN > Group lesswire Hungary | Office: +36 23521 667 | Email: > Varadi@lesswire.com > > > -----Original Message----- From: its-bounces@ietf.org > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Tuesday, June 11, 2013 2:51 PM To: its@ietf.org Subject: [its] > Updated list of suppliers of 802.11p-compatible equipment > > Hello participants to ITS email list, > > I added Arada Systems to the list of suppliers of 802.11p-compatible > equipment. Additionally, I have been pointed that many if not all > (?) these systems use 802.11p miniPCI boards from UNEX. > > The list is now the following: > > Arada Systems LocoMate OBU RENESAS ELECTRONICS NEC NXP/Cohda > Wireless Cisco/Cohda Wireless Denso Delphi Savari Kapsch Siemens > ITRI AutoTalks Commsignia > > Yours, > > Alex > > Le 16/05/2013 20:23, Alexandru Petrescu a écrit : >> Yes, thank you. The list is now: >> >> RENESAS ELECTRONICS NEC NXP/Cohda Wireless Cisco/Cohda Wireless >> Denso Delphi Savari Kapsch Siemens ITRI AutoTalks Commsignia >> >> Yours, >> >> Alex >> >> Le 03/05/2013 18:32, Lenardi, Massimiliano a écrit : >>> Dear All, please also add RENESAS ELECTRONICS to the list >>> below of potential suppliers of 11p/DSRC enabled radio devices. >>> Best, - Max >>> >>> >>> -----Original Message----- From: its-bounces@ietf.org >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: 24 April 2013 13:49 To: its@ietf.org Subject: Re: [its] >>> suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-5905MHz >>> >>> Recently I discovered that in addition to the posted list there >>> is also Commsignia as a manufacturer of 802.11p compatible OBU >>> and RSU. The list is now: >>> >>> NEC NXP/Cohda Wireless Cisco/Cohda Wireless Denso Delphi Savari >>> Kapsch Siemens ITRI AutoTalks Commsignia >>> >>> Yours, >>> >>> Alex >>> >>> Le 16/02/2013 13:19, Alexandru Petrescu a écrit : >>>> Le 11/02/2013 14:50, Dowdell, John a écrit : >>>>> Alex >>>>> >>>>> Is anyone making 802.11p radios commercially at reasonable >>>>> cost? The few I have seen seem to be very expensive (few k$) >>>>> and there appears to be little support in Linux. >>>> >>>> John, >>>> >>>> A person was kind enough to gather in one place information >>>> which is otherwise sparsely but publicly available; this >>>> information is about suppliers of 802.11p-over-ITS-G5 >>>> frequencies (5875-5905MHz, 5855-5875MHz, 5470-5725MHz; caveat - >>>> only some are allowed in some countries, check the local >>>> regulator before turning these on). >>>> >>>> NEC NXP/Cohda Wireless Cisco/Cohda Wireless Denso Delphi >>>> Savari Kapsch Siemens ITRI AutoTalks >>>> >>>> I have some experience with ITRI equipment. In their offer >>>> there is a full-blown RSU, for around 1500EUR. This is for a >>>> RSU hardened box for outdoors, powerpc, GPS-enabled, 2x 802.11p >>>> interfaces, Ethernet with PoE, USB, and linux 2.6. Among >>>> these, it is the software which is expensive; this includes >>>> Atheros driver modifications, new kernel modules for "BTP" >>>> (Base Transmission Protocol?), 'geonetworking', 'wave'. >>>> >>>> OTher than a full-blown RSU, one could acquire also ITRI >>>> individual '802.11p' miniPCI cards which are in the order of >>>> couple hundreds of euros. >>>> >>>> This is not a commercial advertisement. Technically speaking >>>> this means many things for designing protocols. For example: >>>> >>>> It means it is easily possible to run linux with IPv6 over a >>>> 'wave0' interface. Just turn it on, watch the IPv6 link-local >>>> address, echo the frequency value and ping. (no need to set >>>> ESSID, nor security). >>>> >>>> In addition to the Ethernet interfaces, the RSU has _2_ >>>> 802.11p different interfaces, and one Ethernet. Not just two >>>> antennas, but two interfaces (ifconfig 'wave0' and 'wave1'). >>>> This means one doesn't need to 'relay' packets and that one >>>> needs to 'route' packets, in the traditional sense of >>>> 'routing'. (compare this for example to RPL context where a >>>> sensor has a _single_ interface and there is no routing, but >>>> 'relaying'). >>>> >>>> Also this outdoors RSU has 1 GPS antenna. This means that >>>> geonetworking does not work if one tries to use this indoors in >>>> a lab where GPS signal does not reach. (unless one installs a >>>> GPS 'repeater' - easy to do but check with regulator in >>>> country, or use a GPS 'replayer' software to play pre-recorded >>>> NMEA sentences on /dev/tty). >>>> >>>> Note also it is strange to design an RSU Road Side Unit - >>>> designed to be fixed with respect to Earth, and put a GPS >>>> interface on it. It would have been easier to just record the >>>> GPS coordinates once and set them in a file for as long as that >>>> RSU stays there. I consider it as an extra, but cheaper RSU >>>> without GPS should be possible. >>>> >>>>> 802.11s on the other hand is available on standard Wi-Fi >>>>> dongles (from $15) and drivers are already available in >>>>> Linux. Is it correct that 802.11p is mandated for ITS in some >>>>> regions? >>>> >>>> I doubt 802.11p be mandated for ITS. >>>> >>>> I think the regulator mandates the application which could be >>>> used on some frequencies. >>>> >>>> Where I live, the regulator mandates the use of vehicular >>>> 'safety' applications at 5875-5905MHz. The technical >>>> 'conditions' are referred by the regulator to ETSI documents >>>> (the regulator is not ETSI, but often implements what ETSI >>>> wants, but not always). I doubt the regulator mandates >>>> 'geonetworking' for this band. >>>> >>>> I doubt 'IP' could be qualified as 'safety'. >>>> >>>> Hence I think 802.11s _could_ be used on the range >>>> 5875-5905MHz, as long as it does not transport IP. >>>> >>>> 802.11p has some features which could qualify as 'safety'. >>>> For example, it has some MAC-layer messages for 'emergency', >>>> and with timestamps (absent from .11 non-p standard), which >>>> don't transport IP. >>>> >>>> 'geonetworking' also has some features which could qualify as >>>> 'safety'. I just don't remember which. >>>> >>>> What features in 802.11s would qualify as 'safety'? >>>> >>>> Alex >>>> >>>>> >>>>> John >>>>> >>>>> -----Original Message----- From: its-bounces@ietf.org >>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>>> Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: >>>>> [its] IP over 802.11p >>>>> >>>>> Le 31/01/2013 14:47, Thierry Ernst a écrit : >>>>>> >>>>>> Well, we do actually run IPv6 over 11p (with or without >>>>>> GeoNetworking), so I don't see what kind of issues there >>>>>> might be ... >>>>> >>>>> I have some clarification questions about EtherType and >>>>> 802.11p and GeoNetworking. >>>>> >>>>> I guess when you run IPv6 over 11p with GeoNetworking, the >>>>> Ethernet header uses EtherType soon-to-be-0x8947, whereas >>>>> when you run IPv6 over 11p without GeoNetworking, the >>>>> Ethernet header uses EtherType 0x86DD. This is just a >>>>> supposition, I don't know how you run it. >>>>> >>>>> Also, if I run IPv4 over 11p with GeoNetworking - should I >>>>> use EtherType soon-to-be-0x8947? Or other? I suppose that >>>>> if I run IPv4 over 11p without GeoNetworking I should use >>>>> EtherType 0x0800, and if it's ARP over 802.11p still without >>>>> GeoNetworking then I should use EtherType 0x0806. >>>>> >>>>> (the letter we've seen recently is not clear whether that >>>>> allocation is for GeoNetworking, for IP-over-802.11p, for >>>>> ETSI ITS, for GeoNetworking for IPv6, for GeoNetworking for >>>>> IPv4, etc. It is not clear either whether GeoNetworking >>>>> supports IPv4 or not, or under what form). >>>>> >>>>> I also have some questions about the relationship between >>>>> the nature of some 802.11p links (no ESSID, absence of >>>>> link-layer security - as opposed to WiFi which has ESSID and >>>>> link-layer security) and IP. >>>>> >>>>> For example - will V2V prefix exchange using Router >>>>> Advertisements work easier on 802.11p links (easier than on >>>>> WiFi), because the ESSID does not need to be discovered, the >>>>> ad-hoc network does not need to be formed - suffices it to >>>>> send packets on a certain channel. >>>>> >>>>> (in a V2V draft one seems to say that the presence of Access >>>>> Point is absolutely necessary in order for 802.11p to work; >>>>> but in our experimentations this is not the case - it is >>>>> possible to establish direct vehicle-to-vehicle >>>>> IP-over-802.11p communications without the presence of a >>>>> fixed 802.11p Access Point). >>>>> >>>>> For another example - will IP prefer that the 802.11p channel >>>>> in France be 176, 178 or 180? (with WiFi, IP does not care >>>>> because it can work on any of the 11 channels equally well, >>>>> but with 802.11p each of these three channels seem to be >>>>> reserved for "Services", "Control" and "Services"). >>>>> >>>>> For another example - is all the security on these links >>>>> entirely relaying on IP layer security (IPsec, SeND, EAP, >>>>> PANA)? >>>>> >>>>> I think finding consensus on some of these questions could >>>>> lead to interoperability. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Regards, Thierry >>>>>> >>>>>> >>>>>> >>>>>> On 31/01/13 13:55, Alexandru Petrescu wrote: >>>>>>> Given current discussions, I think it may be worth >>>>>>> considering a work item about how to run IP over >>>>>>> 802.11p. >>>>>>> >>>>>>> One of the things to say would be whether or not this is >>>>>>> IPv6 only or IPv4 also. >>>>>>> >>>>>>> This would say how this would work _without_ >>>>>>> GeoNetworking. >>>>>>> >>>>>>> It would agree on the EtherType and/or whether there are >>>>>>> new ones, several or only one, or reusing existing >>>>>>> EtherTypes. >>>>>>> >>>>>>> It could be as simple as to say that IP works over >>>>>>> 802.11p just as it works over 802.11b - no >>>>>>> modifications. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> Le 30/01/2013 11:10, Alexandru Petrescu a écrit : >>>>>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a écrit : >>>>>>>>> Hi Alexandru, >>>>>>>>> >>>>>>>>> IEEE talk only hexa in their Ethertype files. >>>>>>>> >>>>>>>> I tend to agree that #8947 is a hexadecimal notation >>>>>>>> also because the sharp sign preceding it, and because >>>>>>>> if it were decimal it would convert to 22F3 which is >>>>>>>> already reserved for trill. >>>>>>>> >>>>>>>> I just watend to make sure. >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- From: >>>>>>>>>> its-bounces@ietf.org [mailto:its-bounces@ietf.org] >>>>>>>>>> On Behalf Of Alexandru Petrescu Sent: Wednesday, >>>>>>>>>> January 30, 2013 12:00 PM To: its@ietf.org Subject: >>>>>>>>>> Re: [its] What do we need to make ITS WG go >>>>>>>>>> forward? - EtherType for ITS >>>>>>>>>> >>>>>>>>>> Hello Dan, >>>>>>>>>> >>>>>>>>>> Thank you for the email. >>>>>>>>>> >>>>>>>>>> I think we definitely need a good interface with >>>>>>>>>> IEEE about this. >>>>>>>>>> >>>>>>>>>> Maybe you could ask them whether this number is >>>>>>>>>> hexa or decimal, so we know what to put in >>>>>>>>>> implementation (e.g. wireshark packet analyzers, >>>>>>>>>> and 802.11p/etsi-its implementations). >>>>>>>>>> >>>>>>>>>> Also, I am interested to learn whether this >>>>>>>>>> deserves being reserved at IANA. >>>>>>>>>> >>>>>>>>>> Alex >>>>>>>>>> >>>>>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a écrit >>>>>>>>>> : >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> The documents that you are referring (on the >>>>>>>>>>> ETSI server) are not freely accessible. A >>>>>>>>>>> password is required, and probably only ETSI >>>>>>>>>>> members have the access information. >>>>>>>>>>> >>>>>>>>>>> The responsibility for assigning EtherType values >>>>>>>>>>> is with the IEEE Registration Authority. They >>>>>>>>>>> maintain a public list (updated daily) at >>>>>>>>>>> http://standards.ieee.org/develop/regauth/ethertype/eth.txt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>> >>>>>>>>>>> and according to this list the value 8947 is not allocated. >>>>>>>>>>> Now, the public listing information for >>>>>>>>>>> EtherTypes bears a disclaimer that says >>>>>>>>>>> >>>>>>>>>>> * This is a partial listing of all assigned >>>>>>>>>>> EtherType Fields. Not >>>>>>>>>> all >>>>>>>>>>> recipients wish to publish their assignment at >>>>>>>>>>> this time. >>>>>>>>>>> >>>>>>>>>>> Did ETSI require for this information not to be >>>>>>>>>>> published? It does not look useful if they want >>>>>>>>>>> to encourage interoperability >>>>>>>>>>> >>>>>>>>>>> Value 0707 mentioned in the thread is not >>>>>>>>>>> allocated either. >>>>>>>>>>> >>>>>>>>>>> Let me know if I can help (as IETF liaison to the >>>>>>>>>>> IEEE-SA). >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> *From:*its-bounces@ietf.org >>>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, >>>>>>>>>>> 2013 11:11 AM *To:* its@ietf.org *Subject:* Re: >>>>>>>>>>> [its] What do we need to make ITS WG go forward? >>>>>>>>>>> - EtherType for ITS >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Alex, >>>>>>>>>>> >>>>>>>>>>> IEEE have assigned Ethernet Type Field number >>>>>>>>>>> #8947 for ITS use (ETSI TC ITS's GeoNetworking). >>>>>>>>>>> Check the following document available on the >>>>>>>>>>> ETSI server: >>>>>>>>>>> >>>>>>>>>>> ITS(13)000020 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 3% >>>>>>>>>>> 2900002 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>> 0_Ethernet_Type_Field_number_for_GeoNetworking.pdf> >>>>>>>>>>> Ethernet Type Field number for GeoNetworking >>>>>>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)0 >>>>>>>>>>> >>>>>>>>>>> 00 >>>>>>>>>>> 020_Eth >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>> ernet_Type_Field_number_for_GeoNetworking.pdf >>>>>>>>>>> >>>>>>>>>>> Regards, Thierry. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote: >>>>>>>>>>> >>>>>>>>>>> Le 28/01/2013 14:16, Joe Klein a écrit : >>>>>>>>>>> >>>>>>>>>>> I really dislike the fact that ISO is charging >>>>>>>>>>> for the ISO 21217 - Architecture & ISO 21210 - >>>>>>>>>>> IPv6 Networking. >>>>>>>>>>> >>>>>>>>>>> Does this make it any better? Safer? Should ISO >>>>>>>>>>> now have cybersecurity and safety liability if >>>>>>>>>>> the specification leads to deaths and damage to >>>>>>>>>>> property? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Does it make any better interoperable as well? >>>>>>>>>>> >>>>>>>>>>> EtherType 0x0707 described in ITS documents, >>>>>>>>>>> implemented, but not specified by IEEE nor >>>>>>>>>>> reserved at IANA - does not make it >>>>>>>>>>> interoperable. >>>>>>>>>>> >>>>>>>>>>> One wouldn't think that this 0x0707 ethertype be >>>>>>>>>>> reserved by >>>>>>>>>> somebody >>>>>>>>>>> who is not IANA nor IEEE? >>>>>>>>>>> >>>>>>>>>>> (see a good example of interoperability: IPv6 >>>>>>>>>>> 0x86dd ethertype is reserved at IEEE and at IANA >>>>>>>>>>> >>>>>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-num >>>>>>>>>>> >>>>>>>>>>> be >>>>>>>>>>> rs.xml) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>> Alex >>>>>>>>>>> >>>>>>>>>>> Or should these standards remain in >>>>>>>>>>> >>>>>>>>>>> the public domain, for researches to review and >>>>>>>>>>> validate? >>>>>>>>>>> >>>>>>>>>>> Just my 2 cents. >>>>>>>>>>> >>>>>>>>>>> Joe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Dear all, >>>>>>>>>>> >>>>>>>>>>> At this stage, I don't think a new working group >>>>>>>>>>> is needed. First, it would need a charter, and >>>>>>>>>>> support from the industry. But more importantly, >>>>>>>>>>> IETF WGs are not usually sector-driven, so it >>>>>>>>>>> means the different issues pertaining to ITS >>>>>>>>>>> should be brought to >>>>>>>>>> VARIOUS >>>>>>>>>>> existing WGs, and a WG should only be created if >>>>>>>>>>> there is an important issue for which there is no >>>>>>>>>>> existing WG that could work on it. >>>>>>>>>>> >>>>>>>>>>> This said, as mentioned earlier, ITS is not only >>>>>>>>>>> about vehicular communications, though the issues >>>>>>>>>>> listed by Alexandru below mostly consider >>>>>>>>>>> vehicular communications. >>>>>>>>>>> >>>>>>>>>>> What ITS really needs is the definition of a >>>>>>>>>>> common communication architecture and the >>>>>>>>>>> definition of what features should be comprised >>>>>>>>>>> for an IPv6 networking stack deployed for ITS use >>>>>>>>>>> cases. This cannot be done at IETF, and actually >>>>>>>>>>> already exists at ISO: - ISO 21217 - Architecture >>>>>>>>>>> - ISO 21210 - IPv6 Networking >>>>>>>>>>> >>>>>>>>>>> As an input to the discussion, please consider >>>>>>>>>>> reading documents D2.1 and D2.2 available on the >>>>>>>>>>> ITSSv6 project web page: >>>>>>>>>>> http://www.itssv6.eu/documentation/ D2.2 provides >>>>>>>>>>> an analysis of the currently published version of >>>>>>>>>>> ISO 21210, but new work items have been launched >>>>>>>>>>> since then to address remaining issues. >>>>>>>>>>> >>>>>>>>>>> Regards, Thierry. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a >>>>>>>>>>> écrit : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> All, >>>>>>>>>>> >>>>>>>>>>> This is just one opinion, but I'd like to >>>>>>>>>>> understand why ITS would need its own IETF group. >>>>>>>>>>> The work here is the same (IMO) as what is taking >>>>>>>>>>> place in MANET. I would vote that this work be >>>>>>>>>>> taken up in MANET. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Stan, >>>>>>>>>>> >>>>>>>>>>> Thank you for the offer. I considered this offer >>>>>>>>>>> since some time. >>>>>>>>>>> >>>>>>>>>>> I try to understand whether some of these items >>>>>>>>>>> on which I have interest could be brought in in >>>>>>>>>>> MANET WG: - V2V using prefix exchange - VIN-based >>>>>>>>>>> IP addressing scheme - ND Prefix Delegation - >>>>>>>>>>> PMIP-based network mobility - IPv6 single-address >>>>>>>>>>> connecion 'sharing' with a cellular operator and >>>>>>>>>>> a vehicular moving network (type '64share' of >>>>>>>>>>> v6ops). - Default Route with DHCPv6. >>>>>>>>>>> >>>>>>>>>>> Please let me know. >>>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> >>>>>>>>>>> Alex >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, Stan >>>>>>>>>>> >>>>>>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Nabil, >>>>>>>>>>> >>>>>>>>>>> I think we already done some steps but not sure >>>>>>>>>>> how far now. We will need to propose the WG and >>>>>>>>>>> provide the WG charter, as use cases and work to >>>>>>>>>>> be done in this group. This charter needs to be >>>>>>>>>>> approved by the IESG. I have not attended the >>>>>>>>>>> last meeting so not sure about the status now, >>>>>>>>>>> >>>>>>>>>>> AB >>>>>>>>>>> >>>>>>>>>>> On 1/26/13, Nabil Benamar >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> I'm still interested in this list and want to >>>>>>>>>>> join voices previously heard to make it a working >>>>>>>>>>> group. So what should we exactly do, to achieve >>>>>>>>>>> this goal ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> I was interested in this group but not sure where >>>>>>>>>>> are we so far. Is there progress, or is there >>>>>>>>>>> issues/efforts that need to be completed and >>>>>>>>>>> volunteered. >>>>>>>>>>> >>>>>>>>>>> AB >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- * * *تحياتي ØŒ **Cordialement, Regards* * * * * >>>>>>>>>>> *نبيل بنعمروNabil Benamar* Professor of computer >>>>>>>>>>> sciences Simulation and Modelisation Laboratory >>>>>>>>>>> Human Sciences Faculty of Meknes Moulay Ismail* >>>>>>>>>>> *University* Meknes, Morocco *GSM: * *+ 212 6 >>>>>>>>>>> 70832236 http://nabilbenamar.com/ >>>>>>>>>>> >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>> ---------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>> its >>>>>>>>>>> mailing list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its >>>>>>>>>> mailing >>>>>>>>>>> list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its >>>>>>>>>> mailing >>>>>>>>>>> list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing >>>>>>>>>> list >>>>>>>>>>> its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> The information contained within this e-mail and any files >>>>> attached to this e-mail is private and in addition may >>>>> include commercially sensitive information. The contents of >>>>> this e-mail are for the intended recipient only and therefore >>>>> if you wish to disclose the information contained within this >>>>> e-mail or attached files, please contact the sender prior to >>>>> any such disclosure. If you are not the intended recipient, >>>>> any disclosure, copying or distribution is prohibited. Please >>>>> also contact the sender and inform them of the error and >>>>> delete the e-mail, including any attached files from your >>>>> system. Cassidian Limited, Registered Office : Quadrant >>>>> House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company >>>>> No: 04191036 http://www.cassidian.com >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> ********************************************************************* >>> >>> ***************************** >>> >>> E-mail Confidentiality Notice and Disclaimer. >>> >>> This e-mail and any files transmitted with it are confidential >>> and are intended solely for the use of the individual or entity >>> to which they are addressed. Access to this e-mail by anyone else >>> is unauthorised. If you are not the intended recipient, any >>> disclosure, copying, distribution or any action taken or omitted >>> to be taken in reliance on it, is prohibited. E-mail messages are >>> not necessarily secure. Hitachi does not accept responsibility >>> for any changes made to this message after it was sent. Hitachi >>> checks outgoing e-mail messages for the presence of computer >>> viruses. >>> ********************************************************************* >>> >>> ***************************** >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From alexandru.petrescu@gmail.com Fri Jun 21 10:21:17 2013 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 E06DD21F961F for ; Fri, 21 Jun 2013 10:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.318 X-Spam-Level: X-Spam-Status: No, score=-10.318 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCZFLg5OnxVB for ; Fri, 21 Jun 2013 10:21:12 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C562721E8127 for ; Fri, 21 Jun 2013 10:21:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5LHL3nQ011636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 21 Jun 2013 19:21:03 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5LHL3ob018077 for ; Fri, 21 Jun 2013 19:21:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5LHKmvR017674 for ; Fri, 21 Jun 2013 19:21:03 +0200 Message-ID: <51C48B70.3050606@gmail.com> Date: Fri, 21 Jun 2013 19:20:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: multipart/mixed; boundary="------------050900010806070306010409" Subject: [its] 3rd area: Establishment of IP networking between vehicles X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:21:17 -0000 This is a multi-part message in MIME format. --------------050900010806070306010409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The third area potentially to be addressed is "Establishment of IP networking between vehicles". This can be achieved either with MANET protocols or with 1-hop ND extensions. A few use cases exist for traffic management (e.g. allow IPv6 streaming of the video seen by the front vehicle to the rear vehicle, when cellular infrastructure is present or absent). There are two I-Ds about this, and there is ISO activity in this area as well. What do you think about this area? Alex --------------050900010806070306010409 Content-Type: text/plain; charset=windows-1252; name="its-11.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its-11.txt" Intelligent Transportation Systems at IETF Draft Charter Proposal May 29th, 2013 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: Informal Chairs: TBD TBD Assigned Area Director: TBD () Mailing list Address: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: http://www.ietf.org/mail-archive/web/its/current/maillist.html Additional web page http://www.lara.prd.fr/ietf-its Draft Charter Proposal: Context ------- Intelligent Transportation Systems (ITS) ITS is about extending the Internet to mobile vehicular platforms. These platforms include: vehicles and embedded devices (ruggedized units, actuators and sensors), mobile devices carried by passengers (tablets, smartphones) and fixed infrastructure units (Internet access points, charge stations, geo-broadcasting units). The entire system may be connected to the Internet with generic radio-WANs or radio-LANs specific to vehicular communications; in certain cases the vehicles are disconnected from the Internet yet may be inter-connected to each another, in an ad-hoc manner. Each moving vehicle may use disjoint heterogeneous radio systems (e.g. a vehicle employs two or more different radios which may be used simultaneously, or alternatively). They radios have the following characteristics: - lower capacity, higher noise than customary Internet plumbing. - presence of mission critical needs and safety applications. - stable in-vehicle network structure. - volatile topology as vehicles (and the routers they contain) move. An example scenario of vehicular communications is the following: an instrumented ambulance is connected to the Internet and offers access to individual equipments deployed in-vehicle; it moves through a traffic jam and may signal its direction by multicasting IP communication packets over IEEE 802.11p direct links, or it establishes direct subnets to vehicles to request their position. Other similar scenarios are described in a dedicated document. The areas addressed by the group are the following: (1) establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol, (2) layering of IPv6 over IEEE 802.11p communication technology and (3) IPv6-based network-layer distribution of content in a geographic area. For each of the three areas, security aspects will be considered: authenticity of routing message exchanges, influence of the absence of link-layer security of IEEE 802.11p, and security of multicast distribution. In each of these areas, the problem space will be identified in detail, in a dedicated draft. The problem will be expressed in terms of protocol behaviour and point precisely to the lack of feature or other breaking points. For the IP addressing and mobility aspects of in-vehicle subnetworks, single-subnet V2V, and single-subnet V2I, the WG will consider and if necessary, profile, existing IPv6 network protocols. The protocols considered are: MANET protocols, ICMPv6, MLDv2. Other higher layer protocols, although relevant to geo-localization, will be considered as a complete reuse (e.g. RFC 5222). Establishment of networking from vehicle to ground is considered achieved to a large extent, by using existing IPv6 protocols (Mobile IPv6). This would be out of scope of work. Several Standards Development Organizations outside IETF work towards developing protocols for vehicular communications, in a non overlapping manner. In some cases IP protocols are used for transport, in other cases IP protocols are modified for purposes particular to vehicular communications. The group ISO TC204 describes ITS station architecture, IPv6 networking and security, and optimizations. The group ETSI ITS describes IPv6 for networking in vehicles. IEEE TGp, AUTOSAR, GENIVI and IPSO describe other aspects of vehicular communications. When possible, liaisons will be established with these organizations. This group will survey these SDO's documents to identify how it relates to this group's work. Potential new work items ------------------------ The following potential work items exist: Scenarios and requirements for vehicular communications will be developed which introduce at IETF the terms V2V, V2I, V2R and intra-vehicular paradigms. Define various possible scenarios for IP vehicular communications and identify requirements that are essential to support the defined scenarios. Practices and gap analysis for IP vehicular communications: document practices for the deployment of existing IP protocols and identify any limitation of the existing IP protocols to fulfill the scenarios and requirements for IP vehicular communications. The use of IP over 802.11p - with or without intermediary layers, with or without modifications - will de described. One particular practice to document is the IP addressing architecture within a vehicle, between vehicles, and between vehicle and infrastructure: the preferred address auto-configuration methods, the requirements for address stability and scope of visibility (in-vehicle, to vehicles nearby, to infrastructure, to Internet, etc.) A problem statement draft should be written which documents the problem which is a real-world problem, points precisely to the protocols which may break, and may easily lead to a solution that can be designed in a straightforward manner. Milestones: Jul 2013 - Meet in Berlin Jul 2013 - Present drafts "Scenarios and Requirements for IP in Intelligent Transportation Systems", and Gap Analysis Jul 2013 - Present drafts on Route Exchange between vehicles Jul 2013 - Present MANET landscape for V2V2V Nov 2013 - Present status from ISO Nov 2013 - Present gap analysis and requirements Mar 2014 - Present problem statement Jul 2014 - Present solution drafts Nov 2014 - Present solution drafts --------------050900010806070306010409-- From john@moring.net Fri Jun 21 11:18:44 2013 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 5C4AF21F9811 for ; Fri, 21 Jun 2013 11:18:44 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4+V6PnUeW5l for ; Fri, 21 Jun 2013 11:18:39 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7FF21F9BE5 for ; Fri, 21 Jun 2013 11:18:37 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r5LIIaSC024213 for ; Fri, 21 Jun 2013 14:18:36 -0400 Received: (qmail 10727 invoked by uid 0); 21 Jun 2013 18:18:36 -0000 X-TCPREMOTEIP: 75.80.25.247 X-Authenticated-UID: john@moring.net Received: from unknown (HELO MoringBlackDell) (john@moring.net@75.80.25.247) by 0 with ESMTPA; 21 Jun 2013 18:18:35 -0000 From: "John Moring" To: References: <51C1780D.4020109@gmail.com> In-Reply-To: <51C1780D.4020109@gmail.com> Date: Fri, 21 Jun 2013 11:18:44 -0700 Message-ID: <38292F9D41AE4941B0438309C051B089@MoringBlackDell> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac5szmtTbRH6fufgRCmR/6351AZrIwBzFMHg X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 18:18:44 -0000 Greetings, I am editor of IEEE 1609.3 (and some of the other 1609 standards); I've recently started watching this forum. I appreciate the feedback on IPv6 references, and we'll try to tighten that specification up on our next pass. Allow me to explain the rationale for the WAVE Routing Advertisement (WRA), which is optionally sent as part of the WAVE Service Advertisement (WSA). One usage scenario is a vehicle driving past a roadside unit (RSU) and wishing reach an IP-based server through that RSU while within radio range. The RSU broadcasts the WSA with WRA, perhaps every few 10s of milliseconds. Upon receipt of the WSA, the vehicle has everything it needs (service info, router info, perhaps addressing) to access the server, allowing it to use the rest of its limited connectivity opportunity for application info exchange. Using the standard discovery mechanism (which is allowed) would reduce the time available for application transfer in this scenario. We have not performed an analysis to estimate the time savings. IP traffic is prohibited on the IEEE 1609 control channel (CCH) for legacy reasons. When the requirement was written, we expected the CCH to carry a heavy load of safety traffic as well as control info such as the WSA. Now, the bulk of safety traffic is expected to use a different channel, and we will revisit the prohibition of IP on the CCH. We are currently collecting input for both corrections and improvements to 1609.3-2010 and 1609.4-2010. Any suggestions are welcome. Regards, John Moring -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Wednesday, June 19, 2013 2:21 AM To: its@ietf.org Subject: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration ITSsers, Following the mentioning of IEEE P1609.3 'Networking Services'. It is good that we have a contact with IEEE about P1609 and I look forward for closer collaboration. To that end, let me mention technical aspects of IPv6 Address Auto-Configuration. The document IEEE P1609.3/D5.0 Draft Standard for Wireless Access in Vehicular 3 Environments (WAVE) - Networking Services, March 2010, describes among other things aspects related to IPv6 address auto-configuration. > For WAVE devices supporting dynamic IP addressing, the WME shall > calculate the global IPv6 address 18 via a stateless configuration > procedure. This is the procedure described in RFC 3513, For more precision, instead of the Proposed Standard RFC3513 "IPv6 Addressing Architecture" one would rather mention the Draft Standard RFC4291 of same title. At IETF a Draft Standard status witnesses wider adoption than Proposed Standard status. Moreover, if the intent of the text is to refer to the procedure of stateless address autoconfiguration then the more precise reference would rather be RFC4862 "Stateless Address Autoconfiguration". In addition, there is another tool for dynamic IP addressing: DHCPv6 in RFC3315. > except the WAVE device uses its MAC address in conjunction with the > IpPrefix received in the WaveRoutingAdvertisement of a WAVE Service > Advertisement, rather than that received in an RFC 4861 Router > Advertisement message. This may be an unncessarily new way to do same functionality. The use of RA is widely implemented and it should be preferred over the use of link-layer specific mechanisms to realize address autoconfiguration. In the past we have seen in the cellular space a similar mechanism to configure IPv6 addresses with RANAP protocol. At IEEE also we seem to be seing the same thing in 802.11ai for Fast Initial Link Setup. These alternative ways to configure IP addresses are obviously incompatible and may need to converge. > WAVE provides this IP configuration information in the WAVE Service > Advertisement to minimize the need for neighbor and router discovery > with their associated overhead and latency. The ND and router discovery may function quite fast. > Note that IP transmissions are prohibited on the control channel. It may be that IP transmissions are not prohibited on the control channel. Some of the 'road safety' and 'traffic efficiency applications' of ETSI ITS may not be prohibited from using IP, hence transmitted on the control channel. Alex _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Fri Jun 21 12:41:26 2013 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 7D3D221F9929 for ; Fri, 21 Jun 2013 12:41:26 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09uZnBYiG3Kq for ; Fri, 21 Jun 2013 12:41:26 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id C121A21F96EB for ; Fri, 21 Jun 2013 12:41:25 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so927277wib.12 for ; Fri, 21 Jun 2013 12:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=c1sDMHBJQXrJLMaUrMwgn7VJ8FjOcNvnPoGbIBkfOIA=; b=DVniTxt7mmx7fZx5SbW0mUKIDc8aMc99jsj+GSUnFvuVGdBtDo2bgvEzl2T5ZonGW6 k1PX52/W+CzDBEaBlKpr0n7pDeEUReWRoYufEkxG/55sl5aPyOEcD0Q5iMAVqPvChnxp EFMq7Gija70tNadJQzx9lep0vF5IpouVpNKPBToL5+27eIHpAQz6P7KHKgXHLTIQqnjX QWZLjKNR0oNyfMJcrECN2QlhjVqqTghrOJ6dcDn1Fl90tS4BfODXSJetTYG3tCLOMk7j kL7wXXBNtE/NXlN7ivwseMCwMUtvxfbiDqZ2WAgNCA5BowHxwxVy5PxMFyl/CREMVLjJ 4IRw== X-Received: by 10.181.13.75 with SMTP id ew11mr655244wid.2.1371843684050; Fri, 21 Jun 2013 12:41:24 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPSA id b11sm24980598wiv.10.2013.06.21.12.41.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 12:41:23 -0700 (PDT) Message-ID: <51C4AC5B.3060404@gmail.com> Date: Fri, 21 Jun 2013 21:41:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130621-2, 21/06/2013), Outbound message X-Antivirus-Status: Clean Subject: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 19:41:26 -0000 Hello participants to ITS email list, The IESG has not approved the request for BoF ITS in Berlin. I still have to summarize the information I receive about the process, the reasons, the next steps; I will email the list shortly. In the mean time, do not hesitate to make questions. Yours, Alex From buddenbergr@gmail.com Fri Jun 21 15:02:47 2013 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 092D121F930C for ; Fri, 21 Jun 2013 15:02:47 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18jY8S9fJ1oS for ; Fri, 21 Jun 2013 15:02:46 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2020221F9A3E for ; Fri, 21 Jun 2013 15:02:31 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb1so8317776pad.23 for ; Fri, 21 Jun 2013 15:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=G82HmmaLiVARIgFWX3ithVYsZBMV7DP5FKukmmrjuSk=; b=nm4jyT/WOa4LcxRMFfWlsnZ+44EWRToB1hMBh1RQRrLkGGXmy96cAJ3G2jVMXhfMTr ve92oTSlEDYGosMYfSByDW0VNkStc6/QFzvVBAh2aVLYaIBU9x89WUlyWMxnN9uoFq2x Xd2YEIT5Kxx8jHUP2aPX79FFr5QNKoae441hnS+hKsdnQO8wQKqL0VtZX0d3DuDqa1Gw 4JxOGdlgm66E/m7F0hor0OItUIx9CU0cWLlVm8aIhG4myOTKSgkGkhcyy9DSa5UKsTjQ wHcMO6ibWTqQd2gOdbbC/0cqbszh+GGBYNY8eDYHsNo1divm/8FjjknCydK3PvhqA4r/ 1IVQ== X-Received: by 10.68.213.5 with SMTP id no5mr14396713pbc.185.1371852150825; Fri, 21 Jun 2013 15:02:30 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id pm7sm6388292pbb.31.2013.06.21.15.02.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 21 Jun 2013 15:02:30 -0700 (PDT) Message-ID: <1371852148.7392.31.camel@localhost> From: Rex Buddenberg To: John Moring Date: Fri, 21 Jun 2013 15:02:28 -0700 In-Reply-To: <38292F9D41AE4941B0438309C051B089@MoringBlackDell> References: <51C1780D.4020109@gmail.com> <38292F9D41AE4941B0438309C051B089@MoringBlackDell> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 22:02:47 -0000 > Any suggestions are welcome. > You _had_ to ask. John, I've spent the past decade observing the internet-ready standards work for extending the internet to mobile platforms (e.g. IEEE 802.16) and the past three years or so specifically looking at emergency services -- fire, ambulance, police -- and their communications needs. But none of the NPSTC (National Public Safety Telecom Council) sources (to pick just one example) seem to have any reference to IEEE 1609. NPSTC, for reasons they probably can't explain, have latched onto LTE as the layer 1/2 protocol. Emergency services has a segregated 800MHz band of spectrum available. (This is US-specific). Given the overlap in needs and infrastructures, this is odd. It appears that extending the internet to mobile platforms is a thought-piece that has lots of independent players in their own silos. The general recommendation is that these ought to be 'liaised' together better (at all?) to forestall a lot of circular motion. On Fri, 2013-06-21 at 11:18 -0700, John Moring wrote: > Greetings, I am editor of IEEE 1609.3 (and some of the other 1609 > standards); I've recently started watching this forum. > > I appreciate the feedback on IPv6 references, and we'll try to tighten that > specification up on our next pass. > > Allow me to explain the rationale for the WAVE Routing Advertisement (WRA), > which is optionally sent as part of the WAVE Service Advertisement (WSA). > One usage scenario is a vehicle driving past a roadside unit (RSU) and > wishing reach an IP-based server through that RSU while within radio range. > The RSU broadcasts the WSA with WRA, perhaps every few 10s of milliseconds. > Upon receipt of the WSA, the vehicle has everything it needs (service info, > router info, perhaps addressing) to access the server, allowing it to use > the rest of its limited connectivity opportunity for application info > exchange. Using the standard discovery mechanism (which is allowed) would > reduce the time available for application transfer in this scenario. We have > not performed an analysis to estimate the time savings. > > IP traffic is prohibited on the IEEE 1609 control channel (CCH) for legacy > reasons. When the requirement was written, we expected the CCH to carry a > heavy load of safety traffic as well as control info such as the WSA. Now, > the bulk of safety traffic is expected to use a different channel, and we > will revisit the prohibition of IP on the CCH. > > We are currently collecting input for both corrections and improvements to > 1609.3-2010 and 1609.4-2010. Any suggestions are welcome. > > Regards, > John Moring > > > > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Wednesday, June 19, 2013 2:21 AM > To: its@ietf.org > Subject: [its] P1609.3 Networking Services and IPv6 > AddressAuto-Configuration > > ITSsers, > > Following the mentioning of IEEE P1609.3 'Networking Services'. It is good > that we have a contact with IEEE about P1609 and I look forward for closer > collaboration. > > To that end, let me mention technical aspects of IPv6 Address > Auto-Configuration. > > The document IEEE P1609.3/D5.0 Draft Standard for Wireless Access in > Vehicular 3 Environments (WAVE) - Networking Services, March 2010, describes > among other things aspects related to IPv6 address auto-configuration. > > > For WAVE devices supporting dynamic IP addressing, the WME shall > > calculate the global IPv6 address 18 via a stateless configuration > > procedure. This is the procedure described in RFC 3513, > > For more precision, instead of the Proposed Standard RFC3513 "IPv6 > Addressing Architecture" one would rather mention the Draft Standard > RFC4291 of same title. At IETF a Draft Standard status witnesses wider > adoption than Proposed Standard status. > > Moreover, if the intent of the text is to refer to the procedure of > stateless address autoconfiguration then the more precise reference would > rather be RFC4862 "Stateless Address Autoconfiguration". > > In addition, there is another tool for dynamic IP addressing: DHCPv6 in > RFC3315. > > > except the WAVE device uses its MAC address in conjunction with the > > IpPrefix received in the WaveRoutingAdvertisement of a WAVE Service > > Advertisement, rather than that received in an RFC 4861 Router > > Advertisement message. > > This may be an unncessarily new way to do same functionality. The use of RA > is widely implemented and it should be preferred over the use of link-layer > specific mechanisms to realize address autoconfiguration. > > In the past we have seen in the cellular space a similar mechanism to > configure IPv6 addresses with RANAP protocol. At IEEE also we seem to be > seing the same thing in 802.11ai for Fast Initial Link Setup. These > alternative ways to configure IP addresses are obviously incompatible and > may need to converge. > > > WAVE provides this IP configuration information in the WAVE Service > > Advertisement to minimize the need for neighbor and router discovery > > with their associated overhead and latency. > > The ND and router discovery may function quite fast. > > > Note that IP transmissions are prohibited on the control channel. > > It may be that IP transmissions are not prohibited on the control channel. > Some of the 'road safety' and 'traffic efficiency applications' of ETSI ITS > may not be prohibited from using IP, hence transmitted on the control > channel. > > Alex > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From alison@she-devel.com Sat Jun 22 20:56:14 2013 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 DC31521F9D81 for ; Sat, 22 Jun 2013 20:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDA1fPpJMz0m for ; Sat, 22 Jun 2013 20:56:13 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE8B21F9D7C for ; Sat, 22 Jun 2013 20:56:13 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so21422259ieb.24 for ; Sat, 22 Jun 2013 20:56:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=iSfr2iZyr3146GGAto6gZuBeUpNk+1AM37L4Jn2HonA=; b=ZvTGLIGZ+dFaEQx9GteX8f9DxPOwjL0eTZA+NaDmkDXVkqY/wFXZOrDa3Xqx0yWEXz qUCwn7vg56MCL2RfdMqPwAljbRJ+P8EwJc8i3lhqySl7P3g0NceGIFsbuSeMZ+D427dw J4WsCCX7bZAJgdHjKrdwSMyqhDQsKp81evTRKXSpBlSpsSknFX/BkalkLfmyfpn33wtx Hjt/ed+hhLKK1u5xySAksUedHzO4N3ih+/Nsjmvmai9IH3yqCH6NYM8CumVvizkwwTtf 6XGoZwGU6htP2gwdUn8IjJ9R0uPMOj3dvqIaOotD/NybdK4NiTbSFaGhgAbQLPZfUhb+ C9mA== MIME-Version: 1.0 X-Received: by 10.42.237.204 with SMTP id kp12mr9189944icb.18.1371959772608; Sat, 22 Jun 2013 20:56:12 -0700 (PDT) Received: by 10.42.25.70 with HTTP; Sat, 22 Jun 2013 20:56:12 -0700 (PDT) Date: Sat, 22 Jun 2013 20:56:12 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: multipart/alternative; boundary=047d7b6daa10e48ef604dfca46d3 X-Gm-Message-State: ALoCoQlDFhf7z+/VTvwRlPu/7L1WL9ia6ibONvd8MTWYFxQvkd0doqHjlBeWKW4vGRFOChpw8P0y Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 03:56:15 -0000 --047d7b6daa10e48ef604dfca46d3 Content-Type: text/plain; charset=ISO-8859-1 Rex explains: > John, I've spent the past decade observing the internet-ready standards > work for extending the internet to mobile platforms (e.g. IEEE 802.16) > and the past three years or so specifically looking at emergency > services -- fire, ambulance, police -- and their communications needs. > > But none of the NPSTC (National Public Safety Telecom Council) sources > (to pick just one example) seem to have any reference to IEEE 1609. Rex and all assembled, I'm intrigued in this context by the following text about IEEE-1609.2 security that I quote from John Kenney's paper: The certificate carries a list of PSIDs that the sender is authorized to use in its WSM transmissions. For example,a vehicle will have certificates authorizing it to send a WSM with the PSID that is associated with the Basic Safety Message. The certificate may also indicate content-specific permissions that the sender has. For example, an SAE J2735 emergency vehicle alert message (EVAM) might be sent by a number of emergency vehicle types, including police cars, ambulances, and tow trucks. A siren indication within the EVAM is permissible for an ambulance or police car, but not for a tow truck. Clearly a "siren indication" is an area where emergency vehicles, whatever method they use to call back to base, may want communicate to passenger vehicles, as well. The superiority of a longer-range siren signal is obvious: the further back down the road that vehicles know of impending danger, the better for safety systems (within limits, of course). An emergency vehicle could, of course, use LTE to communicate to a RSU that rebroadcasts 802.11p, but we can all guess how long it might be before such infrastructure might be widely deployed. > It appears that extending the internet to mobile platforms is a > thought-piece that has lots of independent players in their own silos. Indeed, but the history of emergency responder communications does not make us hopeful, either. I'm curious what readers from Europe or Asia have to say here. Is there a comparable reference to John K.'s "Dedicated Short-Range Communications (DSRC) Standards in the United States" that discusses the status of European and Asian plans? Is there a single ETSI document, for example, that someone like me who is just spectating could purchase and read? -- Alison, whose day job is writing Linux device drivers for automotive electronics -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou --047d7b6daa10e48ef604dfca46d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rex explains:
> John, =A0I've spent the past decade observing the= internet-ready standards
> work for extending the internet to mobile= platforms (e.g. IEEE 802.16)
> and the past three years or so specif= ically looking at emergency
> services -- fire, ambulance, police -- and their communications needs.=
>
> But none of the NPSTC (National Public Safety Telecom Coun= cil) sources
> (to pick just one example) seem to have any reference = to IEEE 1609.

Rex and all assembled, I'm intrigued in this context by the followi= ng text about IEEE-1609.2 security that I quote from John Kenney's pape= r:

The certificate carries a list of= PSIDs that the sender is authorized to use in its WSM transmissions. For e= xample,a vehicle will have certificates authorizing it to send a WSM with t= he PSID that is associated with the Basic Safety Message. The certificate m= ay also indicate content-specific permissions that the sender has. For exam= ple, an SAE J2735 emergency vehicle alert message (EVAM) might be sent by a= number of emergency vehicle types, including police cars, ambulances, and = tow trucks. =A0 A siren indication within the EVAM is permissible for an am= bulance or police car, but not for a tow truck.

Clearly a "siren indication" is an area where emergency= vehicles, whatever method they use to call back to base, may want communic= ate to passenger vehicles, as well.=A0=A0=A0 The superiority of a longer-ra= nge siren signal is obvious: the further back down the road that vehicles k= now of impending danger, the better for safety systems (within limits, of c= ourse).=A0=A0=A0=A0=A0 An emergency vehicle could, of course, use LTE to co= mmunicate to a RSU that rebroadcasts 802.11p, but we can all guess how long= it might be before such infrastructure might be widely deployed.

> It appears that extending the internet to mobile platforms is a> thought-piece that has lots of independent players in their own silos= .

Indeed, but the history of emergency responder communications does= not make us hopeful, either.

I'm curious what readers from Europe or Asia have to say here.=A0= =A0=A0 Is there a comparable reference to John K.'s
"Dedicated= Short-Range Communications (DSRC) Standards in the United States" tha= t discusses the status of European and Asian plans?=A0=A0=A0 Is there a sin= gle ETSI document, for example, that someone like me who is just spectating= could purchase and read?

-- Alison, whose day job is writing Linux device drivers for automotive= electronics

--
Alison Chaiken =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 alison@she-deve= l.com
650-279-5600 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0http://{she-devel.com, exerciseforthereader.org}
The intermediary between the head and the hands must be the heart. =A0 =A0-= - Thea von Harbou
--047d7b6daa10e48ef604dfca46d3-- From buddenbergr@gmail.com Sun Jun 23 15:07:51 2013 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 2B1E421F9E4A for ; Sun, 23 Jun 2013 15:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg82z6h-8Aur for ; Sun, 23 Jun 2013 15:07:50 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 313BB21F9D9F for ; Sun, 23 Jun 2013 15:07:50 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so10103243pbb.34 for ; Sun, 23 Jun 2013 15:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=8XQJfxwzZi8do75B1zUATEndnpU7d7TBISt1yl7rnJk=; b=xgdUV2zBCgnrNNNFJrIcMiUWmsiTAPOBx76Mz3FFgX65NckNZ9qjpO72bLfSBqMTS9 eVX71T2HHN+jLrP8fjivYoPsNXO2PrlTKPrjF75sVRDwpUsDqHyqHoKJVJgoh/R2odfo YbTXHy9dUEEgWN0EiIoI7Np2d8IgEHD+5a1K62FvlDAbDUavyBlpbCDZhYrEmtuR/bkd +ntP/P/8HuZUJSsVof6658R6zGDQz5pvWiuuqw7LI6AJWoSyKEWEPh80hH4cqkDE/Zyf rxhX2pDM3Fa6GIp9u+I9R5bk+vYOLaEWJSbcBmUmHU+vJtiN19ec0dVFlz2pTunAqyJy aD1Q== X-Received: by 10.66.27.147 with SMTP id t19mr24825841pag.171.1372025269867; Sun, 23 Jun 2013 15:07:49 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id ue9sm6540773pab.7.2013.06.23.15.07.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 23 Jun 2013 15:07:49 -0700 (PDT) Message-ID: <1372025267.7392.41.camel@localhost> From: Rex Buddenberg To: Alison Chaiken Date: Sun, 23 Jun 2013 15:07:47 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 22:07:51 -0000 The quote has things basically right: On Sat, 2013-06-22 at 20:56 -0700, Alison Chaiken wrote: > Rex explains: > > John, I've spent the past decade observing the internet-ready > standards > > work for extending the internet to mobile platforms (e.g. IEEE > 802.16) > > and the past three years or so specifically looking at emergency > > services -- fire, ambulance, police -- and their communications > needs. > > > > But none of the NPSTC (National Public Safety Telecom Council) > sources > > (to pick just one example) seem to have any reference to IEEE 1609. > > Rex and all assembled, I'm intrigued in this context by the following > text about IEEE-1609.2 security that I quote from John Kenney's paper: > > The certificate carries a list of PSIDs that the sender is authorized > to use in its WSM transmissions. The important thing to note here is that it is the data that is being protected. Analogous to signing an e-mail message. Entirely independent of the lower layer protocols and technologies. > For example,a vehicle will have certificates authorizing it to send a > WSM with the PSID that is associated with the Basic Safety Message. > The certificate may also indicate content-specific permissions that > the sender has. For example, an SAE J2735 emergency vehicle alert > message (EVAM) might be sent by a number of emergency vehicle types, > including police cars, ambulances, and tow trucks. A siren > indication within the EVAM is permissible for an ambulance or police > car, but not for a tow truck. > > > Clearly a "siren indication" is an area where emergency vehicles, > whatever method they use to call back to base, may want communicate to > passenger vehicles, as well. Unless I'm misreading something, the private key is associated with the siren _sender_. Anyone can receive the message. Further, anyone could relay the message because the message itself is not changed. And anyone could validate the signature because the public key is, er, public. A passenger car may want to communicate with the ambulance but sending it a siren message would not be appropriate. Use a different keypair. > The superiority of a longer-range siren signal is obvious: the > further back down the road that vehicles know of impending danger, the > better for safety systems (within limits, of course). The WSM messages appear to share the characteristic with Common Alerting Protocol messages: they contain a geo reference and some sort of polygon (commonly an ellipse). I'm not familiar with the WSM data schema but Common Alerting Protocol is based on XML so you can inherently use the sign and crypt primitives. Same/similar?? > An emergency vehicle could, of course, use LTE to communicate to a > RSU that rebroadcasts 802.11p, but we can all guess how long it might > be before such infrastructure might be widely deployed. To the messages, be they WSM, CAP or any of dozens of other formats, they don't care -- routable networks are routable networks. (BTW, what this IEEE committee calls RSU is known as a BS -- base station -- by IEEE 802. TIA, of course, couldn't accept that so they call it CPE. > > > It appears that extending the internet to mobile platforms is a > > thought-piece that has lots of independent players in their own > silos. > > Indeed, but the history of emergency responder communications does not > make us hopeful, either. > > I'm curious what readers from Europe or Asia have to say here. Is > there a comparable reference to John K.'s > "Dedicated Short-Range Communications (DSRC) Standards in the United > States" that discusses the status of European and Asian plans? Is > there a single ETSI document, for example, that someone like me who is > just spectating could purchase and read? > > -- Alison, whose day job is writing Linux device drivers for > automotive electronics > > -- > Alison Chaiken alison@she-devel.com > 650-279-5600 http://{she-devel.com, > exerciseforthereader.org} > The intermediary between the head and the hands must be the heart. > -- Thea von Harbou > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From mcr@sandelman.ca Sun Jun 23 17:09:10 2013 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 44F5021F9FC8 for ; Sun, 23 Jun 2013 17:09:10 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WFpIHncxzjb for ; Sun, 23 Jun 2013 17:09:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id B8C3F21F9FCB for ; Sun, 23 Jun 2013 17:09:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 425342026E for ; Sun, 23 Jun 2013 21:13:06 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F253F63A7C; Sun, 23 Jun 2013 20:08:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E2F8F63732 for ; Sun, 23 Jun 2013 20:08:05 -0400 (EDT) From: Michael Richardson To: its@ietf.org In-Reply-To: <51C4AC5B.3060404@gmail.com> References: <51C4AC5B.3060404@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 00:09:10 -0000 --=-=-= Alexandru Petrescu wrote: > The IESG has not approved the request for BoF ITS in Berlin. Please realize that there were like 16 BOF requests for the Berlin meeting. Not only is there a lack of non-conflicting time slots, but only so many WG can be spun upon in a given amount of time. So some of the reason is not specific to ITS, but I think that ITS was not as clear as it needs to be as to it's charter. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUceN4oqHRg3pndX9AQLsZQP7BIUEIAA31s0edbd0uETQNBrHMvwHV7/O yrl8OE0N3UoHBrfUHeeYRjlwGcjnWynYEH7D0VUuEQ9fVLNdcVf6NZ2iGfZqGsGy 24GmQareH68Kxxb0/utSx8ZdG2u7Jx4Um4inhVj4h5nHfTouXdsWKymGD2EpUmlF asZxAp3Tfno= =zV+Y -----END PGP SIGNATURE----- --=-=-=-- From alison@she-devel.com Sun Jun 23 18:53:24 2013 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 B0AB621F9ED0 for ; Sun, 23 Jun 2013 18:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yXCuBjF2NVS for ; Sun, 23 Jun 2013 18:53:23 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id CFD1821F9EBE for ; Sun, 23 Jun 2013 18:53:23 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so23438409iec.22 for ; Sun, 23 Jun 2013 18:53:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=tYQrXfZ7VB/a8unbTD2MxCX547NgCNCtoeaOdFVuf84=; b=CC8NB92rsjkhur12ovBdWt7z7lDHCCYqLddvUacALONlQnXyYlsQkNX9QsFy+Gi2rf qygsdeR7eKzmezp3AL9PWgvl4SB/vKb5sXjkyqk9HNeCNVd8ekMR4B0YJQA5rmDNAUKV wTtHTJfg6qq2MuAlHKxgyB2mDZ4OWV4KpJU/n/qosiERbBGCLcikhsktZGBtrVjPmH6R 6nZTHyqj06/bXO7upASjzCA4M0rHmHWfRraigCBxA8LHaescD2Vo9DV/RkCG8SlJ3K3z oVsB/Suioz02opJLac9cnLK+gLmaY4u6WQqpQu+fNr5dwd/mwjpeUpi5bbhhyqvDzW5R aqcQ== MIME-Version: 1.0 X-Received: by 10.42.92.78 with SMTP id s14mr10389689icm.40.1372038802236; Sun, 23 Jun 2013 18:53:22 -0700 (PDT) Received: by 10.42.25.70 with HTTP; Sun, 23 Jun 2013 18:53:22 -0700 (PDT) In-Reply-To: <1372025267.7392.41.camel@localhost> References: <1372025267.7392.41.camel@localhost> Date: Sun, 23 Jun 2013 18:53:22 -0700 Message-ID: From: Alison Chaiken To: Rex Buddenberg Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl9I2lsNrVSSXBLN+krc3Ek5b+yVo7/mXlgLqDmnLNUGILsXVfuyIHgTaS7LYpdYiJKs1/X Cc: its@ietf.org Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 01:53:24 -0000 I write: >> Clearly a "siren indication" is an area where emergency vehicles, >> whatever method they use to call back to base, may want communicate to >> passenger vehicles, as well. Rex answers: > Unless I'm misreading something, the private key is associated with the > siren _sender_. Anyone can receive the message. Further, anyone could > relay the message because the message itself is not changed. And anyone > could validate the signature because the public key is, er, public. Sorry, I failed to ask my question, which is: If passenger vehicles expect WSM on 802.11p, don't emergency vehicles then neeed 802.11p to communicate with them, irrespective of LTE plans for emergency vehicles? Assuredly in the Grand Connected Future we don't expect that emergency vehicles will communicate with individual drivers via audible alarms and flashing lights only? And assuredly having emergency vehicles call out siren messages over LTE to infrastructure which sends 802.11p would be ridiculous? Adding 802.11p to emergency vehicles will be expensive, but much less so than adding LTE to all cars. Even if cars have LTE for (gag) "infotainment," we can hardly rely on that channel to convey siren information as well. -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou From buddenbergr@gmail.com Sun Jun 23 19:52:31 2013 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 2405C11E8109 for ; Sun, 23 Jun 2013 19:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCewbKZbWFej for ; Sun, 23 Jun 2013 19:52:30 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4E09311E8103 for ; Sun, 23 Jun 2013 19:52:30 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so10277960pad.5 for ; Sun, 23 Jun 2013 19:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=ztIWnFX6D3p+/lGwKcXox9x7jLJv2gcS+TO6sRmqJyo=; b=B/xoCsnUKgwjC2QqquLcH0WkCrr9xkyDdn1XDggbS559duS9PFZg6fN3eJ+ax5L5Wg FYCeuv6EQDQekMJAKz/NAXw7CFx+iaXTe1spckcNbMAv7LQj0iQUOIqN16uIRY59En0g flnwiDNA7tlIIqdRhUz5PwD72IcQY1GdGCUMJgTocIwH1AoW3/vHBwkoMUKGP7ubq3ze UYeBTUXUxTyjO+J3CvT1JO0sw1Wy4dJH+EEBdynGJ35QAV2wVThPbddaWbpfEqYCYLxN XuGpLkvL76rAoGGtC3ID2OLgxUHeAwq98bE5tuizY/97ol2kWMO1bMFLhLNOilkP+QtO 9IYA== X-Received: by 10.66.185.14 with SMTP id ey14mr25918144pac.23.1372042349095; Sun, 23 Jun 2013 19:52:29 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id mr3sm124235pbb.27.2013.06.23.19.52.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 23 Jun 2013 19:52:28 -0700 (PDT) Message-ID: <1372042346.7392.89.camel@localhost> From: Rex Buddenberg To: Alison Chaiken Date: Sun, 23 Jun 2013 19:52:26 -0700 In-Reply-To: References: <1372025267.7392.41.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 02:52:31 -0000 disentangling... On Sun, 2013-06-23 at 18:53 -0700, Alison Chaiken wrote: > I write: > >> Clearly a "siren indication" is an area where emergency vehicles, > >> whatever method they use to call back to base, may want communicate to > >> passenger vehicles, as well. > > Rex answers: > > Unless I'm misreading something, the private key is associated with the > > siren _sender_. Anyone can receive the message. Further, anyone could > > relay the message because the message itself is not changed. And anyone > > could validate the signature because the public key is, er, public. > Ahh. The above was about data, and definitely not about infrastructure. And I think WSM is indeed about data too. > Sorry, I failed to ask my question, which is: ok, this is a collision -- two silos. Shifting gears: > > If passenger vehicles expect WSM on 802.11p, don't emergency vehicles > then neeed 802.11p to communicate with them, irrespective of LTE plans > for emergency vehicles? The cellphone companies are rolling out LTE infrastructure and it's going in along the highways. (It's being advertised to you as 4g). Who is rolling out 802.11? > Assuredly in the Grand Connected Future we > don't expect that emergency vehicles will communicate with individual > drivers via audible alarms and flashing lights only? The first observation is that both 802.11 and 802.16 (which LTE is a clone of) are routable networks. So if there is dual radio-WAN infrastructures, they will be interoperable. That's the good news. Indeed there's no reason a vehicle's router could not be interfaced to each simultaneously. > And assuredly > having emergency vehicles call out siren messages over LTE to > infrastructure which sends 802.11p would be ridiculous? Adding > 802.11p to emergency vehicles will be expensive, but much less so than > adding LTE to all cars. Even if cars have LTE for (gag) > "infotainment," we can hardly rely on that channel to convey siren > information as well. Strip off the uses for the moment; quick handwaving technical. LTE and 802.11 are: - both routable networks. - more or less RF equivalent: both use OFDM. Note that 1609 has what appears to be yet another layer 1/2 protocol (John Moring???)? The RF range and power figures you can expect are little different than non-protocol range figures that several modeling tools will show. - all use ethernet framing within and pass the ethernet contents up through the layer 2/3 interface, so the integration problems are familiar. Routers know what to do with ethernet frames ... or rather the contents thereof. The difference between the two protocols is in the MAC: - all 802.11 protocols use CSMA of some flavor, derived from 802.3 ethernet. This is a contention-access protocol, albeit with some ifs/ands/buts attached. Contention protocols are comparatively easy to implement but they have three defects in the radio-WAN environment that tend not to show up in the wireless LAN one: o contention protocols are unstable under overload. Too many users, too much to say, the network segment stalls. o the stall point occurs at depressingly low bandwidth efficiency levels. Like around 20% of baseband capacity (depending again on a slew of ifs/ands/buts). o there's no way to manage your way out of this overload situation. There is exactly one MAC message in WiFi: the so-called busy tone that tells would-be SS to wait until someone else is finished (in the labeling, this is the diff between CSMA/CD and CSMA/CA, but it's still CSMA). - 802.16 and LTE have a contention-free protocol borrowed from DOCSIS (!!). It's a TDMA or time-slice arrangement where the base station (BS, what 1609 calls the roadside unit) assigns each user a time slot where only that subscriber station transmits. It's harder to implement (but the problem is solved -- chipsets are readily available) but is o stable under overload o highly bandwidth efficient o can be positively managed. Business. At least in US, the cellphone companies are deploying LTE (Clearwire has ceased expanding its 802.16 deployment because the market herd all started braying LTE). There's a bunch of marketing namecalling, but for all practical purposes '4G' = LTE = 802.16. I've never heard any cellphone company or any DIY emergency service outfit so much as mention 802.11 of any flavor. (The emergency services folks think that they are going to have a separate 800MHz LTE infrastructure. Their reasoning is that they need 'assured access' (which I agree with) and therefore they need a separate freq band (which I do not). This is their conventional wisdom right now; it hasn't met economic reality yet). I agree with your observation, Alison, that two infrastructures is on the ridiculous side. Better to have one and invest in Ao to make it work when the chips are down. None of this has any impact _inside_ the vehicle -- it's only the interface on the radio-WAN side of the router that cares. And there's no reason that the router can't have both interfaces. > > -- > Alison Chaiken alison@she-devel.com > 650-279-5600 http://{she-devel.com, > exerciseforthereader.org} > The intermediary between the head and the hands must be the heart. > -- Thea von Harbou From Andreas.Festag@neclab.eu Mon Jun 24 01:17:24 2013 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 786E021F9C61 for ; Mon, 24 Jun 2013 01:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB+HW9HUxdu2 for ; Mon, 24 Jun 2013 01:17:15 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 34D7921F84AF for ; Mon, 24 Jun 2013 01:17:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4409B104622 for ; Mon, 24 Jun 2013 10:16:49 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX0qYB1cyCta for ; Mon, 24 Jun 2013 10:16:49 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 288DA104558 for ; Mon, 24 Jun 2013 10:16:44 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.234]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 24 Jun 2013 10:15:35 +0200 From: Andreas Festag To: "its@ietf.org" Thread-Topic: [its] Pending request of BoF slot for ITS of IETF in Berlin, decision by June 20, 27 Thread-Index: AQHOX7ssvVga2tl2okSUohRKtQkYvpk8itfQ Date: Mon, 24 Jun 2013 08:15:34 +0000 Message-ID: <21E46EE9B979354990401539FD0A63E515AF40@DAPHNIS.office.hd> References: <51AB8843.1010206@gmail.com> In-Reply-To: <51AB8843.1010206@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [its] Pending request of BoF slot for ITS of IETF in Berlin, decision by June 20, 27 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 08:17:24 -0000 Dear Alexandru, dear all, I intended to write this email already last week but then I got the info th= at the BoF was not accepted, so I changed to scope of the email slightly. T= o cut a long story short, during last week's meeting of the ETSI technical = committee ITS, WG3 (Networking and Transport) has discussed this IETF BoF o= n ITS with some conclusions below. In recent posts in this email list I got the impression there is some confu= sion about the European activities, therefore let me give some background:= =20 As you may know, ETSI has developed a protocol stack specification for ad h= oc communication among vehicles and between vehicles and roadside infrastru= cture primarily for safety and traffic efficiency. The stack covers ITS-G5,= a European variant of IEEE 802.11p operating in the 5 GHz band allocated f= or safety and traffic efficiency. Further, the stack has an ad hoc networki= ng protocol (GeoNetworking), messaging protocols for periodic safety messag= es (aka CAM) and event-driven messages (aka DENM) as well as support for se= curity and anonymity. In particular, the networking protocol supports geogr= aphical addressing and routing (geo-unicast, geo-broadcast, etc.) in the ad= hoc network domain. This protocol, termed GeoNetworking, is combined with = a UDP-like transport protocol called BTP. In order to link ad hoc networkin= g to the IP world, a standard for the transmission of IPv6 over GeoNetworki= ng has been developed. The development of the standards for the overall sys= tem as well as test specifications, conformance testing & plugtests was sup= ported by an EC mandate and the Car-2-Car Communication Consortium (C2C-CC)= , and resulted in a release 1 of ETSI TC ITS standards. The standards have = been trialed in several field operational tests in Europe, such as the Euro= pean DRIVE C2X but also in national activities, such as simTD and SCOREF in= Germany and France, respectively. Deployment of release 1 in Europe is exp= ected around 2015/16. The standardization activities in ETSI TC ITS so far have focused on use ca= ses for safety and traffic efficiency, with rather limited efforts for IP-r= elated use cases. In fact, networking in the ad hoc domain, i.e. not over i= nfrastructure, is well covered by ETSI GeoNetworking, which is not based o= n IP, but can be regarded as a sub-IP ad hoc networking protocol. However, = to my best knowledge the "IPv6-based network-layer distribution of content = in a geographic area" has not been considered so far in standardization tho= ugh for the dissemination via cellular networks (e.g. LTE) ETSI TC ITS has = started some initial activities. Further, IP mobility solutions (Mobile IP,= NEMO) can well be applied for cooperative ITS, but direct communication, e= .g. vehicle-to-vehicle communication, has some addressing issues and standa= rds for route optimization would be needed for effective functioning. Final= ly, ETSI TC ITS has recently started to standardize multimedia content dist= ribution for Car-2-x communication, where I would expect IPv6 to play a big= ger role than for safety applications. In summary, an IETF group dedicated to ITS would be welcome to address IP-s= pecific protocol aspects for cooperative ITS. I hope the IETF efforts will = take into account the existing solutions in ETSI TC ITS (and elsewehere). K= ey to succeed with a BOF proposal is to have ITS stakeholders in. Kind regards, Andreas Festag ETSI TC ITS WG3 chairman =20 -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: Sunday, June 02, 2013 8:01 PM To: its@ietf.org Subject: [its] Pending request of BoF slot for ITS of IETF in Berlin, decis= ion by June 20, 27 ITSers, I wanted to let you know that I have sent a request for scheduling a BoF se= ssion for ITS of IETF in Berlin. We will get a response by June 20 or June= 27th. I guess the decision for Berlin depends largely on the content and activity= of the email list, how far are we with Charter, how much interest there re= ally is, other independent signals. The membership of the list counts approximately 200 email addresses. Alex _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From mcr@sandelman.ca Mon Jun 24 06:08:45 2013 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 A00DA21F8E77 for ; Mon, 24 Jun 2013 06:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJnRNR6lc1b5 for ; Mon, 24 Jun 2013 06:08:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 2552511E812F for ; Mon, 24 Jun 2013 06:08:41 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 230332024B; Mon, 24 Jun 2013 10:12:39 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0062163A7C; Mon, 24 Jun 2013 09:07:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DBCD263A5E; Mon, 24 Jun 2013 09:07:36 -0400 (EDT) From: Michael Richardson To: Alison Chaiken In-Reply-To: References: <1372025267.7392.41.camel@localhost> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Rex Buddenberg , its@ietf.org Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 13:08:45 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Alison Chaiken wrote: alison> If passenger vehicles expect WSM on 802.11p, don't emergency alison>vehicles then need 802.11p to communicate with them, irrespective alison>of LTE plans for emergency vehicles? Assuredly in the Grand alison>Connected Future we don't expect that emergency vehicles will alison>communicate with individual drivers via audible alarms and alison>flashing lights only? And assuredly having emergency vehicles alison>call out siren messages over LTE to infrastructure which sends alison>802.11p would be ridiculous? I don't know that it would be ridiculous to assume this. I agree that the latency might suck. I presume, however two things: 1) the route the *ambulance* or *fire* truck might take is well known in advance to the traffic control system ("in advance" is a relative term, in this I'm saying that 5s >> 0.1s maximum latency). So it need not be the vehicle *itself* that is calling out it's route, the vehicle may well be following the route that the traffic control system has established. 2) my observation is that flashing lights and sirens have two undesireable affects. On overly consentious drivers (my mom-in-law, former er nurse), they yank the wheel, to get out the way, often so fast they nearly cause a collision themselves, even when the vehicle won't even be coming near them. On drivers who day-dream (my mom! "oh, was there a stop sign back there?") they don't notice a thing until the vehicle is stuck behind them. It would be very useful to both of them to be told that the vehicle is coming, and that it will in fact affect them. --=-=-= Content-Disposition: inline Content-Description: Signature -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUchElIqHRg3pndX9AQIzSAQA3YNS2HQGuqhOmEjZW72sSdlsuX+B5N63 cUTr3AwQUGbtbD5/XL7IAKvJwe/fWmR1f1gSS1K7Jud7UHWxwV1PsCttVoHWwmPp nyf4R68Xcjb6euqbLIutSa1rM4sT4PLLt9gibcQFV0JWjjKoIdZP4E2C16ELBNHf +gzplmYO4Go= =3L3+ -----END PGP SIGNATURE----- --==-=-=-- From jkenney@us.toyota-itc.com Mon Jun 24 08:29:23 2013 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 CF3BE11E814D for ; Mon, 24 Jun 2013 08:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8kCQjqBb5TN for ; Mon, 24 Jun 2013 08:29:19 -0700 (PDT) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with SMTP id 44C4D11E813A for ; Mon, 24 Jun 2013 08:29:18 -0700 (PDT) Received: from mail-pb0-f41.google.com ([209.85.160.41]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUchlzZYtj0Ks4lM6mY8nhNrSzzxg+tGw@postini.com; Mon, 24 Jun 2013 08:29:19 PDT Received: by mail-pb0-f41.google.com with SMTP id rp16so11167586pbb.14 for ; Mon, 24 Jun 2013 08:29:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=kVr1vg+6hldA0em6xr3Mkv0PssiEQXkTjUZaRBMq2F4=; b=QKrcXdMshcKk/ZXkw4vE85mVVnBOs/u4GEJHE/uq69mPecRzpztnNCX0yOIfbHft5V rwBWIF0nuEMBh5PnhOO2+cR7KvuKoOYPYsg4qwT69nfra8XK2AX4hqFbkKk0qAyb++yx A5w/hQYLy+OdXTXNItJkQrn5t4pAkNlGp/hDjOSzfzUA8vmALcd3TEnayh9MFPcpvm7v B7Zb//Gd5lbXYfDJD3asDzFk5817/IeZFDKuVTp6mpp8PuGzwi9/mOdh6+hIqDz3gMg2 EwzfEhhqOmw4QtSj+jzIFQRwiaIVrNBZaRokiaeWXu4Fn8HRvujM3KYjDb2obltO9AsX /Aag== X-Received: by 10.68.243.40 with SMTP id wv8mr24284645pbc.34.1372087756840; Mon, 24 Jun 2013 08:29:16 -0700 (PDT) X-Received: by 10.68.243.40 with SMTP id wv8mr24284634pbc.34.1372087756653; Mon, 24 Jun 2013 08:29:16 -0700 (PDT) References: <1372025267.7392.41.camel@localhost> From: John Kenney Mime-Version: 1.0 (1.0) In-Reply-To: <1372025267.7392.41.camel@localhost> Date: Mon, 24 Jun 2013 08:29:11 -0700 Message-ID: <-3255255052080503291@unknownmsgid> To: Rex Buddenberg Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlUFRcDNvFsBH32NepMVz6/FD6ue0Usdp0r2I1JCXXqohCgPJLoUi2NHkyME45IGGhy+iBz5jdqUtsndvM9tnFc9O7VTEUdZIvQ60siCgEP/ptkNtI/oWlvw6z+/jy6f0B7KO1Y Cc: Alison Chaiken , "its@ietf.org" Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:29:23 -0000 1609.2 Security Services can be thought of as operating just above WSMP, so the signed message becomes the payload ("WSM Data") of the WSM packet. This is subtly different than my 2011 description. It is also correct that in the siren example the sender is indicating that it had the authority to set a "siren in use" data field in a higher layer message. An ambulance would have that authority. A tow truck would not. The message would be accompanied by a certificate containing the sender's public key, the PSID(s) the sender is authorized to include in a WSM (presumably including the PSID value associated with this EVAM), and possibly an SSP for each PSID. Anyone can hear the message. I'm not sure about the base station comment. From an 802.11 perspective there is no difference between an RSU and an OBU. There are differences in FCC regulations. Best Regards, John Sent from my iPhone On Jun 23, 2013, at 3:07 PM, Rex Buddenberg wrote: > The quote has things basically right: > > On Sat, 2013-06-22 at 20:56 -0700, Alison Chaiken wrote: >> Rex explains: >>> John, I've spent the past decade observing the internet-ready >> standards >>> work for extending the internet to mobile platforms (e.g. IEEE >> 802.16) >>> and the past three years or so specifically looking at emergency >>> services -- fire, ambulance, police -- and their communications >> needs. >>> >>> But none of the NPSTC (National Public Safety Telecom Council) >> sources >>> (to pick just one example) seem to have any reference to IEEE 1609. >> >> Rex and all assembled, I'm intrigued in this context by the following >> text about IEEE-1609.2 security that I quote from John Kenney's paper: >> >> The certificate carries a list of PSIDs that the sender is authorized >> to use in its WSM transmissions. > > The important thing to note here is that it is the data that is being > protected. Analogous to signing an e-mail message. Entirely > independent of the lower layer protocols and technologies. > >> For example,a vehicle will have certificates authorizing it to send a >> WSM with the PSID that is associated with the Basic Safety Message. >> The certificate may also indicate content-specific permissions that >> the sender has. For example, an SAE J2735 emergency vehicle alert >> message (EVAM) might be sent by a number of emergency vehicle types, >> including police cars, ambulances, and tow trucks. A siren >> indication within the EVAM is permissible for an ambulance or police >> car, but not for a tow truck. >> >> >> Clearly a "siren indication" is an area where emergency vehicles, >> whatever method they use to call back to base, may want communicate to >> passenger vehicles, as well. > > Unless I'm misreading something, the private key is associated with the > siren _sender_. Anyone can receive the message. Further, anyone could > relay the message because the message itself is not changed. And anyone > could validate the signature because the public key is, er, public. > > A passenger car may want to communicate with the ambulance but sending > it a siren message would not be appropriate. Use a different keypair. > >> The superiority of a longer-range siren signal is obvious: the >> further back down the road that vehicles know of impending danger, the >> better for safety systems (within limits, of course). > > The WSM messages appear to share the characteristic with Common Alerting > Protocol messages: they contain a geo reference and some sort of polygon > (commonly an ellipse). > > I'm not familiar with the WSM data schema but Common Alerting Protocol > is based on XML so you can inherently use the sign and crypt primitives. > Same/similar?? > >> An emergency vehicle could, of course, use LTE to communicate to a >> RSU that rebroadcasts 802.11p, but we can all guess how long it might >> be before such infrastructure might be widely deployed. > > To the messages, be they WSM, CAP or any of dozens of other formats, > they don't care -- routable networks are routable networks. (BTW, what > this IEEE committee calls RSU is known as a BS -- base station -- by > IEEE 802. TIA, of course, couldn't accept that so they call it CPE. >> >>> It appears that extending the internet to mobile platforms is a >>> thought-piece that has lots of independent players in their own >> silos. >> >> Indeed, but the history of emergency responder communications does not >> make us hopeful, either. >> >> I'm curious what readers from Europe or Asia have to say here. Is >> there a comparable reference to John K.'s >> "Dedicated Short-Range Communications (DSRC) Standards in the United >> States" that discusses the status of European and Asian plans? Is >> there a single ETSI document, for example, that someone like me who is >> just spectating could purchase and read? >> >> -- Alison, whose day job is writing Linux device drivers for >> automotive electronics >> >> -- >> Alison Chaiken alison@she-devel.com >> 650-279-5600 http://{she-devel.com, >> exerciseforthereader.org} >> The intermediary between the head and the hands must be the heart. >> -- Thea von Harbou >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From jkenney@us.toyota-itc.com Mon Jun 24 08:58:57 2013 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 52C8021E8104 for ; Mon, 24 Jun 2013 08:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78c0zWJ3nFpm for ; Mon, 24 Jun 2013 08:58:52 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with SMTP id 9D52C11E8150 for ; Mon, 24 Jun 2013 08:58:52 -0700 (PDT) Received: from mail-pb0-f43.google.com ([209.85.160.43]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUchsvKpy30bQQHlOwDvjbgfZEi0gpvfF@postini.com; Mon, 24 Jun 2013 08:58:52 PDT Received: by mail-pb0-f43.google.com with SMTP id md12so11283263pbc.16 for ; Mon, 24 Jun 2013 08:58:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Z0JyAoYegHR5wlSL2dm1MJQMKyiQDH9DekKH27rQC34=; b=ej3zi6AMVH2Zpr6edG7X+xcl+2dpKES9cXKnXy6e/RYauDpR1OzGPnBHgoiwFJXVJx 4IaB6Ml6Hj3LINrJJFXjMeoGHXAeB0yG2ML2TqeVhy9C+gADahXDdGkUVJY71rJLl14x wH4j/2tZpmBHRGxz6ftrF7PkxoE4QG6ljTt8QRleh79UsWlz8YYE0Xn/vMLv8E1zIfNp pO7SIcKsG74QtPGFuPntUqhu1zGoM2ne2BmH9CJ+NeVseKhKBwBV8/o+0Ip7EbtCrGDD snfS2xvVc3V5QvfrVWZbmtzjB5lBQR/tR643LLUSPXfY88RrsNaYly1tNwS1mMRrILd3 csTw== X-Received: by 10.68.243.40 with SMTP id wv8mr24399213pbc.34.1372089531940; Mon, 24 Jun 2013 08:58:51 -0700 (PDT) X-Received: by 10.68.243.40 with SMTP id wv8mr24399205pbc.34.1372089531781; Mon, 24 Jun 2013 08:58:51 -0700 (PDT) References: <1372025267.7392.41.camel@localhost> <1372042346.7392.89.camel@localhost> From: John Kenney Mime-Version: 1.0 (1.0) In-Reply-To: <1372042346.7392.89.camel@localhost> Date: Mon, 24 Jun 2013 08:58:45 -0700 Message-ID: <7895374616906071020@unknownmsgid> To: Rex Buddenberg Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlnMUuUd5MlYkW2u02j928sxK3DcKaWsIdAr4kyRdWEDVT5+AleLcmygkzYRF5OGFgnyqX6+h2PE9WSrB4x5/9LW6RAHDkJvwAmOhjVEM2i6l8UkQJvX0QH3kjTWZPIdj6K40qm Cc: Alison Chaiken , "its@ietf.org" Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 15:58:57 -0000 Hi all: A couple of comments about managing channel load in DSRC. First, we have one channel on which Basic Safety Messages are sent (Ch. 172), and it is this one that is likely to be most heavily loaded for the foreseeable future. The auto industry in the US and Europe is actively working on channel congestion control algorithms. We see throughput maximizing at approximately 70-75% of bit rate, e.g. 4 to 4.5 Mbps when we use the 6 Mbps modulation/coding in 11p. We can control to this level with provable stability (paper references available for those interested). For other channels we have no current congestion concern, but are also confident we can manage it if/when needed. Best Regards, John Sent from my iPhone On Jun 23, 2013, at 7:52 PM, Rex Buddenberg wrote: > disentangling... > > On Sun, 2013-06-23 at 18:53 -0700, Alison Chaiken wrote: >> I write: >>>> Clearly a "siren indication" is an area where emergency vehicles, >>>> whatever method they use to call back to base, may want communicate to >>>> passenger vehicles, as well. >> >> Rex answers: >>> Unless I'm misreading something, the private key is associated with the >>> siren _sender_. Anyone can receive the message. Further, anyone could >>> relay the message because the message itself is not changed. And anyone >>> could validate the signature because the public key is, er, public. > Ahh. The above was about data, and definitely not about infrastructure. > And I think WSM is indeed about data too. > >> Sorry, I failed to ask my question, which is: > > ok, this is a collision -- two silos. Shifting gears: >> >> If passenger vehicles expect WSM on 802.11p, don't emergency vehicles >> then neeed 802.11p to communicate with them, irrespective of LTE plans >> for emergency vehicles? > > The cellphone companies are rolling out LTE infrastructure and it's > going in along the highways. (It's being advertised to you as 4g). Who > is rolling out 802.11? > >> Assuredly in the Grand Connected Future we >> don't expect that emergency vehicles will communicate with individual >> drivers via audible alarms and flashing lights only? > > The first observation is that both 802.11 and 802.16 (which LTE is a > clone of) are routable networks. So if there is dual radio-WAN > infrastructures, they will be interoperable. That's the good news. > Indeed there's no reason a vehicle's router could not be interfaced to > each simultaneously. > >> And assuredly >> having emergency vehicles call out siren messages over LTE to >> infrastructure which sends 802.11p would be ridiculous? Adding >> 802.11p to emergency vehicles will be expensive, but much less so than >> adding LTE to all cars. Even if cars have LTE for (gag) >> "infotainment," we can hardly rely on that channel to convey siren >> information as well. > > Strip off the uses for the moment; quick handwaving technical. LTE and > 802.11 are: > - both routable networks. > - more or less RF equivalent: both use OFDM. Note that 1609 has what > appears to be yet another layer 1/2 protocol (John Moring???)? The RF > range and power figures you can expect are little different than > non-protocol range figures that several modeling tools will show. > - all use ethernet framing within and pass the ethernet contents up > through the layer 2/3 interface, so the integration problems are > familiar. Routers know what to do with ethernet frames ... or rather > the contents thereof. > > The difference between the two protocols is in the MAC: > - all 802.11 protocols use CSMA of some flavor, derived from 802.3 > ethernet. This is a contention-access protocol, albeit with some > ifs/ands/buts attached. Contention protocols are comparatively easy to > implement but they have three defects in the radio-WAN environment that > tend not to show up in the wireless LAN one: > o contention protocols are unstable under overload. Too many > users, too much to say, the network segment stalls. > o the stall point occurs at depressingly low bandwidth efficiency > levels. Like around 20% of baseband capacity (depending again on a slew > of ifs/ands/buts). > o there's no way to manage your way out of this overload > situation. > > There is exactly one MAC message in WiFi: the so-called busy tone that > tells would-be SS to wait until someone else is finished (in the > labeling, this is the diff between CSMA/CD and CSMA/CA, but it's still > CSMA). > > > - 802.16 and LTE have a contention-free protocol borrowed from DOCSIS > (!!). It's a TDMA or time-slice arrangement where the base station (BS, > what 1609 calls the roadside unit) assigns each user a time slot where > only that subscriber station transmits. It's harder to implement (but > the problem is solved -- chipsets are readily available) but is > o stable under overload > o highly bandwidth efficient > o can be positively managed. > > > Business. At least in US, the cellphone companies are deploying LTE > (Clearwire has ceased expanding its 802.16 deployment because the market > herd all started braying LTE). There's a bunch of marketing > namecalling, but for all practical purposes '4G' = LTE = 802.16. I've > never heard any cellphone company or any DIY emergency service outfit so > much as mention 802.11 of any flavor. > (The emergency services folks think that they are going to have a > separate 800MHz LTE infrastructure. Their reasoning is that they need > 'assured access' (which I agree with) and therefore they need a separate > freq band (which I do not). This is their conventional wisdom right > now; it hasn't met economic reality yet). > I agree with your observation, Alison, that two infrastructures is > on the ridiculous side. Better to have one and invest in Ao to make it > work when the chips are down. > None of this has any impact _inside_ the vehicle -- it's only the > interface on the radio-WAN side of the router that cares. And there's > no reason that the router can't have both interfaces. > > > >> >> -- >> Alison Chaiken alison@she-devel.com >> 650-279-5600 http://{she-devel.com, >> exerciseforthereader.org} >> The intermediary between the head and the hands must be the heart. >> -- Thea von Harbou > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From buddenbergr@gmail.com Mon Jun 24 20:19:20 2013 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 CEDF821F9D0B for ; Mon, 24 Jun 2013 20:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbPl5qUNk8av for ; Mon, 24 Jun 2013 20:19:19 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 19CD211E8106 for ; Mon, 24 Jun 2013 20:19:17 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id lj1so11959036pab.31 for ; Mon, 24 Jun 2013 20:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=i7BHmTOuamKUZPdDK3N9wtjBm+r/YZDIBMQmDoGwzIE=; b=oxlO8ZhgD9DRWFIf7/PhHqx596l/bKiMkneUOvuA58bjbJ9ljnDKlASLeD3qZB2lb3 FnJ6r5gsyoTxec9IWAMVA7hPFJPB0zeJ4cBs2pp3nYzSMaBu9tZ7gCoKKuP2AYI4dm+u e7Y9KcfMOm0wWadwFf4uW1JZzGI05SzbpXYdqMYFkaavy9oPtKbYEmuxi/eAZcXI8CGF r9kwZfgSGqn0Fxr0Mqhg7KQ3lSPX5Ohdgm+SLiUgxmFAYANKMwOhTZf4Oi7zsbtqywMs ObWk5NUahRnf8hb9o52H80gWs+XCxCChNPxcIoBh+9tKabs19OtsfcU9WKpwc2Dt5oVd 2zZg== X-Received: by 10.66.149.198 with SMTP id uc6mr25661632pab.61.1372130357714; Mon, 24 Jun 2013 20:19:17 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id iq6sm20935765pbc.1.2013.06.24.20.19.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 24 Jun 2013 20:19:16 -0700 (PDT) Message-ID: <1372130355.7392.160.camel@localhost> From: Rex Buddenberg To: Michael Richardson Date: Mon, 24 Jun 2013 20:19:15 -0700 In-Reply-To: <20951.1372079256@sandelman.ca> References: <1372025267.7392.41.camel@localhost> <20951.1372079256@sandelman.ca> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Alison Chaiken , its@ietf.org Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 03:19:20 -0000 Michael, We might want to consider this the snowplow case; gets past some of your human factors issues. Try this as a variant to the ambulance/siren illustration. One of my friends and sounding board for such stuff works for Wyoming DoT. He observes that the casualty rate among snowplow operators in Wy is higher than among cops. The typical accident scenario is when the plow is working on I-80 and is overtaken by other traffic, the villain usually a semi. If the semi driver doesn't figure out that it is a snowplow ahead of him until too late, he's exceeded the intertia/road slickness limits, and rear-ends the plow. (Trucks as a class are more prone to push the weather limits than the family sedan. If the family sedan is out in this weather, and is smart, he's tucked in behind the semi). In this case, visibility is routinely awful (it's snowing, and often blowing). And even if the plow had a siren, the semi driver probably wouldn't hear it until too late. The sedan behind the semi is in an even worse situation. So this is a good use case for alerting message. On Mon, 2013-06-24 at 09:07 -0400, Michael Richardson wrote: > Alison Chaiken wrote: > alison> If passenger vehicles expect WSM on 802.11p, don't emergency > alison>vehicles then need 802.11p to communicate with them, irrespective > alison>of LTE plans for emergency vehicles? Assuredly in the Grand > alison>Connected Future we don't expect that emergency vehicles will > alison>communicate with individual drivers via audible alarms and > alison>flashing lights only? And assuredly having emergency vehicles > alison>call out siren messages over LTE to infrastructure which sends > alison>802.11p would be ridiculous? > > I don't know that it would be ridiculous to assume this. > I agree that the latency might suck. I presume, however two things: > > 1) the route the *ambulance* or *fire* truck might take is well known > in advance to the traffic control system ("in advance" is a relative > term, in this I'm saying that 5s >> 0.1s maximum latency). > So it need not be the vehicle *itself* that is calling out it's route, > the vehicle may well be following the route that the traffic control > system has established. > > 2) my observation is that flashing lights and sirens have two undesireable > affects. On overly consentious drivers (my mom-in-law, former er nurse), > they yank the wheel, to get out the way, often so fast they nearly > cause a collision themselves, even when the vehicle won't even be > coming near them. > On drivers who day-dream (my mom! "oh, was there a stop sign back there?") > they don't notice a thing until the vehicle is stuck behind them. > > It would be very useful to both of them to be told that the vehicle is > coming, and that it will in fact affect them. > > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > From alexandru.petrescu@gmail.com Tue Jun 25 00:46:35 2013 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 3FC3321F9FDD for ; Tue, 25 Jun 2013 00:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLnRdE6DlabV for ; Tue, 25 Jun 2013 00:46:30 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id DD37121F9FE3 for ; Tue, 25 Jun 2013 00:46:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5P7kS6l006315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 09:46:28 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5P7kRCd003880; Tue, 25 Jun 2013 09:46:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5P7kDHg022160; Tue, 25 Jun 2013 09:46:27 +0200 Message-ID: <51C94AC4.8080104@gmail.com> Date: Tue, 25 Jun 2013 09:46:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Richardson References: <51C4AC5B.3060404@gmail.com> <8844.1372032485@sandelman.ca> In-Reply-To: <8844.1372032485@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Alison Chaiken , its@ietf.org Subject: [its] advancements towards a bar BoF X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 07:46:35 -0000 Hello Michael, I can understand there were many BoF requests this time and a selection had to be made. I have been indicated that IESG thought that this is an interesting and important problem space, and worthy of further consideration. If we want it to succeed we need something considerably smaller scoped. Relationships to other SDOs can turn to the advantage of this activity _if_ we understand the SDO scope and interest, helping avoid duplicates and clarifying which technique is better suited where. Participation to this list of industry stakeholders and alliances is of high importance towards the scoping of needed work. Relationships to IETF groups is also important, and the ATOCA activity is a new facet yet to uncover. Given these reasons, and other than the ongoing good activities, we have been recommended the following: - pursue discussion towards identifying 1 area among the 3, involving industry interests. - hold a bar BoF in Berlin. - uncover ATOCA before Berlin. Yours, Alex Le 24/06/2013 02:08, Michael Richardson a écrit : > > Alexandru Petrescu wrote: >> The IESG has not approved the request for BoF ITS in Berlin. > > Please realize that there were like 16 BOF requests for the Berlin > meeting. Not only is there a lack of non-conflicting time slots, but > only so many WG can be spun upon in a given amount of time. > > So some of the reason is not specific to ITS, but I think that ITS > was not as clear as it needs to be as to it's charter. > > > -- Michael Richardson , Sandelman Software > Works > > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From abdussalambaryun@gmail.com Tue Jun 25 01:14:25 2013 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 EC07011E80E0 for ; Tue, 25 Jun 2013 01:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3Q8TvK2dxEV for ; Tue, 25 Jun 2013 01:14:22 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6384711E80E2 for ; Tue, 25 Jun 2013 01:14:20 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id tj12so12168599pac.40 for ; Tue, 25 Jun 2013 01:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uiCHdYs2xMMuvrKp8EFxMlbQ8PmBQq5ZpPvoHbM/PZo=; b=CBZGZpgMLvrno2uEJ1moSy+rLrqPlK2NwywE6IlOANR1BAAhRjc00ApjkdWJ26jN5Q eG7Feh2ZC3NnnsSFtDe5FEYf/z4dh+hhieuMFy6u31f8o6X3BzXb2R17K1l89o/3q/Tv e4E1/AuaYYkYCv74RXmqAKZI3iijvDuP2sHpa+KL3ERGOkkBB6o/hHPC2tiSFRLfxVLL F/qe3/r7JQNjRGxDdZYove1XSnHdCRLcG2zn+ioNAPsIWVA1uW3V/hJ9VfQ/U8hd6SwG /rFamjBYvCIpA8jpDl6q5yS7OMpOKvqvYamUJnflhJfRA3yNRiqyEhhSKwE9CoaP0PYm L2Ig== MIME-Version: 1.0 X-Received: by 10.68.219.42 with SMTP id pl10mr27625471pbc.24.1372148058434; Tue, 25 Jun 2013 01:14:18 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Tue, 25 Jun 2013 01:14:18 -0700 (PDT) In-Reply-To: <51C94AC4.8080104@gmail.com> References: <51C4AC5B.3060404@gmail.com> <8844.1372032485@sandelman.ca> <51C94AC4.8080104@gmail.com> Date: Tue, 25 Jun 2013 10:14:18 +0200 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: its@ietf.org Subject: Re: [its] advancements towards a bar BoF X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:14:26 -0000 On 6/25/13, Alexandru Petrescu wrote: > Hello Michael, > > I have been indicated that IESG thought that this is an interesting and > important problem space, and worthy of further consideration. If we > want it to succeed we need something considerably smaller scoped. Could I know what was the respond specifically? > > Relationships to other SDOs can turn to the advantage of this activity > _if_ we understand the SDO scope and interest, helping avoid duplicates > and clarifying which technique is better suited where. If something is missing in IETF then we focus on it, why we have to present the WORLD to check things don't duplicate, I think things in the WORLD is already duplicated every where. Does management in IETF don't understand other SDOs? I recommend we focus on the technology not procedures, others should do that job. > > Participation to this list of industry stakeholders and alliances is of > high importance towards the scoping of needed work. Why we make it difficult, industry are in competition so they have many reasons sometimes not to participate, does IESG think there is no interest in industry? if they think that do they have proof. Do we have proof that industry is interested in this WG, I think yes (they have interest to the establish but not directly participate). > > Relationships to IETF groups is also important, and the ATOCA activity > is a new facet yet to uncover. We already mentioned the relationship to other groups (each of them have different charter), Why is it not clear, not sure? > > Given these reasons, and other than the ongoing good activities, we have > been recommended the following: > - pursue discussion towards identifying 1 area among the 3, involving > industry interests. > - hold a bar BoF in Berlin. > - uncover ATOCA before Berlin. Yes we need to do it in Berlin, because I think the interest is in Europe region more than the North America region (Majority of participants). AB From abdussalambaryun@gmail.com Tue Jun 25 01:19:23 2013 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 E01A721F9FE3 for ; Tue, 25 Jun 2013 01:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5I1B7LrGarL for ; Tue, 25 Jun 2013 01:19:23 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6612821F9FC8 for ; Tue, 25 Jun 2013 01:19:21 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so12272862pbb.14 for ; Tue, 25 Jun 2013 01:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4h8bdeiEtRtUS+BKkaWdKnja2OJcwHcb/VjFGvkz9cw=; b=LIIk1to9g4M0UgqXG8c/3BjyyiuYdbsu4RC6EJa4H9BO+Y6mGQr2JQg1uGZFYUnXVL zYmbAkh2Bnsa41aRL589g98MTa7dAA6gtzk54UwW6bcgr5lXIlcOqa90e8yG3MTujXmE gs+wAfNifEatJ8zFZVj+5KsEb83/DnKgIcQ2MVGZ1jYQz4uJfJN8ujDtSBac7S6RmMV/ urQn9EUgtdwFhdGbr6hpUFZWySU5MWv6EWzhTZoZV67h0WgMsBmh3w79ChbXlNyGtorb OI+Jdxc3X46rhWRX+oJ1otnUvt0T+WXt87BY/pMSM5UWFhkB9QFvXC96nRs3WhHitt9B VQyA== MIME-Version: 1.0 X-Received: by 10.66.7.164 with SMTP id k4mr31489999paa.142.1372148361113; Tue, 25 Jun 2013 01:19:21 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Tue, 25 Jun 2013 01:19:20 -0700 (PDT) In-Reply-To: <51C4AC5B.3060404@gmail.com> References: <51C4AC5B.3060404@gmail.com> Date: Tue, 25 Jun 2013 10:19:20 +0200 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: its@ietf.org Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:19:24 -0000 Could I know what was the respond, or if there is a reference I can collect it? I want full respond not only summary? Sometimes I think we should close this WG if the IESG is not allowing it to continue :-( AB On 6/21/13, Alexandru Petrescu wrote: > Hello participants to ITS email list, > > The IESG has not approved the request for BoF ITS in Berlin. > > I still have to summarize the information I receive about the process, > the reasons, the next steps; I will email the list shortly. > > In the mean time, do not hesitate to make questions. > > Yours, > > Alex > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From alexandru.petrescu@gmail.com Tue Jun 25 01:49:05 2013 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 BCF4D21F92E7 for ; Tue, 25 Jun 2013 01:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.281 X-Spam-Level: X-Spam-Status: No, score=-10.281 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-Xlknw9EqWz for ; Tue, 25 Jun 2013 01:49:00 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDEE21F9E71 for ; Tue, 25 Jun 2013 01:48:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5P8mpxL018317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 10:48:51 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5P8mpWK006308; Tue, 25 Jun 2013 10:48:51 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5P8mhjd004905; Tue, 25 Jun 2013 10:48:51 +0200 Message-ID: <51C9596B.4090902@gmail.com> Date: Tue, 25 Jun 2013 10:48:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Abdussalam Baryun References: <51C4AC5B.3060404@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: its@ietf.org Subject: Re: [its] negative thoughts (was: Not approved BoF ITS Berlin) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:49:05 -0000 Le 25/06/2013 10:19, Abdussalam Baryun a écrit : > Could I know what was the respond, or if there is a reference I can > collect it? I want full respond not only summary? Abdussalam, There is no one full official response. There is a general 'do a bar bof' indication from IESG. Until now we ITS held very small bar BoFs ('informal meetings') but now IESG tells us to do a bar BoF. It is different. I hope for higher attendance to this bar BoF. A number of people at IESG are active and positive about this effort. They want us to succeed. > Sometimes I think we should close this WG if the IESG is not > allowing it to continue :-( There is frustration also here, but I see it this way. IESG did not tell us to stop continuing. They said we should continue this way, and identify one area on which to do the work. There are currently 3 areas (IPv6-over-80211p, 'geo-' work, 1-hop addressing and routing). Until we have that clearer we can't hold a BoF. That's what they said. Also, I have witnessed several kinds of BoFs/WGs at IETF that were successful so-and-so. We don't want a WG which is successful so-and-so, right? Alex > > AB > > On 6/21/13, Alexandru Petrescu wrote: >> Hello participants to ITS email list, >> >> The IESG has not approved the request for BoF ITS in Berlin. >> >> I still have to summarize the information I receive about the >> process, the reasons, the next steps; I will email the list >> shortly. >> >> In the mean time, do not hesitate to make questions. >> >> Yours, >> >> Alex _______________________________________________ its mailing >> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > From abdussalambaryun@gmail.com Tue Jun 25 02:01:20 2013 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 5EFDB21F9F6B for ; Tue, 25 Jun 2013 02:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmmxuFuXujgZ for ; Tue, 25 Jun 2013 02:01:19 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5B021F9FC5 for ; Tue, 25 Jun 2013 02:01:19 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so12212045pbb.5 for ; Tue, 25 Jun 2013 02:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+R1qVmNGjux8MwQHvfxTjMGXxCqX7AC/gIX1E3+RYjE=; b=YTLT/Quw9t0xKfU4+D1q/2T35AFxfUbMFLJrOu79IA8BBv9lJ6vuxg5GP+rJs/5rSD Aa+JTBzb+REMOD+udOKbRlky8t39HhfOcTPsbxPsTyh5VfYchiWQHuUFwz6zYhDmmXQy EWlZhiTgLHkW7hCCTQ+MifOLFw6EBzhQz68BsWYItJoYR39yLivyKKHn1j3Pm+s2WU3m 4Ftl6EaedPJiux4k5kthCQHPZNohVTRK6pyHueE52nRpQf2CaYwfyXLYx3mm0Fk3zHOC HMMMCv6uQaNO8B46B2xykWecGgWHzbmtyiN4QNdvPUQ7yT7JJtfvgetOyXxpc+We7ic+ jHTw== MIME-Version: 1.0 X-Received: by 10.66.145.98 with SMTP id st2mr31767450pab.24.1372150868278; Tue, 25 Jun 2013 02:01:08 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Tue, 25 Jun 2013 02:01:08 -0700 (PDT) In-Reply-To: <21E46EE9B979354990401539FD0A63E515AF40@DAPHNIS.office.hd> References: <51AB8843.1010206@gmail.com> <21E46EE9B979354990401539FD0A63E515AF40@DAPHNIS.office.hd> Date: Tue, 25 Jun 2013 11:01:08 +0200 Message-ID: From: Abdussalam Baryun To: Andreas Festag Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] Pending request of BoF slot for ITS of IETF in Berlin, decision by June 20, 27 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 09:01:20 -0000 Hi Andreas, I thank you for your input, my comments below, On 6/24/13, Andreas Festag wrote: > In summary, an IETF group dedicated to ITS would be welcome to address > IP-specific protocol aspects for cooperative ITS. I hope the IETF efforts > will take into account the existing solutions in ETSI TC ITS (and > elsewehere). Key to succeed with a BOF proposal is to have ITS stakeholders > in. Yes I agree, I think we are considering all solutions but also considering what will be more suitable for the Internet. Furthermore, I don't want the issue of SDOs to make this group delayed in becoming an IETF WG, however, I see an important issue that IESG SHOULD understand which they may ignored: - The interests of ITS are in Europe mostly (which we can see from Alex and Andreas input in the list). - That for ITS technology each region has its different issues, now for Europe region, I agree that we should consider solutions and deployments in Europe (Andreas proposal). - For America regions they should not force this group to make it different only if they have clear participation best ideas that is backed by industry. - This group can start with Europe ITS technologies for Internet standards (high demanded) and then America ITS technologies. All for the best of the Internet future development. AB > > Kind regards, > > Andreas Festag > ETSI TC ITS WG3 chairman > > > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Sunday, June 02, 2013 8:01 PM > To: its@ietf.org > Subject: [its] Pending request of BoF slot for ITS of IETF in Berlin, > decision by June 20, 27 > > ITSers, > > I wanted to let you know that I have sent a request for scheduling a BoF > session for ITS of IETF in Berlin. We will get a response by June 20 or > June 27th. > > I guess the decision for Berlin depends largely on the content and activity > of the email list, how far are we with Charter, how much interest there > really is, other independent signals. > > The membership of the list counts approximately 200 email addresses. > > Alex > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From abdussalambaryun@gmail.com Tue Jun 25 02:24:55 2013 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 6715D11E80D1 for ; Tue, 25 Jun 2013 02:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVaV4n5sFjhC for ; Tue, 25 Jun 2013 02:24:53 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 91BBC21FA000 for ; Tue, 25 Jun 2013 02:24:53 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so12249007pbb.6 for ; Tue, 25 Jun 2013 02:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KSBQmfEXlUdXiWP1gofsfgCbHIXtWRTLD+i7O8Y+8pI=; b=yxmQq8+h/ZyLF9wRGdm59ZYX+VOJyv7CIfDUbRl3MjOLDMTrX2bhie2xy2xg5c8/F8 6CYhYshhj0MlxTNMfxDaLI4yql50aCvP52pJgue1Vs447AFwOHgc+E8hZVxGse0pE6uE Q+plHnhPAzVFr0RJrn/arXv2gPn1jAGT+DdkoqeVR4TSQN7/7l6q77xPM+5xGBT/JsVT a1Uc9rZ0pQ8R11FArJ3w67r6YLBAbBfo1O1pxucPP1mK78BN2CNTM5jxUDAeVRkI1iqJ /eVune9bktlsevlkmvEh+q8L5dbZnbnL41G1zjJVHkmgs/dCfw1xysV9m0qsy4NpERMM yIXg== MIME-Version: 1.0 X-Received: by 10.66.7.164 with SMTP id k4mr31724346paa.142.1372152293343; Tue, 25 Jun 2013 02:24:53 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Tue, 25 Jun 2013 02:24:53 -0700 (PDT) In-Reply-To: <51C9596B.4090902@gmail.com> References: <51C4AC5B.3060404@gmail.com> <51C9596B.4090902@gmail.com> Date: Tue, 25 Jun 2013 11:24:53 +0200 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: its@ietf.org Subject: Re: [its] negative thoughts (was: Not approved BoF ITS Berlin) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 09:24:55 -0000 Hi Alex, Thanks, I am ok not negative :-), as long as I get a clear respond what they need and we will do that to progress. I want to see progress clear, not arguing with the IESG. I feel we are now in stage of (NOT APPROVE, is negative respond not encouraging). That means that we have to submit a new one and they still can say not approved again. From your message it can be understood that you beleive that they are saying we (Will Approve subject to clarifications of this and this), but I don't share your beleive only if the respond is clear as well. On 6/25/13, Alexandru Petrescu wrote: > Le 25/06/2013 10:19, Abdussalam Baryun a =E9crit : >> Could I know what was the respond, or if there is a reference I can >> collect it? I want full respond not only summary? > > Abdussalam, > > There is no one full official response. There is a general 'do a bar > bof' indication from IESG. Until now we ITS held very small bar BoFs > ('informal meetings') but now IESG tells us to do a bar BoF. It is > different. I hope for higher attendance to this bar BoF. They SHOULD consider remote participation as well, and I think we will get higher attendance this time. > > A number of people at IESG are active and positive about this effort. > They want us to succeed. Ok, that is nice, but if that is true why I don't see progress, I think this group is very important but is delayed. The number of people SHOULD not be an issue in their consideration of approvals, the issue SHOULD be the need of technology. If ETSI is doing alot of work in this field, why the IETF is not progressing in such field (not successful approach, to wait for numbers its quality that counts). > >> Sometimes I think we should close this WG if the IESG is not >> allowing it to continue :-( > > There is frustration also here, but I see it this way. > > IESG did not tell us to stop continuing. They said we should continue > this way, and identify one area on which to do the work. The IESG has no authority to tell community to stop or continue. We do what we feel better but both should be clear in their decisions. I feel IESG is not clear if they don't post an input in this list saying what was the respond. Then I can hold their respond and follow to progress. > There are > currently 3 areas (IPv6-over-80211p, 'geo-' work, 1-hop addressing and > routing). > Until we have that clearer we can't hold a BoF. That's what > they said. Ok, so I will choose not to separate ITS into areas, why did they do that? I recommend we focus on the ITS and see what is better for us and the ITS to standard first. However, I think we already done that in the charter. AB From lear@cisco.com Tue Jun 25 02:32:30 2013 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 3A84F21F9EE6 for ; Tue, 25 Jun 2013 02:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.637 X-Spam-Level: X-Spam-Status: No, score=-110.637 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paonBcVYBwVN for ; Tue, 25 Jun 2013 02:32:26 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 61BCE21F9958 for ; Tue, 25 Jun 2013 02:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6358; q=dns/txt; s=iport; t=1372152745; x=1373362345; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=CAhsaO0x5pAeyshInZep54yDu8wk8EZSkQfFvH7Io9s=; b=MfWV+jZyPDa3uAEmhc0S1DSUCIfoej8nAXJlwJTHwDJ2aMz7BwXqHxHY iJV664YuvQVgHoGaPpS3hv6iKbNS4x8Rr8DL4JjsplHgcIvdK6WpiIjq9 bXWCo3E3E74Oqnzw7kx2XZoxwL7gN5Ke4Ahs65ND+UXy5aP4g+g443Qz/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAFJjyVGQ/khM/2dsb2JhbABagwkxg06FXbZXgQEWdIIjAQEBBCNVARALGAkWCwICCQMCAQIBKxoGDQEHAQEFiAUMqSSRVo4NgTgHgk+BFAOXQ4EpkBuDEjqBLA X-IronPort-AV: E=Sophos;i="4.87,935,1363132800"; d="scan'208,217";a="14503018" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 25 Jun 2013 09:32:24 +0000 Received: from mctiny.local ([10.61.175.226]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5P9WLZ3002493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 09:32:22 GMT Message-ID: <51C963A5.6040907@cisco.com> Date: Tue, 25 Jun 2013 11:32:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Abdussalam Baryun References: <51C4AC5B.3060404@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------010909020307060805020006" Cc: Alexandru Petrescu , its@ietf.org Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 09:32:30 -0000 This is a multi-part message in MIME format. --------------010909020307060805020006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi AB, The guidelines for successful BoFs can be found in RFC-5434[1]. Alexandru has done a very good job at getting things going. Just because the IESG passed on this BoF at this next meeting doesn't mean the work is unimportant. My impression is otherwise, but it's not *yet* crisply enough defined. On 6/25/13 10:19 AM, Abdussalam Baryun wrote: > Could I know what was the respond, or if there is a reference I can > collect it? I want full respond not only summary? Sometimes I think we > should close this WG if the IESG is not allowing it to continue :-( > The BoF proposed to tackle three rather distinct issues: # establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol, # layering of IPv6 over IEEE 802.11p communication technology and # IPv6-based network-layer distribution of content in a geographic area In the latter case, we have work going on relating to emergency alerts in the ATOCA working group, and we don't yet understand the overlap. In the case of 802.11p, the exact problem to be addressed to get IPv6 running on it isn't clear and therefore whether it should be addressed in IEEE 802.11 or by us is also not clear. In the case of v2v communications, here we need to understand a bit more why existing protocol suites aren't sufficient. But above and beyond all of this there should be some confidence that the results will be accepted by the industry. We know they play heavily in ISO TC-207. See [1] for a series of standards that are either adopted or in progress. ETSI is also in this space. Will the manufacturers adopt our work as well? Some additional activity on this list might prove convincing. And then there is the fact that the IETF is limited in the number of BoFs we can support. This space is both interesting and important. If we can get to a point that we can see that there will be adoption, and that the goals are achievable in a reasonable period of time, then I would expect a WG to be formed. Vancouver offers an additional opportunity for a formal BoF. In the meantime, take advantage of Berlin to meet, discuss, and figure these questions out, and zero down to specific actionable areas. I will be available for any and all of these discussions. Eliot [1] http://tools.ietf.org/html/rfc5434 [2] http://www.iso.org/iso/home/store/catalogue_tc/catalogue_tc_browse.htm?commid=54706&published=on&development=on --------------010909020307060805020006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi AB,

The guidelines for successful BoFs can be found in RFC-5434[1].  Alexandru has done a very good job at getting things going.  Just because the IESG passed on this BoF at this next meeting doesn't mean the work is unimportant.  My impression is otherwise, but it's not yet crisply enough defined.

On 6/25/13 10:19 AM, Abdussalam Baryun wrote:
Could I know what was the respond, or if there is a reference I can
collect it? I want full respond not only summary? Sometimes I think we
should close this WG if the IESG is not allowing it to continue :-(
The BoF  proposed to tackle three rather distinct issues:

  • establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol,
  • layering of IPv6 over IEEE 802.11p communication technology and
  • IPv6-based network-layer distribution of content in a geographic area

    • In the latter case, we have work going on relating to emergency alerts in the ATOCA working group, and we don't yet understand the overlap.  In the case of 802.11p,  the exact problem to be addressed to get IPv6 running on it isn't clear and therefore whether it should be addressed in IEEE 802.11 or by us is also not clear.  In the case of v2v communications, here we need to understand a bit more why existing protocol suites aren't sufficient. 

    But above and beyond all of this there should be some confidence that the results will be accepted by the industry.  We know they play heavily in ISO TC-207.  See [1] for a series of standards that are either adopted or in progress.  ETSI is also in this space.  Will the manufacturers adopt our work as well?  Some additional activity on this list might prove convincing.

    And then there is the fact that the IETF is limited in the number of BoFs we can support.

    This space is both interesting and important.  If we can get to a point that we can see that there will be adoption, and that the goals are achievable in a reasonable period of time, then I would expect a WG to be formed.  Vancouver offers an additional opportunity for a formal BoF.  In the meantime, take advantage of Berlin to meet, discuss, and figure these questions out, and zero down to specific actionable areas.

    I will be available for any and all of these discussions. 

    Eliot

    [1] http://tools.ietf.org/html/rfc5434
    [2] http://www.iso.org/iso/home/store/catalogue_tc/catalogue_tc_browse.htm?commid=54706&published=on&development=on

    --------------010909020307060805020006-- From william.d.ivancic@nasa.gov Tue Jun 25 05:39:31 2013 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 0219C21F99DC for ; Tue, 25 Jun 2013 05:39:31 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRd6wGvp3-p6 for ; Tue, 25 Jun 2013 05:39:24 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 648CD21E808E for ; Tue, 25 Jun 2013 05:39:24 -0700 (PDT) Received: from ndjsppt104.ndc.nasa.gov (NDJSPPT104.ndc.nasa.gov [198.117.1.198]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id CBC422D8066; Tue, 25 Jun 2013 07:39:23 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r5PCdN9w012736; Tue, 25 Jun 2013 07:39:23 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Tue, 25 Jun 2013 07:39:23 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Abdussalam Baryun , Alexandru Petrescu Date: Tue, 25 Jun 2013 07:39:26 -0500 Thread-Topic: [its] Not approved BoF ITS Berlin Thread-Index: Ac5xfLhLSkPNavQWTbq74gxnSBxJegAJE6eC Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-25_04:2013-06-24, 2013-06-25, 1970-01-01 signatures=0 Cc: "its@ietf.org" Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:39:31 -0000 Alex, This ITS group is currently just a mailing list. It is not a Working Group= . In order to become a working group, we need a concise, bounded piece of wor= k related to the use of internet technologies and protocols (either existing, something that needs development) that needs to be done and sufficient interest and energy to accomplish the work. IMHO, this has yet to be well articulated and probably the reason why IESG has not granted a BOF. You want a successful BOF with the outcome of a charter on what problem a working group would work to solve as well as a rough schedule. IMHO, an unsuccessful BOF is death to forming any working group. Rarely is a second BOF held. So, the suggestion of a Bar BOF is actually a way to get the group to focus the problem space and do their homework in the hope that it will lead to a successful IETF sanctioned BOF. While I agree that most work in ITS appears to be coming from Europe, concentrating on a Europe only solution would probably not be a way to get IESG approval of a working group. The bottom line is that we need to draft a working group charter indicating what problem or problems need to be solved with Internet technologies. To go into a BOF, you would probably want a Charter and a Problem Statement Draft - even for a bar BOF. This will form the basis for focused discussion. That being said, I am just an observer at this point. I am currently working Space Suit technology, but see similarities with general ITS - not just Internet related. Note, the technical term for space suit is Extra-vehicular Mobile Unit (EMU). It is really a self contained mini-spacecraft with critical life-support, communications, and informatics= . These map closely to ITS critical controls, on-board and wide area communications and entertainment systems. -- Will Ivancic > From: Abdussalam Baryun > Date: Tue, 25 Jun 2013 03:19:20 -0500 > To: Alexandru Petrescu > Cc: "its@ietf.org" > Subject: Re: [its] Not approved BoF ITS Berlin >=20 > Could I know what was the respond, or if there is a reference I can > collect it? I want full respond not only summary? Sometimes I think we > should close this WG if the IESG is not allowing it to continue :-( >=20 > AB From william.d.ivancic@nasa.gov Tue Jun 25 05:49:22 2013 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 DC9C821F9E18 for ; Tue, 25 Jun 2013 05:49:22 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af-oVFOWo4zb for ; Tue, 25 Jun 2013 05:49:17 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id A377B21F96EB for ; Tue, 25 Jun 2013 05:49:17 -0700 (PDT) Received: from ndjsppt105.ndc.nasa.gov (NDJSPPT105.ndc.nasa.gov [198.117.1.199]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id B939126006A; Tue, 25 Jun 2013 07:49:16 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt105.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r5PCnGsv022348; Tue, 25 Jun 2013 07:49:16 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Tue, 25 Jun 2013 07:49:16 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Ivancic, William D. (GRC-RHN0)" , Abdussalam Baryun , Alexandru Petrescu Date: Tue, 25 Jun 2013 07:49:19 -0500 Thread-Topic: [its] Not approved BoF ITS Berlin Thread-Index: Ac5xfLhLSkPNavQWTbq74gxnSBxJegAJE6eCAABYXaM= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-25_04:2013-06-24, 2013-06-25, 1970-01-01 signatures=0 Cc: "its@ietf.org" Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:49:23 -0000 I know there is a draft charter that was let to the mailing list, but it is fairly general. To me, it indicates there are lots of potential areas to work and we need to figure out what to do. I don't disagree, but a good charter that would lead to a working group probably needs to be more focuse= d indicated the specific problem that needs to be address and why along with an approach. I think we need a well articulated problem statement. -- Will > From: "Ivancic, William D. (GRC-RHN0)" > Date: Tue, 25 Jun 2013 07:39:26 -0500 > To: Abdussalam Baryun , Alexandru Petrescu > > Cc: "its@ietf.org" > Subject: Re: [its] Not approved BoF ITS Berlin >=20 > Alex, >=20 > This ITS group is currently just a mailing list. It is not a Working Gro= up. >=20 > In order to become a working group, we need a concise, bounded piece of w= ork > related to the use of internet technologies and protocols (either existin= g, > something that needs development) that needs to be done and sufficient > interest and energy to accomplish the work. >=20 > IMHO, this has yet to be well articulated and probably the reason why IES= G > has not granted a BOF. You want a successful BOF with the outcome of a > charter on what problem a working group would work to solve as well as a > rough schedule. IMHO, an unsuccessful BOF is death to forming any workin= g > group. Rarely is a second BOF held. So, the suggestion of a Bar BOF is > actually a way to get the group to focus the problem space and do their > homework in the hope that it will lead to a successful IETF sanctioned BO= F. >=20 > While I agree that most work in ITS appears to be coming from Europe, > concentrating on a Europe only solution would probably not be a way to ge= t > IESG approval of a working group. >=20 > The bottom line is that we need to draft a working group charter indicati= ng > what problem or problems need to be solved with Internet technologies. T= o > go into a BOF, you would probably want a Charter and a Problem Statement > Draft - even for a bar BOF. This will form the basis for focused > discussion. >=20 > That being said, I am just an observer at this point. I am currently > working Space Suit technology, but see similarities with general ITS - no= t > just Internet related. Note, the technical term for space suit is > Extra-vehicular Mobile Unit (EMU). It is really a self contained > mini-spacecraft with critical life-support, communications, and informati= cs. > These map closely to ITS critical controls, on-board and wide area > communications and entertainment systems. >=20 >=20 > -- Will Ivancic >=20 >> From: Abdussalam Baryun >> Date: Tue, 25 Jun 2013 03:19:20 -0500 >> To: Alexandru Petrescu >> Cc: "its@ietf.org" >> Subject: Re: [its] Not approved BoF ITS Berlin >>=20 >> Could I know what was the respond, or if there is a reference I can >> collect it? I want full respond not only summary? Sometimes I think we >> should close this WG if the IESG is not allowing it to continue :-( >>=20 >> AB >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Tue Jun 25 05:57:57 2013 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 1601221E8098 for ; Tue, 25 Jun 2013 05:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.279 X-Spam-Level: X-Spam-Status: No, score=-10.279 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgQdLI8lYEuk for ; Tue, 25 Jun 2013 05:57:51 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 60F3811E80E8 for ; Tue, 25 Jun 2013 05:57:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5PCvFjw021935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 14:57:15 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5PCvFNj019394; Tue, 25 Jun 2013 14:57:15 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5PCv4Og032398; Tue, 25 Jun 2013 14:57:15 +0200 Message-ID: <51C993A0.3070008@gmail.com> Date: Tue, 25 Jun 2013 14:57:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RHN0)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" , Abdussalam Baryun Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:57:57 -0000 I agree we need to articulate a Problem Statement draft and a draft Charter for Berlin, focused on one work area. For the EMU unit, which of these areas would be more helpful? 1. establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol, 2. layering of IPv6 over IEEE 802.11p communication technology 3. IPv6-based network-layer distribution of content in a geographic area Alex Le 25/06/2013 14:49, Ivancic, William D. (GRC-RHN0) a écrit : > I know there is a draft charter that was let to the mailing list, but > it is fairly general. To me, it indicates there are lots of potential > areas to work and we need to figure out what to do. I don't > disagree, but a good charter that would lead to a working group > probably needs to be more focused indicated the specific problem that > needs to be address and why along with an approach. > > I think we need a well articulated problem statement. > > -- Will > > > >> From: "Ivancic, William D. (GRC-RHN0)" >> Date: Tue, 25 Jun 2013 07:39:26 -0500 >> To: Abdussalam Baryun , Alexandru >> Petrescu Cc: "its@ietf.org" >> Subject: Re: [its] Not approved BoF ITS Berlin >> >> Alex, >> >> This ITS group is currently just a mailing list. It is not a >> Working Group. >> >> In order to become a working group, we need a concise, bounded >> piece of work related to the use of internet technologies and >> protocols (either existing, something that needs development) that >> needs to be done and sufficient interest and energy to accomplish >> the work. >> >> IMHO, this has yet to be well articulated and probably the reason >> why IESG has not granted a BOF. You want a successful BOF with the >> outcome of a charter on what problem a working group would work to >> solve as well as a rough schedule. IMHO, an unsuccessful BOF is >> death to forming any working group. Rarely is a second BOF held. >> So, the suggestion of a Bar BOF is actually a way to get the group >> to focus the problem space and do their homework in the hope that >> it will lead to a successful IETF sanctioned BOF. >> >> While I agree that most work in ITS appears to be coming from >> Europe, concentrating on a Europe only solution would probably not >> be a way to get IESG approval of a working group. >> >> The bottom line is that we need to draft a working group charter >> indicating what problem or problems need to be solved with Internet >> technologies. To go into a BOF, you would probably want a Charter >> and a Problem Statement Draft - even for a bar BOF. This will form >> the basis for focused discussion. >> >> That being said, I am just an observer at this point. I am >> currently working Space Suit technology, but see similarities with >> general ITS - not just Internet related. Note, the technical term >> for space suit is Extra-vehicular Mobile Unit (EMU). It is really >> a self contained mini-spacecraft with critical life-support, >> communications, and informatics. These map closely to ITS critical >> controls, on-board and wide area communications and entertainment >> systems. >> >> >> -- Will Ivancic >> >>> From: Abdussalam Baryun Date: Tue, >>> 25 Jun 2013 03:19:20 -0500 To: Alexandru Petrescu >>> Cc: "its@ietf.org" >>> Subject: Re: [its] Not approved BoF ITS Berlin >>> >>> Could I know what was the respond, or if there is a reference I >>> can collect it? I want full respond not only summary? Sometimes I >>> think we should close this WG if the IESG is not allowing it to >>> continue :-( >>> >>> AB >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > From william.d.ivancic@nasa.gov Tue Jun 25 06:49:57 2013 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 5BBE021E8090 for ; Tue, 25 Jun 2013 06:49:57 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRVFKLeJZlgN for ; Tue, 25 Jun 2013 06:49:51 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB7F21E80AD for ; Tue, 25 Jun 2013 06:49:51 -0700 (PDT) Received: from ndjsppt105.ndc.nasa.gov (NDJSPPT105.ndc.nasa.gov [198.117.1.199]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 6C2C62D809F; Tue, 25 Jun 2013 08:49:50 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt105.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r5PDnoGA011608; Tue, 25 Jun 2013 08:49:50 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Tue, 25 Jun 2013 08:49:50 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Alexandru Petrescu Date: Tue, 25 Jun 2013 08:49:53 -0500 Thread-Topic: [its] Not approved BoF ITS Berlin Thread-Index: Ac5xo4iDsSKwkslFS/e33es3r4N2OgAB1XlR Message-ID: In-Reply-To: <51C993A0.3070008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-25_05:2013-06-24, 2013-06-25, 1970-01-01 signatures=0 Cc: "its@ietf.org" , Abdussalam Baryun Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:49:57 -0000 I would say 1 and 2 in that order. For the foreseeable future, my participation will have to be remote. The US Government has greatly restricted travel for political reasons following the GSA and IRS travel issues that have been in the news in the States. -- Will >=20 > For the EMU unit, which of these areas would be more helpful? >=20 > 1. establishment of IP networking between neighboring vehicles using > either MANET protocols or 1-hop ICMP protocol, >=20 > 2. layering of IPv6 over IEEE 802.11p communication technology >=20 > 3. IPv6-based network-layer distribution of content in a geographic area >=20 > Alex >=20 From alexandru.petrescu@gmail.com Tue Jun 25 08:48:41 2013 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 2307211E80FD for ; Tue, 25 Jun 2013 08:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.65 X-Spam-Level: X-Spam-Status: No, score=-7.65 tagged_above=-999 required=5 tests=[HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyQap+WWCuWi for ; Tue, 25 Jun 2013 08:48:35 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9B54D11E80F5 for ; Tue, 25 Jun 2013 08:48:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5PFmTmU020760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 25 Jun 2013 17:48:29 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5PFmTHi006079 for ; Tue, 25 Jun 2013 17:48:29 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5PFmTko003342 for ; Tue, 25 Jun 2013 17:48:29 +0200 Message-ID: <51C9BBCC.1090304@gmail.com> Date: Tue, 25 Jun 2013 17:48:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:48:41 -0000 Hello participants to ITS email list, During recent discussions we mentioned 3 different areas to work on. They are too many for a meaningful detail work. Please select area scoping the Charter, prioritizing according to the environment you work on. 1. establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol. 2. layering of IPv6 over IEEE 802.11p communication technology. 3. IPv6-based network-layer distribution of content in a geographic area. Yours, Alex From mcr@sandelman.ca Tue Jun 25 10:55:22 2013 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 2CB8E21F9A44 for ; Tue, 25 Jun 2013 10:55:22 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sRqN0TDEM81 for ; Tue, 25 Jun 2013 10:55:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id C76D511E8118 for ; Tue, 25 Jun 2013 10:55:14 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id ECC3B20171; Tue, 25 Jun 2013 14:59:14 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3496563A7C; Tue, 25 Jun 2013 13:54:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2264C63A5E; Tue, 25 Jun 2013 13:54:08 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <51C9BBCC.1090304@gmail.com> References: <51C9BBCC.1090304@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "its@ietf.org" Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:55:22 -0000 --=-=-= Alexandru Petrescu wrote: > Hello participants to ITS email list, > During recent discussions we mentioned 3 different areas to work on. > They are too many for a meaningful detail work. > Please select area scoping the Charter, prioritizing according to the > environment you work on. > 1. establishment of IP networking between neighboring vehicles using > either MANET protocols or 1-hop ICMP protocol. Do you mean address allocation or routing? > 2. layering of IPv6 over IEEE 802.11p communication technology. I am not convinced this isn't a nop. (empty set) > 3. IPv6-based network-layer distribution of content in a geographic > area. This interests me the most. *MY* use cases are idiosyncratic and very anarcho-syndicalist, and as such suffer from "no way to make a buck" problem. I think that it does not require, at this point, standardization, as I am not convinced the parties who want/need to do this are actually at the IETF table yet. I think that a group of funded researchers could prototype such a thing using existing well defined protocols, and having demostrated such a thing to an appropriate set of equipment (by this, I mean, "vehicle") vendors. At that point, a specification would ensue. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUcnZO4qHRg3pndX9AQLifAP/UqY6yhZj3BWBVof+dyxzXX79Dj+tVbN2 1Drcmk/Pvio1V5y1qM3/sCfHbRy9ZTwicV+i/mp4uOCjSwN5e0mgaVK5YD6Q/MNl iiM9S9oiTWAtMLQGxOyWNwKU3ahvrbeBfrMenL+bLPALnkI7t6T5YSJutvmD8Dk7 Z/89J456bTo= =+or5 -----END PGP SIGNATURE----- --=-=-=-- From dromasca@avaya.com Wed Jun 26 00:41:00 2013 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 32E8C21F99F4 for ; Wed, 26 Jun 2013 00:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxWeS6VK77cy for ; Wed, 26 Jun 2013 00:40:53 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69821F9980 for ; Wed, 26 Jun 2013 00:40:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAK6ZylHGmAcF/2dsb2JhbABagmgher53gQYWdIIjAQEBAQMSKD8MBAIBCA0IDRQJBzIUEQIEAQ0FCBqHbAGeR5t8jxkxB4MCYQOeB4sBgxGCKA X-IronPort-AV: E=Sophos;i="4.87,941,1363147200"; d="scan'208";a="14486883" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jun 2013 03:40:51 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jun 2013 03:38:28 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 09:40:49 +0200 From: "Romascanu, Dan (Dan)" To: Michael Richardson , Alexandru Petrescu Thread-Topic: [its] Please select area scoping the Charter Thread-Index: AQHOcbt7PmWVXOM5OUaAPdv9EtCczZlG+ZIAgACjPxA= Date: Wed, 26 Jun 2013 07:40:49 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> In-Reply-To: <28782.1372182848@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "its@ietf.org" Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 07:41:00 -0000 > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of > Michael Richardson >=20 > > 2. layering of IPv6 over IEEE 802.11p communication technology. >=20 > I am not convinced this isn't a nop. (empty set) >=20 [[DR]] I was actually asking myself the same question. Did anybody do an an= alysis / requirements about what work needs to be done here? Assuming it's = not a nop - is this something specific to its? Or rather in a broader scope= (intarea?) Regards, Dan From Dirk.von-Hugo@telekom.de Wed Jun 26 02:20:05 2013 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 088E021E80F9 for ; Wed, 26 Jun 2013 02:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-1L1BxBxH7E for ; Wed, 26 Jun 2013 02:20:01 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id BAAB521E80D7 for ; Wed, 26 Jun 2013 02:19:59 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 26 Jun 2013 11:19:57 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.120]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 26 Jun 2013 11:19:56 +0200 From: To: , Date: Wed, 26 Jun 2013 11:19:55 +0200 Thread-Topic: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration Thread-Index: Ac5xUsv1osFwRsemRTmJv3QzM51htwA+uEEg Message-ID: <05C81A773E48DD49B181B04BA21A342A2C33C70A07@HE113484.emea1.cds.t-internal.com> References: <1372025267.7392.41.camel@localhost> <20951.1372079256@sandelman.ca> <1372130355.7392.160.camel@localhost> In-Reply-To: <1372130355.7392.160.camel@localhost> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: alison@she-devel.com, its@ietf.org Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 09:20:05 -0000 Hi all, Speaking of actual use cases it may be of interest that the German project = SIMTD - "Safe, Intelligent Mobility - Test field Deutschland (Germany)" has= completed to test the functionality, efficacy and feasibility for everyday= use of car-to-x communication under real-life driving conditions. Some de= tailed information can be found here: http://simtd.de/index.dhtml/0251caae4= 65f8345005d/-/enEN/-/CS/-/ and =20 http://simtd.de/index.dhtml/0251caae465f8345005d/object.media/enEN/8033/CS/= -/news/Presse/simTD-Pressemitteilung_2013_EN.pdf Best regards Dirk -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Rex B= uddenberg Sent: Dienstag, 25. Juni 2013 05:19 To: Michael Richardson Cc: Alison Chaiken; its@ietf.org Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configu= ration Michael, We might want to consider this the snowplow case; gets past some of your hu= man factors issues. Try this as a variant to the ambulance/siren illustrat= ion. One of my friends and sounding board for such stuff works for Wyoming DoT. = He observes that the casualty rate among snowplow operators in Wy is highe= r than among cops. The typical accident scenario is when the plow is worki= ng on I-80 and is overtaken by other traffic, the villain usually a semi. = If the semi driver doesn't figure out that it is a snowplow ahead of him un= til too late, he's exceeded the intertia/road slickness limits, and rear-en= ds the plow. (Trucks as a class are more prone to push the weather limits = than the family sedan. If the family sedan is out in this weather, and is = smart, he's tucked in behind the semi). In this case, visibility is routinely awful (it's snowing, and often bl= owing). And even if the plow had a siren, the semi driver probably wouldn'= t hear it until too late. The sedan behind the semi is in an even worse si= tuation. =20 So this is a good use case for alerting message. =20 On Mon, 2013-06-24 at 09:07 -0400, Michael Richardson wrote: > Alison Chaiken wrote: > alison> If passenger vehicles expect WSM on 802.11p, don't emergency > alison>vehicles then need 802.11p to communicate with them, irrespect= ive > alison>of LTE plans for emergency vehicles? Assuredly in the Grand > alison>Connected Future we don't expect that emergency vehicles will > alison>communicate with individual drivers via audible alarms and > alison>flashing lights only? And assuredly having emergency vehicles > alison>call out siren messages over LTE to infrastructure which sends > alison>802.11p would be ridiculous? >=20 > I don't know that it would be ridiculous to assume this. > I agree that the latency might suck. I presume, however two things: >=20 > 1) the route the *ambulance* or *fire* truck might take is well known > in advance to the traffic control system ("in advance" is a relative > term, in this I'm saying that 5s >> 0.1s maximum latency). > So it need not be the vehicle *itself* that is calling out it's route, > the vehicle may well be following the route that the traffic control > system has established. >=20 > 2) my observation is that flashing lights and sirens have two undesireabl= e > affects. On overly consentious drivers (my mom-in-law, former er nurs= e), > they yank the wheel, to get out the way, often so fast they nearly > cause a collision themselves, even when the vehicle won't even be > coming near them. > On drivers who day-dream (my mom! "oh, was there a stop sign back the= re?") > they don't notice a thing until the vehicle is stuck behind them. >=20 > It would be very useful to both of them to be told that the vehicle is=20 > coming, and that it will in fact affect them. >=20 >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From abdussalambaryun@gmail.com Wed Jun 26 05:59:37 2013 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 568CB11E81CC for ; Wed, 26 Jun 2013 05:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB5DilWbEHxO for ; Wed, 26 Jun 2013 05:59:36 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 799D011E81C3 for ; Wed, 26 Jun 2013 05:59:36 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so14167373pad.0 for ; Wed, 26 Jun 2013 05:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K/n4K7EnIN85tUzDISDEfdnWtEnPsVhh2JnzxtYDcaY=; b=UGO8ZhC5lJyOATvcKZz5kB9/fZLe4WGgSIO8/X6wjphoRzMqpZSp9FEQXKEvRaIt+y ZlhhZ7zU4WO8PyQIYf+gbXROfjHFLR0TWDhvPoPGzNv6WF0KJ76p6Zb3e7ChsUvMqiTp omuj43O0pZQPY7rZoEd3pMNkoe4pBWeA76w68fLQPCjGNDVVP+dZpjBL/p48AM2vV142 qh7HIFW+klOtMU3e0fd5AKsaRfzAl9/hJ7nH2TH7BcFoChQFmolNWdlnPllNsW5wQSQU n3UgGFVAKWMsXqQC4H9uwa7QCTA6WsdzcXlLdZyTijuqE8LARcpoXCh2I1HwRFJPJvHO nsVg== MIME-Version: 1.0 X-Received: by 10.66.221.101 with SMTP id qd5mr527153pac.174.1372251576124; Wed, 26 Jun 2013 05:59:36 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Wed, 26 Jun 2013 05:59:36 -0700 (PDT) In-Reply-To: <51C963A5.6040907@cisco.com> References: <51C4AC5B.3060404@gmail.com> <51C963A5.6040907@cisco.com> Date: Wed, 26 Jun 2013 14:59:36 +0200 Message-ID: From: Abdussalam Baryun To: Eliot Lear Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexandru Petrescu , its@ietf.org Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:59:37 -0000 Hi Eliot, Thank you for your message which I got to understand more details of the not-approval reasons, my comments/questions below, On 6/25/13, Eliot Lear wrote: > Hi AB, > > The guidelines for successful BoFs can be found in RFC-5434[1]. > Alexandru has done a very good job at getting things going. Just > because the IESG passed on this BoF at this next meeting doesn't mean > the work is unimportant. My impression is otherwise, but it's not *yet* > crisply enough defined. I agree that Alex has done a great job. I and many thought that the work was ready, and I want to defend my position if you allow me to. > > On 6/25/13 10:19 AM, Abdussalam Baryun wrote: >> Could I know what was the respond, or if there is a reference I can >> collect it? I want full respond not only summary? Sometimes I think we >> should close this WG if the IESG is not allowing it to continue :-( >> > The BoF proposed to tackle three rather distinct issues: Why you see them as distinct? they are related to transport networks within the Internet system domains. > > # establishment of IP networking between neighboring vehicles using either > MANET protocols or 1-hop ICMP protocol, > # layering of IPv6 over IEEE 802.11p communication technology and > # IPv6-based network-layer distribution of content in a geographic area > > In the latter case, we have work going on relating to emergency alerts > in the ATOCA working group, and we don't yet understand the overlap. Why you relate it to emergency only, but the overlap can be better understood when the both groups work in parallel? Why we choose the methodology of stop this group until we understand? > In > the case of 802.11p, the exact problem to be addressed to get IPv6 > running on it isn't clear and therefore whether it should be addressed > in IEEE 802.11 or by us is also not clear. IMHO, no one can say to the Internet-community what is SHOULD be done and what SHOULD not be done, but we can say to the community *you may have a request from another organisation would you like to accept it or not*. This list involves the Internet-Community seeking WG acceptance. IMHO, any work that involves IPv6 SHOULD be addresses by the Internet-community in IETF not in IEEE802, and any work that involves internet-vehicle-communications is better in ITS. > In the case of v2v > communications, here we need to understand a bit more why existing > protocol suites aren't sufficient. Existing protocols are not application specific, they still are very general, the ITS is more with a clear application. I think our proposal was clear about that. > > But above and beyond all of this there should be some confidence that > the results will be accepted by the industry. We know they play heavily > in ISO TC-207. See [1] for a series of standards that are either > adopted or in progress. ETSI is also in this space. Will the > manufacturers adopt our work as well? Some additional activity on this > list might prove convincing. I realy don't care much of what other OSDs are doing but think that they are doing a better job than IETF in this ITS area/market. The manufactures will adopt work when groups become officialy accepted not before I think. Does IETF wait for manufactures to be succesful or does the community requirement drive more? > > And then there is the fact that the IETF is limited in the number of > BoFs we can support. IMHO, limitation never can be an excuse for not approvals, the IETF can approve with limits due to thoes limitations. > > This space is both interesting and important. I agree, > If we can get to a point > that we can see that there will be adoption, and that the goals are > achievable in a reasonable period of time, then I would expect a WG to > be formed. Thanks that is encouraging for progress, > Vancouver offers an additional opportunity for a formal > BoF. In the meantime, take advantage of Berlin to meet, discuss, and > figure these questions out, and zero down to specific actionable areas. I have no objection, > > I will be available for any and all of these discussions. Thanks AB > > Eliot > > [1] http://tools.ietf.org/html/rfc5434 > [2] > http://www.iso.org/iso/home/store/catalogue_tc/catalogue_tc_browse.htm?commid=54706&published=on&development=on > > From abdussalambaryun@gmail.com Wed Jun 26 06:08:11 2013 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 74AE811E81BB for ; Wed, 26 Jun 2013 06:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGt4-fTiBK8x for ; Wed, 26 Jun 2013 06:08:11 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EFF6A11E81A3 for ; Wed, 26 Jun 2013 06:08:10 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so14162832pbb.20 for ; Wed, 26 Jun 2013 06:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y8jk04600acUIRIqn2SWKUw+ecXgrzcai7dEqtYwESw=; b=ZGKn6WC/bq7bf5oY5EORp3EFCMsw96sTxf/8DfiUz0+lcd/+j8JmSf04I/V+n35v1U PxaZv3umGN0n7G/1j2wK0qmhtxH1NNyvGcw+QsVv5gcMruHVu6BjYBoMjP23h+TLkRcN yq3iQWcrCFdBMto2YoJZRJ4uCRcXwXKkr//OjjyBgg2UGJW6FAv0MF+elcMqQt9D+AVd 3PaEF3utpCjEagOjJrwLqDUETiyTxD46MZSjXFfPQrf5v0z8qk/1fosMcaOA5nag/CZ2 dKkw8VFAOREmvRqIwJrEixj3E24/bt9HfRVVRcdZcERhmXB3cqq9cQLSRRx6nAL4iPRA IJdg== MIME-Version: 1.0 X-Received: by 10.68.175.33 with SMTP id bx1mr583263pbc.21.1372252090734; Wed, 26 Jun 2013 06:08:10 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Wed, 26 Jun 2013 06:08:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Jun 2013 15:08:10 +0200 Message-ID: From: Abdussalam Baryun To: "Ivancic, William D. (GRC-RHN0)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:08:11 -0000 On 6/25/13, Ivancic, William D. (GRC-RHN0) wrote: > While I agree that most work in ITS appears to be coming from Europe, > concentrating on a Europe only solution would probably not be a way to get > IESG approval of a working group. > I don't want also Europe only solution, but the IETF have to understand the needs of the Internet community all over the world, we should not wait. We SHOULD act before others will do a better job and we are still waiting. IESG approval decision seems to FOLLOW the REQUEST of manufactures/industry, but they don't say which industry or which manufacture. My focus on Europe is because I FOLLOW the request of community+industry+region, not only industry/manufacture. AB From abdussalambaryun@gmail.com Wed Jun 26 06:11:36 2013 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 3D2D021F9F40 for ; Wed, 26 Jun 2013 06:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbyaPpK5ql4e for ; Wed, 26 Jun 2013 06:11:35 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 986C621F9F02 for ; Wed, 26 Jun 2013 06:11:35 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id lj1so14169041pab.31 for ; Wed, 26 Jun 2013 06:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LCAyBeBKk55lyKGoYusFNsFCcQa0vevLLti+fuWPL0U=; b=ats9KNzf0bUmf0IDAo18MWDstjhTVvgsOXc0z7IdAhdb29kS7WdkO0jdt5Eb5KUWrZ T4dIL7tRyRwvCMUdrcnEWJCRtu5U9Ix2uqf4nrjoxouX1mFdLtB+FA3MEYkc8VG7nMbp fNyybUnpuZgTRNKiDeRcQv8XjTZEyiUUqzlHNWJXnMmV3JbOavpgSP9xfbJkKKqq4gHI 0y/+LpChYOvAPUiQfNTvu2bd0Zkz/kfihDX7myS2es8HGXCO2YZP9vAIg1z9fU0XqFXP 8vIgunybbZKLjgDD/OjipDcxGOQ8EIhIbgFk64cf8EFb3K9O/XR7vGlH5ZGC+nS8YQVr ZTJw== MIME-Version: 1.0 X-Received: by 10.66.221.101 with SMTP id qd5mr587996pac.174.1372252295339; Wed, 26 Jun 2013 06:11:35 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Wed, 26 Jun 2013 06:11:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Jun 2013 15:11:35 +0200 Message-ID: From: Abdussalam Baryun To: "Ivancic, William D. (GRC-RHN0)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:11:36 -0000 Hi Will, You need to tell us what you mean, or give an example of a better charter. I don't think you can just say we need more specific without telling your input. there was an input charter that the participants in the list accepted and now it was not approved, so what is your suggestion, please provide with edits to the charter, or some information. Thanking you, AB On 6/25/13, Ivancic, William D. (GRC-RHN0) wrote: > I know there is a draft charter that was let to the mailing list, but it is > fairly general. To me, it indicates there are lots of potential areas to > work and we need to figure out what to do. I don't disagree, but a good > charter that would lead to a working group probably needs to be more > focused > indicated the specific problem that needs to be address and why along with > an approach. > > I think we need a well articulated problem statement. > > -- Will > > > >> From: "Ivancic, William D. (GRC-RHN0)" >> Date: Tue, 25 Jun 2013 07:39:26 -0500 >> To: Abdussalam Baryun , Alexandru Petrescu >> >> Cc: "its@ietf.org" >> Subject: Re: [its] Not approved BoF ITS Berlin >> >> Alex, >> >> This ITS group is currently just a mailing list. It is not a Working >> Group. >> >> In order to become a working group, we need a concise, bounded piece of >> work >> related to the use of internet technologies and protocols (either >> existing, >> something that needs development) that needs to be done and sufficient >> interest and energy to accomplish the work. >> >> IMHO, this has yet to be well articulated and probably the reason why >> IESG >> has not granted a BOF. You want a successful BOF with the outcome of a >> charter on what problem a working group would work to solve as well as a >> rough schedule. IMHO, an unsuccessful BOF is death to forming any >> working >> group. Rarely is a second BOF held. So, the suggestion of a Bar BOF is >> actually a way to get the group to focus the problem space and do their >> homework in the hope that it will lead to a successful IETF sanctioned >> BOF. >> >> While I agree that most work in ITS appears to be coming from Europe, >> concentrating on a Europe only solution would probably not be a way to >> get >> IESG approval of a working group. >> >> The bottom line is that we need to draft a working group charter >> indicating >> what problem or problems need to be solved with Internet technologies. >> To >> go into a BOF, you would probably want a Charter and a Problem Statement >> Draft - even for a bar BOF. This will form the basis for focused >> discussion. >> >> That being said, I am just an observer at this point. I am currently >> working Space Suit technology, but see similarities with general ITS - >> not >> just Internet related. Note, the technical term for space suit is >> Extra-vehicular Mobile Unit (EMU). It is really a self contained >> mini-spacecraft with critical life-support, communications, and >> informatics. >> These map closely to ITS critical controls, on-board and wide area >> communications and entertainment systems. >> >> >> -- Will Ivancic >> >>> From: Abdussalam Baryun >>> Date: Tue, 25 Jun 2013 03:19:20 -0500 >>> To: Alexandru Petrescu >>> Cc: "its@ietf.org" >>> Subject: Re: [its] Not approved BoF ITS Berlin >>> >>> Could I know what was the respond, or if there is a reference I can >>> collect it? I want full respond not only summary? Sometimes I think we >>> should close this WG if the IESG is not allowing it to continue :-( >>> >>> AB >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > From abdussalambaryun@gmail.com Wed Jun 26 06:19:30 2013 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 2D21721E8122 for ; Wed, 26 Jun 2013 06:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1wGzJijWIj6 for ; Wed, 26 Jun 2013 06:19:29 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2631921E811D for ; Wed, 26 Jun 2013 06:19:29 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so14185535pab.13 for ; Wed, 26 Jun 2013 06:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tDCXx9QHtpCQV4GDZVLaqDasHf8I9805B/8Cpuo97LU=; b=GOSNkWGEqTSG/PNFVSf2OTrMfwrrzpBBsVtVyw9kHGkyQE50F0uCCFmI71V+8BzBwS Gd6eHW9wvrPoLtSOaJrrZV26P0nFXX8YWs49syBMCK2MgyRfa7/44QLykgtkQZs2+CZS Ob/sIlc4GfIiP29+pA0pw09TDQ4xdlWVX4YG4rpV038yy71Px+j+99CHixD0JMKEukHv 0WoHe/DzdQLk4VfeC3QAtAoPxk67qcavacFcTbSL2lRwlmFxXzKC2/c1Ga5dQkPsbA4A XnE7T41GpPxFqzzSanDQtrvKDvUhJwudpOO1VOY9RGXhOKNmgZpLcfnlNBANU2kpSUWb G1yg== MIME-Version: 1.0 X-Received: by 10.66.221.101 with SMTP id qd5mr624314pac.174.1372252768279; Wed, 26 Jun 2013 06:19:28 -0700 (PDT) Received: by 10.68.78.164 with HTTP; Wed, 26 Jun 2013 06:19:28 -0700 (PDT) In-Reply-To: <51C993A0.3070008@gmail.com> References: <51C993A0.3070008@gmail.com> Date: Wed, 26 Jun 2013 15:19:28 +0200 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "its@ietf.org" Subject: Re: [its] Not approved BoF ITS Berlin X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:19:30 -0000 Hi Alex, I choose to delete 1, and leave 2 and 3 (we may discuss more on these two). However, trying to make what is most important to ITS. AB On 6/25/13, Alexandru Petrescu wrote: > I agree we need to articulate a Problem Statement draft and a draft > Charter for Berlin, focused on one work area. > > For the EMU unit, which of these areas would be more helpful? > > 1. establishment of IP networking between neighboring vehicles using > either MANET protocols or 1-hop ICMP protocol, > > 2. layering of IPv6 over IEEE 802.11p communication technology > > 3. IPv6-based network-layer distribution of content in a geographic area > > Alex > > Le 25/06/2013 14:49, Ivancic, William D. (GRC-RHN0) a =E9crit : >> I know there is a draft charter that was let to the mailing list, but >> it is fairly general. To me, it indicates there are lots of potential >> areas to work and we need to figure out what to do. I don't >> disagree, but a good charter that would lead to a working group >> probably needs to be more focused indicated the specific problem that >> needs to be address and why along with an approach. >> >> I think we need a well articulated problem statement. >> >> -- Will >> >> >> >>> From: "Ivancic, William D. (GRC-RHN0)" >>> Date: Tue, 25 Jun 2013 07:39:26 -0500 >>> To: Abdussalam Baryun , Alexandru >>> Petrescu Cc: "its@ietf.org" >>> Subject: Re: [its] Not approved BoF ITS Berlin >>> >>> Alex, >>> >>> This ITS group is currently just a mailing list. It is not a >>> Working Group. >>> >>> In order to become a working group, we need a concise, bounded >>> piece of work related to the use of internet technologies and >>> protocols (either existing, something that needs development) that >>> needs to be done and sufficient interest and energy to accomplish >>> the work. >>> >>> IMHO, this has yet to be well articulated and probably the reason >>> why IESG has not granted a BOF. You want a successful BOF with the >>> outcome of a charter on what problem a working group would work to >>> solve as well as a rough schedule. IMHO, an unsuccessful BOF is >>> death to forming any working group. Rarely is a second BOF held. >>> So, the suggestion of a Bar BOF is actually a way to get the group >>> to focus the problem space and do their homework in the hope that >>> it will lead to a successful IETF sanctioned BOF. >>> >>> While I agree that most work in ITS appears to be coming from >>> Europe, concentrating on a Europe only solution would probably not >>> be a way to get IESG approval of a working group. >>> >>> The bottom line is that we need to draft a working group charter >>> indicating what problem or problems need to be solved with Internet >>> technologies. To go into a BOF, you would probably want a Charter >>> and a Problem Statement Draft - even for a bar BOF. This will form >>> the basis for focused discussion. >>> >>> That being said, I am just an observer at this point. I am >>> currently working Space Suit technology, but see similarities with >>> general ITS - not just Internet related. Note, the technical term >>> for space suit is Extra-vehicular Mobile Unit (EMU). It is really >>> a self contained mini-spacecraft with critical life-support, >>> communications, and informatics. These map closely to ITS critical >>> controls, on-board and wide area communications and entertainment >>> systems. >>> >>> >>> -- Will Ivancic >>> >>>> From: Abdussalam Baryun Date: Tue, >>>> 25 Jun 2013 03:19:20 -0500 To: Alexandru Petrescu >>>> Cc: "its@ietf.org" >>>> Subject: Re: [its] Not approved BoF ITS Berlin >>>> >>>> Could I know what was the respond, or if there is a reference I >>>> can collect it? I want full respond not only summary? Sometimes I >>>> think we should close this WG if the IESG is not allowing it to >>>> continue :-( >>>> >>>> AB >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> > > > From john@moring.net Wed Jun 26 09:04:52 2013 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 0A8BA21E8092 for ; Wed, 26 Jun 2013 09:04:52 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3bP0VFXIm7i for ; Wed, 26 Jun 2013 09:04:47 -0700 (PDT) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8D33F21E80AB for ; Wed, 26 Jun 2013 09:04:47 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r5QG4jQ9005237 for ; Wed, 26 Jun 2013 12:04:45 -0400 Received: (qmail 17630 invoked by uid 0); 26 Jun 2013 16:04:45 -0000 X-TCPREMOTEIP: 75.80.25.247 X-Authenticated-UID: john@moring.net Received: from unknown (HELO MoringBlackDell) (john@moring.net@75.80.25.247) by 0 with ESMTPA; 26 Jun 2013 16:04:43 -0000 From: "John Moring" To: References: <1372025267.7392.41.camel@localhost> <1372042346.7392.89.camel@localhost> In-Reply-To: <1372042346.7392.89.camel@localhost> Date: Wed, 26 Jun 2013 09:04:45 -0700 Message-ID: <6E092C29FF5A4F129AD30BC1DAB0312B@MoringBlackDell> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac5whgyfuM8768rzRTiY7/l3dOl0DgAl2PdQ X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 16:04:52 -0000 Rex asked: >Strip off the uses for the moment; quick handwaving technical. LTE and >802.11 are: > - both routable networks. > - more or less RF equivalent: both use OFDM. Note that 1609 has what >appears to be yet another layer 1/2 protocol (John Moring???)? The IEEE 1609 WAVE (Wireless Access in Vehicular Environments) standards assume operation over 802.11 (and specifically the mode of operation "outside the context of a basic service set," as originally specified in 802.11p). They are intended specifically for the 5.8GHz channels allocated by the US FCC but could be used in other bands. Unlike their ISO and ETSI counterparts, their scope is limited to 802.11 MAC/PHY; they do not cover other media such as LTE. 1609 does not touch the 802.11 PHY. IEEE Std 1609.4-2010 "WAVE Multi-channel Operation" adds some layer 2 features to 802.11, and mandates other 802.11 features such as EDCA. The primary added feature is a mechanism for alternating between the control channel (CCH) and a service channel (SCH) using one 802.11 radio. The use case that prompted this - safety info and advertisements on the CCH, another application running on an SCH, each getting half the time resources - is no longer expected to be as important, since safety is now using one full channel as described earlier by John Kenney. To the best of my knowledge, the 802.11 PHY used in the US (WAVE/DSRC) and Europe (G5) are interoperable. I would not agree that LTE and 802.11 are "more or less RF equivalent" but I am not here as an LTE expert. The advantage of the 802.11 media over wide area technologies is its low latency, important for vehicle-to-vehicle safety applications. Regards, John Moring -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg Sent: Sunday, June 23, 2013 7:52 PM To: Alison Chaiken Cc: its@ietf.org Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration disentangling... On Sun, 2013-06-23 at 18:53 -0700, Alison Chaiken wrote: > I write: > >> Clearly a "siren indication" is an area where emergency vehicles, > >> whatever method they use to call back to base, may want communicate > >> to passenger vehicles, as well. > > Rex answers: > > Unless I'm misreading something, the private key is associated with > > the siren _sender_. Anyone can receive the message. Further, > > anyone could relay the message because the message itself is not > > changed. And anyone could validate the signature because the public key is, er, public. > Ahh. The above was about data, and definitely not about infrastructure. And I think WSM is indeed about data too. > Sorry, I failed to ask my question, which is: ok, this is a collision -- two silos. Shifting gears: > > If passenger vehicles expect WSM on 802.11p, don't emergency vehicles > then neeed 802.11p to communicate with them, irrespective of LTE plans > for emergency vehicles? The cellphone companies are rolling out LTE infrastructure and it's going in along the highways. (It's being advertised to you as 4g). Who is rolling out 802.11? > Assuredly in the Grand Connected Future we don't expect that > emergency vehicles will communicate with individual drivers via > audible alarms and flashing lights only? The first observation is that both 802.11 and 802.16 (which LTE is a clone of) are routable networks. So if there is dual radio-WAN infrastructures, they will be interoperable. That's the good news. Indeed there's no reason a vehicle's router could not be interfaced to each simultaneously. > And assuredly > having emergency vehicles call out siren messages over LTE to > infrastructure which sends 802.11p would be ridiculous? Adding > 802.11p to emergency vehicles will be expensive, but much less so than > adding LTE to all cars. Even if cars have LTE for (gag) > "infotainment," we can hardly rely on that channel to convey siren > information as well. Strip off the uses for the moment; quick handwaving technical. LTE and 802.11 are: - both routable networks. - more or less RF equivalent: both use OFDM. Note that 1609 has what appears to be yet another layer 1/2 protocol (John Moring???)? The RF range and power figures you can expect are little different than non-protocol range figures that several modeling tools will show. - all use ethernet framing within and pass the ethernet contents up through the layer 2/3 interface, so the integration problems are familiar. Routers know what to do with ethernet frames ... or rather the contents thereof. The difference between the two protocols is in the MAC: - all 802.11 protocols use CSMA of some flavor, derived from 802.3 ethernet. This is a contention-access protocol, albeit with some ifs/ands/buts attached. Contention protocols are comparatively easy to implement but they have three defects in the radio-WAN environment that tend not to show up in the wireless LAN one: o contention protocols are unstable under overload. Too many users, too much to say, the network segment stalls. o the stall point occurs at depressingly low bandwidth efficiency levels. Like around 20% of baseband capacity (depending again on a slew of ifs/ands/buts). o there's no way to manage your way out of this overload situation. There is exactly one MAC message in WiFi: the so-called busy tone that tells would-be SS to wait until someone else is finished (in the labeling, this is the diff between CSMA/CD and CSMA/CA, but it's still CSMA). - 802.16 and LTE have a contention-free protocol borrowed from DOCSIS (!!). It's a TDMA or time-slice arrangement where the base station (BS, what 1609 calls the roadside unit) assigns each user a time slot where only that subscriber station transmits. It's harder to implement (but the problem is solved -- chipsets are readily available) but is o stable under overload o highly bandwidth efficient o can be positively managed. Business. At least in US, the cellphone companies are deploying LTE (Clearwire has ceased expanding its 802.16 deployment because the market herd all started braying LTE). There's a bunch of marketing namecalling, but for all practical purposes '4G' = LTE = 802.16. I've never heard any cellphone company or any DIY emergency service outfit so much as mention 802.11 of any flavor. (The emergency services folks think that they are going to have a separate 800MHz LTE infrastructure. Their reasoning is that they need 'assured access' (which I agree with) and therefore they need a separate freq band (which I do not). This is their conventional wisdom right now; it hasn't met economic reality yet). I agree with your observation, Alison, that two infrastructures is on the ridiculous side. Better to have one and invest in Ao to make it work when the chips are down. None of this has any impact _inside_ the vehicle -- it's only the interface on the radio-WAN side of the router that cares. And there's no reason that the router can't have both interfaces. > > -- > Alison Chaiken alison@she-devel.com > 650-279-5600 http://{she-devel.com, > exerciseforthereader.org} > The intermediary between the head and the hands must be the heart. > -- Thea von Harbou _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Thu Jun 27 06:09:00 2013 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 80E1921F9D67 for ; Thu, 27 Jun 2013 06:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.95 X-Spam-Level: X-Spam-Status: No, score=-8.95 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi7uleDPc0tV for ; Thu, 27 Jun 2013 06:08:45 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id B686721F9D68 for ; Thu, 27 Jun 2013 06:08:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5RD8D3S002074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jun 2013 15:08:13 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5RD8Dmb031520; Thu, 27 Jun 2013 15:08:13 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5RD88rY000919; Thu, 27 Jun 2013 15:08:13 +0200 Message-ID: <51CC3938.2070909@gmail.com> Date: Thu, 27 Jun 2013 15:08:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Richardson References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> In-Reply-To: <28782.1372182848@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Jong-Hyouk Lee , "its@ietf.org" Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:09:00 -0000 Hello Michael, Thank you for the message. Le 25/06/2013 19:54, Michael Richardson a écrit : > > Alexandru Petrescu wrote: > > Hello participants to ITS email list, > > > During recent discussions we mentioned 3 different areas to work on. > > They are too many for a meaningful detail work. > > > Please select area scoping the Charter, prioritizing according to the > > environment you work on. > > > 1. establishment of IP networking between neighboring vehicles using > > either MANET protocols or 1-hop ICMP protocol. > > Do you mean address allocation or routing? I think it depends on what discussion may bring in here, if interest is expressed. I personally think about a concept like in this video, in which vehicles passing each other do IPv6 exchanges: http://youtu.be/RqC0a9bYQCE?t=5m49s E.g. the siren scenario, or the video from the front vehicle allowing driver to see. > > 2. layering of IPv6 over IEEE 802.11p communication technology. > > I am not convinced this isn't a nop. (empty set) > > > 3. IPv6-based network-layer distribution of content in a geographic > > area. > > This interests me the most. *MY* use cases are idiosyncratic and very > anarcho-syndicalist, and as such suffer from "no way to make a buck" problem. > > I think that it does not require, at this point, standardization, as I am not > convinced the parties who want/need to do this are actually at the IETF table yet. > > I think that a group of funded researchers could prototype such a thing using > existing well defined protocols, and having demostrated such a thing to an > appropriate set of equipment (by this, I mean, "vehicle") vendors. At that > point, a specification would ensue. Well, if interest is expressed in this as well, it could be further framed. The 'geo-' aspect is deeply rooted in vehicular electronics, given the wide availability of GPS data. However, how would that integrate with networking concepts is multi-faceted. Alex > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > -- > Michael Richardson , Sandelman Software Works > > From alexandru.petrescu@gmail.com Thu Jun 27 07:55:48 2013 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 1550121F9D52 for ; Thu, 27 Jun 2013 07:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyt23bPSD+ti for ; Thu, 27 Jun 2013 07:55:20 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACFE21F9D0A for ; Thu, 27 Jun 2013 07:55:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5REtDqH009727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jun 2013 16:55:13 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5REtCiA021587; Thu, 27 Jun 2013 16:55:12 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5REt9e4024056; Thu, 27 Jun 2013 16:55:12 +0200 Message-ID: <51CC524D.4060404@gmail.com> Date: Thu, 27 Jun 2013 16:55:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Michael Richardson , "its@ietf.org" Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:55:48 -0000 Le 26/06/2013 09:40, Romascanu, Dan (Dan) a écrit : > > > > >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Michael Richardson >> >>> 2. layering of IPv6 over IEEE 802.11p communication technology. >> >> I am not convinced this isn't a nop. (empty set) >> > > [[DR]] I was actually asking myself the same question. Did anybody > do an analysis / requirements about what work needs to be done here? > Assuming it's not a nop - is this something specific to its? Or > rather in a broader scope (intarea?) First, I am interested in what do the others think about this topic? I guess I may be the only apparent voice about this topic, but here is how I see the situation. Doing IPv6-over-80211p is relatively straightforward in implementation. There may be some modifications needed to a driver 802.11a to become a 802.11p; these are link-layer driver modifications. There may be some modifications needed in government legislation about the limit of power levels, and interpretation of the relationship between 'IP' and 'safety apps'. E.g. if I am not wrong US has limits like 40dBm whereas EU has 33dBm (imagine a vehicle imported from here there), and both consider IP is not about safety but rather entertainment. There may be modifications to ICMP needed such that the movement detection procedure of Mobile IPv6 works ok on a non-BSSID channel (the 802.11p has no BSSID, hence no subnet structure). Currently this doesnt work because the UMIP software gets random behaviour when hearing two different prefixes on the same link (they are supposed to be 2 different links). To address this there are several directions of solutions possible: (1) use 'geo-' concepts, e.g. by GPS know you're closer to that RSU than the other, so trigger Mobile IP movement detection procedure accordingly, (2) have RSU RAs enhanced with non 'geo-' relationships such to overcome the limits of GPS non working in tunnels, (3) others yet to imagine. An Internet-Draft about IPv6-over-802.11p-without-mobility could be very simple: just state IP over 80211p works fine is already a huge step forward from the current informal statements that IP is prohibited on 80211p. These modifications may not impact at all the IP stack software, or just a little bit. In this sense, this indeed may be an activity that requires little work specific to vehicular communications, but which may relate to intarea, to 6man WG, and to Mobile IPv6 protocol. This is my biased opinion, Alex > > Regards, > > Dan > > From fjros@um.es Thu Jun 27 08:34:01 2013 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 C3B1921F9DB8 for ; Thu, 27 Jun 2013 08:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeJa-aVbbDZy for ; Thu, 27 Jun 2013 08:33:56 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id C1F6E11E80E8 for ; Thu, 27 Jun 2013 08:20:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id BC6385D51A; Thu, 27 Jun 2013 17:20:22 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1SB+xTi02UjN; Thu, 27 Jun 2013 17:20:22 +0200 (CEST) Received: from [192.168.1.3] (79.109.154.183.dyn.user.ono.com [79.109.154.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon14.um.es (Postfix) with ESMTPSA id AFBD95D4A2; Thu, 27 Jun 2013 17:20:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-1-1049703882 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <51CC524D.4060404@gmail.com> Date: Thu, 27 Jun 2013 17:20:11 +0200 Message-Id: <1E2E8F27-5524-4B63-9DBB-DC265DF4C6BE@um.es> References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1085) Cc: "Romascanu, Dan \(Dan\)" , "its@ietf.org" , Michael Richardson Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:34:01 -0000 --Apple-Mail-1-1049703882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Alex, El 27/06/2013, a las 16:55, Alexandru Petrescu escribi=F3: > There may be modifications to ICMP needed such that the movement > detection procedure of Mobile IPv6 works ok on a non-BSSID channel = (the > 802.11p has no BSSID, hence no subnet structure). Currently this = doesnt > work because the UMIP software gets random behaviour when hearing two > different prefixes on the same link (they are supposed to be 2 = different > links). This seems to be an implementation issue in uMIP, and not an = 802.11p-specific problem. RFC 3775 warns us about such situation: o There might be multiple routers on the same link, thus hearing a new router does not necessarily constitute an L3 handover. o When there are multiple routers on the same link they might advertise different prefixes. Thus even hearing a new router with a new prefix might not be a reliable indication of an L3 handover. Best, fran -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ --Apple-Mail-1-1049703882 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Alex,

    El 27/06/2013, a las 16:55, Alexandru Petrescu = escribi=F3:
    <snip>
    There may be = modifications to ICMP needed such that the movement
    detection = procedure of Mobile IPv6 works ok on a non-BSSID channel (the
    802.11p = has no BSSID, hence no subnet structure).  Currently this = doesnt
    work because the UMIP software gets random behaviour when = hearing two
    different prefixes on the same link (they are supposed to = be 2 different
    links).

    This = seems to be an implementation issue in uMIP, and not an 802.11p-specific = problem. RFC 3775 warns us about such situation:
    o  There might =
be multiple routers on the same link, thus hearing a
      new router does not necessarily constitute an L3 handover.

o  When there are multiple routers on the same link they might
      advertise different prefixes.  Thus even hearing a new router with
      a new prefix might not be a reliable indication of an L3 =
handover.
    Best,
    fran
    --
    Francisco J. Ros, = PhD
    Dept. of Information and Communications = Engineering
    University of Murcia, Murcia (Spain)




    = --Apple-Mail-1-1049703882-- From alexandru.petrescu@gmail.com Thu Jun 27 08:55:28 2013 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 A58C021F9E0A for ; Thu, 27 Jun 2013 08:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.35 X-Spam-Level: X-Spam-Status: No, score=-7.35 tagged_above=-999 required=5 tests=[HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIS4BzXqRDY9 for ; Thu, 27 Jun 2013 08:55:23 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 48FC621F9DC6 for ; Thu, 27 Jun 2013 08:55:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r5RFt5Zk002551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jun 2013 17:55:05 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r5RFt5gN008850; Thu, 27 Jun 2013 17:55:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r5RFstxo009058; Thu, 27 Jun 2013 17:55:05 +0200 Message-ID: <51CC604F.4030509@gmail.com> Date: Thu, 27 Jun 2013 17:54:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> <1E2E8F27-5524-4B63-9DBB-DC265DF4C6BE@um.es> In-Reply-To: <1E2E8F27-5524-4B63-9DBB-DC265DF4C6BE@um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Romascanu, Dan \(Dan\)" , "its@ietf.org" , Michael Richardson Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 15:55:28 -0000 Hi Francisco, Le 27/06/2013 17:20, Francisco Javier Ros Muñoz a écrit : > Hi Alex, > > El 27/06/2013, a las 16:55, Alexandru Petrescu escribió: >> There may be modifications to ICMP needed such that the movement >> detection procedure of Mobile IPv6 works ok on a non-BSSID channel >> (the 802.11p has no BSSID, hence no subnet structure). Currently >> this doesnt work because the UMIP software gets random behaviour >> when hearing two different prefixes on the same link (they are >> supposed to be 2 different links). > > This seems to be an implementation issue in uMIP, Has one seen this issue solved somehow? How can I get Mobile IPv6 handovers between two different 802.11p Access Points? What do you think? This may only be an implementation issue. Maybe largely identified within uMIP code. But it may be that this gets redirected to one other kind of issue: source-selection, multiple source address, multiple Care-of Address. It may be that uMIP people say that's a much larger issue than just Mobile IP, which uMIP excells at. > and not an 802.11p-specific problem. I tend to agree, it is largely a problem with multiple prefixes on the same link, not necessarily 802.11p. However, one may note that among all 802 wireless links the .11p is the only one which has no structure naturally leading to a subnet (no 'broadcast domain', no ESSID, no messages to create/delete such link, or to associate to one). This is so in purpose, of course, to realize very fast exchanges - avoid the need to first Associate to a network, and all 3 subsequent messages. > RFC 3775 warns us about such situation: > > o There might be multiple routers on the same link, thus hearing a > new router does not necessarily constitute an L3 handover. Right, and in that case there should exist a logic for a Host to choose between these links, and to determine whether a handover is really present or not. This logic has been implemented under various forms by various people. None is standard. There is also DNA. > o When there are multiple routers on the same link they might > advertise different prefixes. Thus even hearing a new router with a > new prefix might not be a reliable indication of an L3 handover. That is right. RFC3775 warns about that situation. However, in a 802.11p deployment of RSUs (Road Side Unit), there are few constants: - there are no multiple prefixes on the same link. - each prefix is actually belonging to one particular RSU, and that particular RSU is in a different subnet. - hearing a different prefix means a different subnet. - there are no two same prefixes on the same subnet. The link-layer problem is that there is no link, one can't distinguish it. I suppose that this is also a reason why ETSI and earlier came up with GeoNetworking, because GPS data can help disambiguate (although it does not work when there is no GPS data). Alex > > Best, fran -- Francisco J. Ros, PhD Dept. of Information and > Communications Engineering University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ > > > > From buddenbergr@gmail.com Thu Jun 27 10:07:42 2013 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 B699121F997B for ; Thu, 27 Jun 2013 10:07:42 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3VN59IRQu8e for ; Thu, 27 Jun 2013 10:07:42 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 524D921F8AD5 for ; Thu, 27 Jun 2013 10:07:40 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so1307809pab.25 for ; Thu, 27 Jun 2013 10:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=An/mpPMIXkPpZ0vJeDZvNsZlAU+DnUuxl8sF2QIO1+4=; b=eaFI0HH4Z9BPTzrw6jHf1ctgHcxfUIerZqTZHQ79Yv+CJUu2pxK65IyR5/YSuM0lOc SNWpbECQl3w6to6f0kLIJDcu4c8LgqgKk5Tzf0wPmtKvJJBVjjHEVwa5Trf5lmh35HL7 MUzq+FTNDLoJG1mqAgNDB0XamgCzsCPsEDvl1k27CIZVjW2uVeLkuCbNLfl8/gQEeraa A19ykEJ8Bke1uC/gBRfF4NfWodOKK6ziymUw9y7WGP0O3fQwU2hXfDF7VSfjv52G3fqk Zju8QOoz2UOhVSXcXhsB0rlSCHuvhToQYSjVYuBotUFWriFryLOOD6yMKZr9WElQuFDB ClRw== X-Received: by 10.68.197.199 with SMTP id iw7mr7084241pbc.110.1372352851791; Thu, 27 Jun 2013 10:07:31 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id eq5sm3973872pbc.15.2013.06.27.10.07.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Jun 2013 10:07:30 -0700 (PDT) Message-ID: <1372352848.1665.88.camel@localhost> From: Rex Buddenberg To: Alexandru Petrescu Date: Thu, 27 Jun 2013 10:07:28 -0700 In-Reply-To: <51CC524D.4060404@gmail.com> References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "Romascanu, Dan \(Dan\)" , "its@ietf.org" , Michael Richardson Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:07:42 -0000 On Thu, 2013-06-27 at 16:55 +0200, Alexandru Petrescu wrote: > and both consider IP is not about safety but rather entertainment. ??? This makes no sense. IP is about a set of communications protocols. 'safety' usually implies some high availability requirements. There are three principles of high availability engineering: - elimination of single points of failure. In comms systems this usually boils down to altroutes and backup power. Provisioning issue, has nothing to do with choices of technology ('IP' or non-IP). - reliable crossover. In redundant systems the crossover switch itself can become a single point of failure. And this is where IP shines: routers do reliable crossover all day every day. I don't know of any other comms technology that solves this problem by protocol design or solves it as elegantly. - detection of failures as they occur. The function of a management system, particularly fault management. SNMP is designed to do exactly this (and a lot more). Meet these principles for the most demanding applications (remember that 'IP' is application-agnostic) and you have a super-solution for everything else. From jonghyouk@gmail.com Thu Jun 27 19:05:25 2013 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 4FFB811E8145 for ; Thu, 27 Jun 2013 19:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kUQFxebiBxJ for ; Thu, 27 Jun 2013 19:05:24 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2936B21F9DE3 for ; Thu, 27 Jun 2013 19:05:24 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so1284873vbe.5 for ; Thu, 27 Jun 2013 19:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pao69ZfH9oWj6lj6Clao+6jHyxGGWk46RGoVVFH6Y34=; b=APJEPP6QAR6E/qeMj5hqgqvNokIQaxxD/8gJpheWIMS14/WTfZS4SlmOp0POUTXGaa 4J46WedJycmNv6WPL6/ksKYY0/dZvcuJbTFsB72TMJJfxjpqp0c7WZ3F7YN/Q4CvpTUT dABxmEsdBjP/N7ro+kFR4K+ktUUiZPQGNPE/MUec+NlRFLwbisSOqrkQnYM786Ti1+xL zEHM5F0Wnk62x4LKjOvR66dQknpEi/rBXKDLOrmkVsQqEfcmfKLasMBzTxLmIp6rxnkT MgnAZQsIt8/edb+yKZu3IRFlprpIAuNCFF4FKUluzR+2BYN2xyiY8izZTEpEbq2a76XE RD1A== MIME-Version: 1.0 X-Received: by 10.220.182.193 with SMTP id cd1mr4688130vcb.32.1372385122495; Thu, 27 Jun 2013 19:05:22 -0700 (PDT) Received: by 10.58.201.66 with HTTP; Thu, 27 Jun 2013 19:05:22 -0700 (PDT) In-Reply-To: <51CC3938.2070909@gmail.com> References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <51CC3938.2070909@gmail.com> Date: Fri, 28 Jun 2013 11:05:22 +0900 Message-ID: From: Jong-Hyouk Lee To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=089e0115f038b8b53d04e02d4f17 Cc: Michael Richardson , Jong-Hyouk Lee , "its@ietf.org" Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 02:05:25 -0000 --089e0115f038b8b53d04e02d4f17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I support to have the topic "establishment of IP networking between neighboring vehicles" that is one of essential requirements. But, I'm willing to extend it. In other words, we should not limit it only to vehicles. So, I suggest to revise the text as: "establishment of IP networking between neighboring nodes including vehicles and infrastrcutures" Cheers. On Thu, Jun 27, 2013 at 10:08 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hello Michael, > > Thank you for the message. > > Le 25/06/2013 19:54, Michael Richardson a =C3=A9crit : > > >> Alexandru Petrescu wrote: >> > Hello participants to ITS email list, >> >> > During recent discussions we mentioned 3 different areas to work >> on. >> > They are too many for a meaningful detail work. >> >> > Please select area scoping the Charter, prioritizing according to >> the >> > environment you work on. >> >> > 1. establishment of IP networking between neighboring vehicles >> using >> > either MANET protocols or 1-hop ICMP protocol. >> >> Do you mean address allocation or routing? >> > > I think it depends on what discussion may bring in here, if interest is > expressed. > > I personally think about a concept like in this video, in which vehicles > passing each other do IPv6 exchanges: > http://youtu.be/RqC0a9bYQCE?t=3D**5m49s > > E.g. the siren scenario, or the video from the front vehicle allowing > driver to see. > > > > 2. layering of IPv6 over IEEE 802.11p communication technology. >> >> I am not convinced this isn't a nop. (empty set) >> >> > 3. IPv6-based network-layer distribution of content in a geograph= ic >> > area. >> >> This interests me the most. *MY* use cases are idiosyncratic and very >> anarcho-syndicalist, and as such suffer from "no way to make a buck" >> problem. >> >> I think that it does not require, at this point, standardization, as I a= m >> not >> convinced the parties who want/need to do this are actually at the IETF >> table yet. >> >> I think that a group of funded researchers could prototype such a thing >> using >> existing well defined protocols, and having demostrated such a thing to = an >> appropriate set of equipment (by this, I mean, "vehicle") vendors. At >> that >> point, a specification would ensue. >> > > Well, if interest is expressed in this as well, it could be further frame= d. > > The 'geo-' aspect is deeply rooted in vehicular electronics, given the > wide availability of GPS data. However, how would that integrate with > networking concepts is multi-faceted. > > Alex > > > > >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on >> rails [ >> >> >> >> -- >> Michael Richardson , Sandelman Software Works >> >> >> > > ______________________________**_________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/**listinfo/its > --=20 RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --089e0115f038b8b53d04e02d4f17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi all,

    I support to have the top= ic "establishment of IP networking between neighboring vehicles" = that is one of essential requirements. But, I'm willing to extend it. I= n other words, we should not limit it only to vehicles. So, I suggest to re= vise the text as:

    "establishment of IP networking betwee= n neighboring nodes including vehicles and infrastrcutures"

    Cheers.=C2=A0



    On Thu, Jun 27, 2013 at 10:08 PM, Alexan= dru Petrescu <alexandru.petrescu@gmail.com> wrote= :
    Hello Michael,

    Thank you for the message.

    Le 25/06/2013 19:54, Michael Richardson a =C3=A9crit :

    Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
    =C2=A0 =C2=A0 =C2=A0> Hello participants to ITS email list,

    =C2=A0 =C2=A0 =C2=A0> During recent discussions we mentioned 3 different= areas to work on.
    =C2=A0 =C2=A0 =C2=A0> They are too many for a meaningful detail work.
    =C2=A0 =C2=A0 =C2=A0> Please select area scoping the Charter, prioritizi= ng according to the
    =C2=A0 =C2=A0 =C2=A0> environment you work on.

    =C2=A0 =C2=A0 =C2=A0> 1. establishment of IP networking between neighbor= ing vehicles using
    =C2=A0 =C2=A0 =C2=A0> either MANET protocols or 1-hop ICMP protocol.

    Do you mean address allocation or routing?

    I think it depends on what discussion may bring in here, if interest is exp= ressed.

    I personally think about a concept like in this video, in which vehicles pa= ssing each other do IPv6 exchanges:
    http://= youtu.be/RqC0a9bYQCE?t=3D5m49s

    E.g. the siren scenario, or the video from the front vehicle allowing drive= r to see.


    =C2=A0 =C2=A0 =C2=A0> 2. layering of IPv6 over IEEE 802.11p communicatio= n technology.

    I am not convinced this isn't a nop. (empty set)

    =C2=A0 =C2=A0 =C2=A0> 3. IPv6-based network-layer distribution of conten= t in a geographic
    =C2=A0 =C2=A0 =C2=A0> area.

    This interests me the most. *MY* use cases are idiosyncratic and very
    anarcho-syndicalist, and as such suffer from "no way to make a buck&qu= ot; problem.

    I think that it does not require, at this point, standardization, as I am n= ot
    convinced the parties who want/need to do this are actually at the IETF tab= le yet.

    I think that a group of funded researchers could prototype such a thing usi= ng
    existing well defined protocols, and having demostrated such a thing to an<= br> appropriate set of equipment (by this, I mean, "vehicle") vendors= . =C2=A0At that
    point, a specification would ensue.

    Well, if interest is expressed in this as well, it could be further framed.=

    The 'geo-' aspect is deeply rooted in vehicular electronics, given = the wide availability of GPS data. =C2=A0However, how would that integrate = with networking concepts is multi-faceted.

    Alex




    --
    ] =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Never tell me the odds! = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | ipv6 mesh network= s [
    ] =C2=A0 Michael Richardson, Sandelman Software Works =C2=A0 =C2=A0 =C2=A0 = =C2=A0| network architect =C2=A0[
    ] =C2=A0 =C2=A0 mcr@s= andelman.ca =C2=A0http://www.sandelman.ca/ =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 ruby on = rails =C2=A0 =C2=A0[



    --
    Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works




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



    --
    =
    RSM Department, TELECOM Bretagne, France
    Jong-Hyouk Lee, liv= ing somewhere between /dev/null and /dev/random

    #email:=C2=A0jonghyouk (at) gmail (dot) com
    --089e0115f038b8b53d04e02d4f17-- From r.kuntz@gmail.com Fri Jun 28 00:51:50 2013 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 B88D721F9ECC for ; Fri, 28 Jun 2013 00:51:49 -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=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSTeOCph0WE7 for ; Fri, 28 Jun 2013 00:51:29 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5B621F9CF1 for ; Fri, 28 Jun 2013 00:51:21 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so435317wiw.11 for ; Fri, 28 Jun 2013 00:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wcV12p4yPoDE8ep69Z9Uc+2NiZwEt+Sev+qJ0//HOzg=; b=vfdXLK+3tCRKAOLOKUsIAVYEuuQmbBMJ0r8HcYYCnnv6NmHJXfXGsAHTxK13HwO/ct A2vW/tcb5xtR23IUmEKTs5SJ7w7N3V8bMRLuFzAAZlJU3xgW2h9lZzuk5dAeJJ/8ETeY azVLUo/hkrIfs3WmksXDBdhDc8rwoqCitGmOEdSOOZoxpZ/+/2xZhwCDwT/N+JgGXe6Q 3fa7+ziJuMNcKq5Fj6wwcG0N9cpdwhUhv/LDwICQ140VdeAfudauv0fDgAo82iGpqmjr zIibnXAYir3KbEX2RgyDYQZzaY7mw0TTYtof5Kc0TznJuy+RT5smhpVchqat/5c8c37w GWIA== X-Received: by 10.180.108.129 with SMTP id hk1mr1501367wib.42.1372405881237; Fri, 28 Jun 2013 00:51:21 -0700 (PDT) Received: from [192.168.0.14] (81-64-76-117.rev.numericable.fr. [81.64.76.117]) by mx.google.com with ESMTPSA id fb9sm22123158wid.2.2013.06.28.00.51.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 00:51:20 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Romain KUNTZ In-Reply-To: <51CC604F.4030509@gmail.com> Date: Fri, 28 Jun 2013 09:51:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <526FF3FE-751D-4082-B069-768EF7CB5EAE@gmail.com> References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> <1E2E8F27-5524-4B63-9DBB-DC265DF4C6BE@um.es> <51CC604F.4030509@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1508) Cc: Michael Richardson , "Romascanu, Dan \(Dan\)" , "its@ietf.org" , =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 07:51:50 -0000 Hello, On Jun 27, 2013, at 17:54 , Alexandru Petrescu = wrote: > Hi Francisco, >=20 > Le 27/06/2013 17:20, Francisco Javier Ros Mu=F1oz a =E9crit : >> Hi Alex, >>=20 >> El 27/06/2013, a las 16:55, Alexandru Petrescu escribi=F3: >>> There may be modifications to ICMP needed such that the movement >>> detection procedure of Mobile IPv6 works ok on a non-BSSID channel >>> (the 802.11p has no BSSID, hence no subnet structure). Currently >>> this doesnt work because the UMIP software gets random behaviour >>> when hearing two different prefixes on the same link (they are >>> supposed to be 2 different links). >>=20 >> This seems to be an implementation issue in uMIP, >=20 > Has one seen this issue solved somehow? How can I get Mobile IPv6 > handovers between two different 802.11p Access Points? This problem can be solved using the "MnRouterProbes" and = "MnRouterProbeTimeout" options of UMIP, which makes UMIP avoiding = switching to another router if the current one is still reachable. This = behaviour is disabled by default. More below (from the UMIP manpage): MnRouterProbes " "number" ";" Indicates how many times the MN should send Neighbor Unreachability Detection (NUD) probes to its old router after receiving a Router Advertisement (RA) from a new one. If the option is set to zero or the new router advertises a strictly higher default preference value than the old one (as defined in RFC 4191), the MN will move to the new router straight away. =20 Default: 0 =20 =20 "MnRouterProbeTimeout " "decimal" ";" =20 Indicates how long (in seconds) the MN should wait for a reply during a access router Neighbor Unreachability Detection probe. If set, it overrides any default Neighbor Solicitation Retransmit Timer value greater than MnRouterProbeTimeout. For example, if the interface Retransmit Timer is 1 second, but MnRouterProbeTimeout is just 0.2 seconds, the MN will only wait 0.2 seconds for a Neighbor Advertisement before proceeding with the handoff. Default: 0.0 > What do you think? >=20 > This may only be an implementation issue. Maybe largely identified > within uMIP code. But it may be that this gets redirected to one = other > kind of issue: source-selection, multiple source address, multiple > Care-of Address. It may be that uMIP people say that's a much > larger issue than just Mobile IP, which uMIP excells at. >=20 >> and not an 802.11p-specific problem. >=20 > I tend to agree, it is largely a problem with multiple prefixes on the > same link, not necessarily 802.11p. >=20 > However, one may note that among all 802 wireless links the .11p is = the > only one which has no structure naturally leading to a subnet (no > 'broadcast domain', no ESSID, no messages to create/delete such link, = or > to associate to one). This is so in purpose, of course, to realize = very > fast exchanges - avoid the need to first Associate to a network, and = all > 3 subsequent messages. >=20 >> RFC 3775 warns us about such situation: >>=20 >> o There might be multiple routers on the same link, thus hearing a >> new router does not necessarily constitute an L3 handover. >=20 > Right, and in that case there should exist a logic for a Host to = choose > between these links, and to determine whether a handover is really > present or not. >=20 > This logic has been implemented under various forms by various people. > None is standard. I think this can be solved by performing NUD (which is standard) as UMIP = does. Best, Romain Kuntz (UMIP maintainer) > There is also DNA. >=20 >> o When there are multiple routers on the same link they might >> advertise different prefixes. Thus even hearing a new router with a >> new prefix might not be a reliable indication of an L3 handover. >=20 > That is right. RFC3775 warns about that situation. >=20 > However, in a 802.11p deployment of RSUs (Road Side Unit), there are = few > constants: > - there are no multiple prefixes on the same link. > - each prefix is actually belonging to one particular RSU, and that > particular RSU is in a different subnet. > - hearing a different prefix means a different subnet. > - there are no two same prefixes on the same subnet. >=20 > The link-layer problem is that there is no link, one can't distinguish = it. >=20 > I suppose that this is also a reason why ETSI and earlier came up with > GeoNetworking, because GPS data can help disambiguate (although it = does > not work when there is no GPS data). >=20 > Alex >=20 >>=20 >> Best, fran -- Francisco J. Ros, PhD Dept. of Information and >> Communications Engineering University of Murcia, Murcia (Spain) >> http://masimum.inf.um.es/fjrm/ >>=20 >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From william.d.ivancic@nasa.gov Fri Jun 28 06:08:00 2013 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 682B721F938E for ; Fri, 28 Jun 2013 06:08:00 -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=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UvdXP4aQqze for ; Fri, 28 Jun 2013 06:07:55 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8E221F99F6 for ; Fri, 28 Jun 2013 06:07:55 -0700 (PDT) Received: from ndjsppt102.ndc.nasa.gov (NDJSPPT102.ndc.nasa.gov [198.117.1.196]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 5A8522D808B; Fri, 28 Jun 2013 08:07:54 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt102.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r5SD7s5g001315; Fri, 28 Jun 2013 08:07:54 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Fri, 28 Jun 2013 08:07:54 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Jong-Hyouk Lee , Alexandru Petrescu Date: Fri, 28 Jun 2013 08:07:53 -0500 Thread-Topic: [its] Please select area scoping the Charter Thread-Index: Ac5zo/ad615PJxenSZySdaHp1CJ8PwAXIj9g Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CDF302E9FA6Fwilliamdivancicnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-28_06:2013-06-28, 2013-06-28, 1970-01-01 signatures=0 Cc: Michael Richardson , Jong-Hyouk Lee , "its@ietf.org" Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 13:08:00 -0000 --_000_CDF302E9FA6Fwilliamdivancicnasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree. One bit of advices / history lesson. After the tcpsat working grou= p, I believe there was a lot of reluctance to establish working groups at I= ETF to solve particular industry specific problems. I certainly agree as g= enerally problems that initially may appear to be industry specific actuall= y occur in many places. For example in tcpsat the initial problem was how t= o get TCP to work better over long delays. But, in reality, the problem is= (delay x bandwidth) and is certainly not unique to satellite communication= s. I guess the point I am trying to make is to think beyond ITS when looking = at the problem space so that any solutions are more general. -- Will ________________________________ From: Jong-Hyouk Lee Date: Thu, 27 Jun 2013 21:05:22 -0500 To: Alexandru Petrescu Cc: Michael Richardson , Jong-Hyouk Lee , "its@ietf.org" Subject: Re: [its] Please select area scoping the Charter Hi all, I support to have the topic "establishment of IP networking between neighbo= ring vehicles" that is one of essential requirements. But, I'm willing to e= xtend it. In other words, we should not limit it only to vehicles. So, I su= ggest to revise the text as: "establishment of IP networking between neighboring nodes including vehicle= s and infrastrcutures" --_000_CDF302E9FA6Fwilliamdivancicnasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [its] Please select area scoping the Charter Agree.  On= e bit of advices / history lesson.  After the tcpsat working group, I = believe there was a lot of reluctance to establish working groups at IETF t= o solve particular industry specific problems.  I certainly agree as g= enerally problems that initially may appear to be industry specific actuall= y occur in many places. For example in tcpsat the initial problem was how t= o get TCP to work better over long delays.  But, in reality, the probl= em is (delay x bandwidth) and is certainly not unique to satellite communic= ations.

    I guess the point I am trying to make is to  think beyond ITS when loo= king at the problem space so that any solutions are more general.

    -- Will




    From: Jong-Hyouk Lee <= ;jonghyouk@gmail.com>
    Date: Thu, 27 Jun 2013 21:05:22 -0500
    To: Alexandru Petrescu <= alexandru.petrescu@gmail.com>
    Cc: Michael Richardson <mcr+iet= f@sandelman.ca>, Jong-Hyouk Lee <hu= rryon@gmail.com>, "its@ietf.org&qu= ot; <its@ietf.org>
    Subject: Re: [its] Please select area scoping the Charter

    Hi all,

    I support to have the topic "establishment of IP networking between ne= ighboring vehicles" that is one of essential requirements. But, I'm wi= lling to extend it. In other words, we should not limit it only to vehicles= . So, I suggest to revise the text as:

    "establishment of IP networking between neighboring nodes including ve= hicles and infrastrcutures"



     --_000_CDF302E9FA6Fwilliamdivancicnasagov_-- From alison@she-devel.com Sat Jun 29 12:55:52 2013 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 2FC6C21F9F90 for ; Sat, 29 Jun 2013 12:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7uPjXRJCGI6 for ; Sat, 29 Jun 2013 12:55:47 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id C666521F9F69 for ; Sat, 29 Jun 2013 12:55:46 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id fe20so3140792lab.6 for ; Sat, 29 Jun 2013 12:55:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=IN+3LRGcSpv3KXjzxM2aSh+25azqpg8mxSAYxszVE3E=; b=ldCeJ4MgWkqG/sfcF3xICGnAd0JuDLliY5HmdoF4zOL0gySdPxtFvBtjAK9ioxKI9/ d5k81jtxVUrV5NOQG/VWEeTL61Y+soURUZoTYQ4529133m2UH9qYAQhkVPoTTpTZxk+4 ccELxJKBu5yOaGNBNGtzojOIgAZ+o5SbOPVNM3fnpG2YU3rDHK22icLnF7y9VcPm6nhw nLc0psyUlZxg2PoEHXAzr0c/F35BFbviWE017y/p58H7kQ3dV1/NXLukN6Ms6xKEfdsZ fPIdfrH0+YrVXRdmXjYj5glj5nQNeMULIdmfXsAN67IzBs8sZV1VYLzafgxNW+B0xZlb +iIA== MIME-Version: 1.0 X-Received: by 10.152.19.194 with SMTP id h2mr9009889lae.26.1372535744421; Sat, 29 Jun 2013 12:55:44 -0700 (PDT) Received: by 10.112.201.194 with HTTP; Sat, 29 Jun 2013 12:55:43 -0700 (PDT) Received: by 10.112.201.194 with HTTP; Sat, 29 Jun 2013 12:55:43 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Jun 2013 12:55:43 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: multipart/alternative; boundary=089e013d0f127cf19804e0506176 X-Gm-Message-State: ALoCoQkxXoYrWWmhX/njIlJ1yvMAiNeQPIkFQ+hxKOXG9GPI4MME3qoB+WRPdNVquQcxJCseiWiS Subject: [its] Geo-networking and WiFi positioning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 19:55:52 -0000 --089e013d0f127cf19804e0506176 Content-Type: text/plain; charset=ISO-8859-1 Regarding loss of GPS signal in tunnels and cities, why not use WiFi Positioning? Couldn't a vehicle know its position by triangulating among different RSUs? Couldn't the last 32 or 64 positions be cached? What problem is temporary loss of GPS connectivity going to cause that we are trying to solve, anyway? Consider my car parked inside my garage overnight. Assuredly I should be able to communicate with a router in my house securely. Does geo-networking apply here? Should I have a second radio in the car that talks in the 2.4 GHz band with a different 802.11 protocol for this purpose? The other fascinating topic is over-the-air updates of vehicle software. These have security concerns more akin to emergency vehicles than to (gag) infotainment. I assume current vendors (Red bend) and OEMs (Tesla) are using 3G right now for this purpose. On Thursday night I attended a panel discussion with Mercedes, QNX (leading car software vendor), Pandora music service, and Gartner. They talked about LTE and satellite communications, not 802.11p. XM and Sirius are planning to expand their business models to include non-broadcast data streams, apparently. GM has announced that it plans to offer LTE across its whole fleet. Does 802.11p stand a chance? Are we certain it will extend beyond simTD and SafetyPilot trials? Happy weekend, Alison --089e013d0f127cf19804e0506176 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    Regarding loss of GPS signal in tunnels and cities, why not = use WiFi Positioning?=A0 Couldn't a vehicle know its position by triang= ulating among different RSUs?=A0 Couldn't the last 32 or 64 positions b= e cached?=A0 What problem is temporary loss of GPS connectivity going to ca= use that we are trying to solve, anyway?

    Consider my car parked inside my garage overnight.=A0=A0 Ass= uredly I should be able to communicate with a router in my house securely.= =A0=A0 Does geo-networking=A0 apply here?=A0=A0 Should I have a second radi= o in the car that talks in the 2.4 GHz band with a different 802.11 protoco= l for this purpose?

    The other fascinating topic is over-the-air updates of vehic= le software.=A0 These have security concerns more akin to emergency vehicle= s than to (gag) infotainment.=A0=A0 I assume current vendors (Red bend) and= OEMs (Tesla) are using 3G right now for this purpose.

    On Thursday night I attended a panel discussion with Mercede= s, QNX (leading car software vendor), Pandora music service, and Gartner.= =A0=A0 They talked about LTE and satellite communications, not 802.11p.=A0= =A0 XM and Sirius are planning to expand their business models to include n= on-broadcast data streams, apparently.=A0=A0 GM has announced that it plans= to offer LTE across its whole fleet.=A0=A0 Does 802.11p stand a chance?=A0= Are we certain it will extend beyond simTD and SafetyPilot trials?

    Happy weekend,
    Alison

    --089e013d0f127cf19804e0506176-- From buddenbergr@gmail.com Sat Jun 29 14:59:38 2013 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 D56BC21F9C6C for ; Sat, 29 Jun 2013 14:59:38 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKTPxRpsIgi3 for ; Sat, 29 Jun 2013 14:59:38 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id EA7D321F9C59 for ; Sat, 29 Jun 2013 14:59:37 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so3455190pbc.7 for ; Sat, 29 Jun 2013 14:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=AvTtrIDWpqfeIn6ghux3ghyheQqMFAep95rbMPlnfIc=; b=JKfGXeSzwHfl7cgPD4pq5Dlr2lAIRRGQ3SXcbkgw3cjNRCuI6zYdaOsY5t3DVkQ9Yz DZd8V46GWXCXH1lXGMkB+VViiWTz6LwYZ5AdtKSjaLCrfoboiuwK3yMxA9Euzi2IpJCC 7QL46lY2qMPO2jKjMkHdv8A649ZAXxcwp1z49J7WAWyW9uDPTV7OaE1Mzzp22aQfbpTZ t0fWueM/vPvd4VLiVKiw8tA8U49Hfm4JmUWl7ISoTi8c4lY9V0HyAX8y3cFKMiePF+Uv E2Vt7DWrj2Pikm2Tli60tVrUZeU9BleYNTLDJi7VdK7pWEIMpHoccEG8mwNER5CKF61G +wMA== X-Received: by 10.68.250.5 with SMTP id yy5mr17440526pbc.93.1372543177674; Sat, 29 Jun 2013 14:59:37 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id kc8sm14453891pbc.18.2013.06.29.14.59.36 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 29 Jun 2013 14:59:36 -0700 (PDT) Message-ID: <1372543175.1665.165.camel@localhost> From: Rex Buddenberg To: Alison Chaiken Date: Sat, 29 Jun 2013 14:59:35 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] Geo-networking and WiFi positioning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 21:59:39 -0000 On Sat, 2013-06-29 at 12:55 -0700, Alison Chaiken wrote: > Regarding loss of GPS signal in tunnels and cities, why not use WiFi > Positioning? See GNSS Today a couple years ago for an article. http://www.insidegnss.com/node/1916 (Google will reveal several other articles/citations) The problem has to do with the asynchronous (bursty) transmission of WiFi emissions. In a tunnel, you're likely to have the same problems with WiFi shading as with GPS shading. > Couldn't a vehicle know its position by triangulating among different > RSUs? Couldn't the last 32 or 64 positions be cached? What problem > is temporary loss of GPS connectivity going to cause that we are > trying to solve, anyway? Ah, better question to ask. Commercial aircraft are fitted with inertial systems that provide a 'flywheel' for radionav system gaps. And inertial systems found initial use on submarines that we didn't want to require to surface to get a nav fix. For years, the inertial systems on submarines are good enough that they need not reset for an entire patrol. Loran C was initially deployed for the SSBN submarine fleet. One of the advantages was that the 100kHz signal could be received while submerged (trailing wire antenna). Indeed, while I was on the Loran desk in CGHQ, got mail from some cavecrawlers in Indiana who used Loran to map caves. ... dragging a receiver and antenna into the cave with them. Loran, as a complement to GPS is not at all far-fetched. The North Koreans jammed GPS earlier this year; prompting the South Koreans to announce a rebuild of their Loran system: http://www.insidegnss.com/node/3532 GPS suffers from several availability shortcomings, shading being an obvious one. Loran also suffers availability shortcomings, but there are no common-cause failures between the two systems. > > Consider my car parked inside my garage overnight. Assuredly I > should be able to communicate with a router in my house securely. Well if it's an electric car, you'd be plugging it in wouldn't you? Hook up the ethernet cord at the same time... > Does geo-networking apply here? Should I have a second radio in > the car that talks in the 2.4 GHz band with a different 802.11 > protocol for this purpose? One of the things I've learned over the years is to not do with radio what you can do with wired internet. That experience, IMHO, applies here. > > The other fascinating topic is over-the-air updates of vehicle > software. These have security concerns more akin to emergency > vehicles than to (gag) infotainment. I assume current vendors (Red > bend) and OEMs (Tesla) are using 3G right now for this purpose. Downloads are a classical case where at least the Linux community has got it right: the authenticity is associated with the data and entirely independent of the infrastructure. Even my cellphone provider has that part right! > > On Thursday night I attended a panel discussion with Mercedes, QNX > (leading car software vendor), Pandora music service, and Gartner. > They talked about LTE and satellite communications, not 802.11p. XM > and Sirius are planning to expand their business models to include > non-broadcast data streams, apparently. GM has announced that it > plans to offer LTE across its whole fleet. Does 802.11p stand a > chance? Are we certain it will extend beyond simTD and SafetyPilot > trials? If you live (or drive) in Wyoming, neither LTE nor 802.11 of any flavor are likely to be ubiquitous. It's territory that we describe as miles and miles of nothing but miles and miles. Did these companies talk about what happens after the radio? If they're not talking about a router (which can have multiple WAN ports, after all) and an in-platform LAN on the backside of the router, then they haven't gotten the modularization model and systems thinking on board yet. Whether '802.11p stand a chance' depends on an entirely different business model, which is not mutually exclusive to the LTE one. After all, my cellphone has interfaces for both. WiFi has tended to be an unofficial infrastructure at the fringe of the internet. If you stroll around the neighborhood and pick up access points, they're all owned by my neighbors, not any phone company or highway company. By contrast, all the 3G and 4G base stations around here are corporately owned. > > Happy weekend, > Alison > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its