Subject: Re: [its] suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-5905MHz

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Apr 2013 13:49:14 +0200

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: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
>> 31 January 2013 15:17 To: [email-masked] 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: [email-masked]
>>>>>>> [mailto:[email-masked]] On Behalf Of Alexandru
>>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To:
>>>>>>> [email-masked] 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:[email-masked]
>>>>>>>> [mailto:[email-masked]] *On Behalf Of *Thierry
>>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM *To:*
>>>>>>>> [email-masked] *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
>>>>>>>> <http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS%2813%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)000020_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-numbers.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
>>>>>>>> <[email-masked]> <mailto:[email-masked]>
>>>>>>>> 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 <[email-masked]>
>>>>>>>> <mailto:[email-masked]> 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 <[email-masked]>
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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 [email-masked] <mailto:[email-masked]>
>>>>>>>> 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 [email-masked] <mailto:[email-masked]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ its
>>>>>>> mailing
>>>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ its
>>>>>>> mailing
>>>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ its
>>>>>>>> mailing
>>>>>>> list
>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>>
>>>>>>>> _______________________________________________ its
>>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ its
>>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ its
>>>>>>>> mailing list [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ its
>>>>>>> mailing list [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>
>>>>>
>>>>> _______________________________________________ its mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>>
>>>>
>>>> _______________________________________________ its mailing list
>>>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>
>>>
>>>
>>> _______________________________________________ its mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>
>>
>>
>> _______________________________________________ its mailing list
>> [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its