Subject: Re: [ipwave] 802.11 Data vs 802.11 QoS Data in IPv6-over-802.11-OCB- interoperability

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 1 Mar 2018 00:19:39 +0200

On Wed, Feb 28, 2018 at 4:08 PM, Alexandre PETRESCU <
[email-masked]> wrote:

>
> --
> Alexandre [email-masked], tél 0169089223
>
>
> Le 28/02/2018 à 14:58, Michelle Wetterwald a écrit :
>
> Hi Alex,
>
> Answers inline.
>
> 2018-02-28 12:22 GMT+01:00 Alexandre PETRESCU <[email-masked]>:
>
>> [trimmed the CC because mailer problems]
>>
>> Le 28/02/2018 à 11:34, Michelle Wetterwald a écrit :
>>
>>> Hi Alex,
>>>
>>> Regarding the interoperability between different implementations, it has
>>> been fully validated during numerous plugtests events in EU and US,
>>> gathering a large set of different implementations. For the EU ones, the
>>> reports are freely available on the ETSI web site.
>>>
>>
>> I am using the wireshark dissectors on the ETSI web site.
>>
>> I can tell they show lack of interoperability: several CAM messages from
>> several stacks are not understood by these wireshark dissectors.
>>
>
> Can you give references to these stacks?
>
>
> github.com 'rendits', 'vanetza', 'driveits', 'geonetworking', 'btpsap'.
>
> None puts a QoSData header, each puts a 'Data' header.
>
> (but none sends CAM as IP messages either).
>

Any implementer uses the easy way to transmit, so future work can develop
it.

>
>
>
>> The ETSI wireshark dissectors have another problem themselves: they are
>> not integrated in the main wireshark software.  It's just ETSI's point of
>> view.
>>
>> I am sorry to hear that the open source implementation that you are using
>>> has some limitations. I remember that one of the participants to the last
>>> PlugTest in Livorno (Nov 2016) explained to me he had extended the open
>>> source software to use his computer to monitor the traffic exchanged on the
>>> 802.11p. So he made his Ath implementation fully interoperable with those
>>> from the other vendors. Maybe you can apply similar upgrades to your
>>> testing implementations?
>>>
>>
>> Can you tell me who is that participant so I can contact?
>>
>
> Sorry, NDA applies here. But the list of vendors is in the report.
>
>
> The reference to the report please?
>
>
>> Again, I disagree with the change you propose in the text of the draft,
>>> as it goes against the *existing* EU regulations. Compliance with the
>>> modified text would prevent vendors from accessing the EU market.
>>>
>>
>> Accessing EU market is a good thing, but customer lock in may not be that
>> good.
>>
>
> This is not customer lock-in, there are several and diverse
> implementations available (BTW, this is more an L2 than an L3-IETF
> related topic), the only thing is that you have to pay for getting them,
> which is often part of the market rules, right?
>
>
> There are software features in limited deployment that deserve a certain
> amount of money.
> But key aspects like running IP are free of charge.
>
> For example, it is worth attaching a price tag for software in a limited
> deployment (e.g. this highway), but IP is much wider scale.  You cant put a
> price tag on it.
>
> Is there a requirement that an RFC can be approved only if several open
> source implementations are available?
>
>
> No, there is no such requirement.
>

There is no requirement, and it can be solved if required, so IMO we should
not ask for it because this draft is only transmission over.

>
> But there is requirement for interoperability.  I can test for
> interoperability because I can use some open-source stacks.
>

The open source software are not standards or they are standards? if not
they may not follow our standards, and if yes they need to follow the use
requirement of ieee802.11-ocb

> For one, they are not interoperable among themselves when it comes to
> QoSData, but _are_ interoperable if they use Data.
>

Why test results are not interoperable for QoS?

AB