Subject: [ipwave] IPWAVE Recharter Topics?

From: Russ Housley <[email-masked]>
Date: Wed, 18 Apr 2018 14:39:15 -0400

I saw very little excitement for rechartering the IPWAVE WG.  There were
a small number of people want to do something, but most people felt that
other standards bodies should tackle non-IP topics.

Are there any IP-related topics that need to be tackled?  If so, is
there enough interest and energy among the IPWAVE WG participants to
tackle them?

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Apr 2018 17:38:13 +0200

I think there are several things on the table:

- QoS OCB-Ethernet,
- ND over OCB,
- XER-CAM/UDP/IP (instead of UPER-CAM/Geonet),
- RA prefix exchanges for V2V,
- 65-SLAAC (instead of 64-SLAAC),
- IPv6-over-802.11-NGV,
- IP Discovery of nearby vehicles,
- Security.

There is also some comment in 6man that deserves consideration with 
respect to ND.

Le 18/04/2018 à 20:39, Russ Housley a écrit :
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Apr 2018 17:59:09 +0200

For the XER-CAM/UDP/IP/Ethernet topic we have an interoperable 
implementation with a partner; that implementation couples to 
UPER-CAM/Geonet and soon will couple to XER-CAM/UDP/IP/LTE and 
potentially to XER-CAM/UDP/IP/OCB.

We need to reserve a UDP port number for it, as now we just do it 
between 'consenting adults' 52000 decimal.

Should we request it to IANA, or just continue between 'consenting 
adults' for the duration of the project trial prototype.

Or maybe just wait a few months to have more confirmation.

For those who wonder what is 'XER' it is an encoding rule specified by 
ITU, in a same family like 'UPER'.  XER is like XML human readable and 
UPER is Unaligned Packed Encoding Rules which is more compressed.  UPER 
is preferred by CAM but makes little sense to humans; worse - UPER-CAM 
is ambiguously specified from a purely formal standpoint.  ITU and 
others would like one day to join JSON into these encoding rules, maybe 
as a XER derivative.

We now have a recipe about how to make CAMs and DENMs for almost free 
(no money) that I could publish easily, although I will not publish 
code.  That recipe relies entirely on the gratuituous open source 
software called asn1c, on freely accessible grammars from 
asn1-playground and marben websites.  We tested on several platforms of 
different endianness (endianness is important for embedded and for 
UPER).  We applied the recipe from one partner to another and it worked.

A few things that still are in the way towards making cheap 
interoperable stack for ITS are:
- various licensing conditions on geonet and a few other ITS-related
   ETSI messages still risk knocking at the door asking.
- price tag of the SPAT grammar at SAE (in the order of hundred(s)
   dollars).

Alex

---

From: [email-masked]
Date: Thu, 19 Apr 2018 09:22:00 -0700

> On Apr 19, 2018, at 8:59 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> We need to reserve a UDP port number for it, as now we just do it between 'consenting adults' 52000 decimal.
> 
> Should we request it to IANA, or just continue between 'consenting adults' for the duration of the project trial prototype.

Before you ask IANA for a UDP port number, you’ll need an Internet draft that describes the protocol running on top of it.

From what you’ve said, this is unlikely to be in the Internet area and more likely in Applications.  Thus, a different WG...

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Apr 2018 19:08:52 +0200

:-)

We're in Europe it must be GeoNetworking :-)  Or I must redirect 1000 
people to you :-)

Alex

Le 19/04/2018 à 18:45, Dick Roy a écrit :
> The use of GeoNotworking or IP to send broadcast single-hop CAMs, DENMs,
> BSMs, etc. is a total waste of resources.  GeoNotworking is the absolute
> worst possible choice, followed closely by IP.  There is not a system
> engineer worth his weight in salt that would specify such nonsense.  Why are
> you guys proposing to do something so ridiculous?
> 
> RR
> 
> -----Original Message-----
> From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, April 19, 2018 8:59 AM
> To: [email-masked]
> Subject: Re: [ipwave] IPWAVE Recharter Topics?
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Apr 2018 19:09:24 +0200

XER on 5G at 4Gbps yes

XER on 802.11 NGV at 1GBps yes

Le 19/04/2018 à 18:47, Dick Roy a écrit :
> XER for broadcasting CAMs on a resource constrained channel??? Are you
> seriously considering such a thing?
> 
> RR
> 
> Sent: Thursday, April 19, 2018 8:38 AM
> To: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Apr 2018 19:10:12 +0200

Le 19/04/2018 à 18:59, Dick Roy a écrit :
> Alex et. al.,
> 
> The only thing SAE charges for is the document, not the code.  You can code
> the SPaT message yourself for free assuming you have the ASN.1 for the
> message.

The ASN.1 grammar of SPAT is not available elsewhere than on that SAE 
paywall.

Alex

> 
> As for GeoNotworking and the patents thereon, ABSOLUTELY DO NOT use that
> networking protocol ... EVER ... for anything.  It is useless and
> encumbered.  Instead, work to get any mention of that dysfunctional protocol
> removed from ALL your RFCs, and more importantly, from every mandate issued
> by the EC!  Anyone who thinks paying royalties for something that simply
> does not work and NEVER WILL has serious problems.  Allowing the companies
> that foisted this travesty on the ITS community to get away with this
> blatant abuse of the standards process is nothing sort of complicity!
> 
> Cheers,
> 
> RR
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 Apr 2018 09:53:31 +0200

Dick,

I tend to agree that the use of GeoNotWorking to send broadcast 
single-hop CAMs, DENMs is a waste of resources.  In particular, it has 
the overhead of sending two times the position value (once in the 
GeoNotWorking header and once in the CAM payload - both are mandatory).

The licensing risk is that whoever implements the GeoNotWorking header 
risks a few companies to knock at their door to ask for rights, be they 
'reasonable'.

On another hand, the GeoNotWorking is such a mandatory protocol in 
Europe at ETSI and, consequently by the uniformisation process at each 
country level.  So many people implement it - be it functional or just 
pretending to function.  This is what I meant by the '1000 person' metaphor.

Given this situation, we locally have decided to also implement the 
GeoNotWorking header.  But we set the values in this header to 0.  This 
is non-functional too, just like GeoNotWorking is.  The receivers of 
these CAM/GeoNotWorking that we send dont complain and are happy.  The 
receivers care a lot about what is in the CAM payload.

We also implement IPv6-over-OCB without the GeoNotWorking header and 
that is useful for connecting the car to the Internet.

Alex

Le 19/04/2018 à 19:08, Alexandre Petrescu a écrit :
[...]

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Fri, 20 Apr 2018 10:02:52 +0200

Well, everybody understands the problem with GeoNetworking. GN was a 
nice scientific exercise, but it failed in the very narrow channels at 
5,9 GHz. There is an easy migration possibel from GN to both WSMP (IEEE 
1609.3) and FNTP (ISO 29281-1:2018). WSMP and FNTP are efficiently 
structured, using the same message format, and thus are interoperable.

Remote SW update in ITS stations can do the job. Some hints on remote 
station management are given in ISO 24102-2:2018.

My two cents.
Hans-Joachim

Am 20.04.2018 um 09:53 schrieb Alexandre Petrescu:
> risks a few companies to knock at their door to ask for rights, be 
> they 'reasonable'.
>
> GeoNotWorking header.  But we set the values in this header to 0.  
> This is non-functional too, just like GeoNotWorking is.  The receivers 
> of these CAM/GeoNotWorking that we send dont complain and are happy.  
> The receivers care a lot about what is in the CAM payload.
>

-- 
Dr. Hans-Joachim Fischer
Managing Director

--------------------------------------------------------------------------------

                ESF News edition 2018/1
https://fischer-tech.eu/Feeds/News/ESF-News-2018-01.pdf

--------------------------------------------------------------------------------
       Towards deployment of C-ITS based on proven technology
Avoid risks and delay by looking on potential future technologies.

                The real advocate on ITS is ISO TC204!
--------------------------------------------------------------------------------
+ + + Instaurare omnia in Christo + + +
--------------------------------------------------------------------------------
The information contained in this message is confidential and may be legally
privileged. This email is intended for the addressee(s). Addressees may be
individual persons or members of mailing list.
If you are not an addressee, you are hereby notified that any use,
dissemination, or reproduction of this email and its optional attachements is
strictly prohibited and may be unlawful. If you are not an addressee, please
contact the sender by return e-mail and destroy all copies of the original
message.
--------------------------------------------------------------------------------
ESF GmbH
Fichtenweg 9
89143 Blaubeuren
+49 (7344) 175340 (Direct line Dr. Fischer)
+49 (7344) 919188 (Central office)
+49 (7344) 919123 (Fax)
https://fischer-tech.eu :  Main web of ESF GmbH
http://its-standards.eu : News on cooperative ITS standardization
http://its-testing.org :  International consultancy for cooperative ITS
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
ESF online-news:        http://fischer-tech.eu/Feeds/esf.rss
C-ITS online news:      http://its-standards.info/Feeds/cits.rss
ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss
-------------------------------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 Apr 2018 10:17:21 +0200

Dick,

Let me detail a bit about this.

Le 19/04/2018 à 18:59, Dick Roy a écrit :
> Alex et. al.,
> 
> The only thing SAE charges for is the document, not the code.  You 
> can code the SPaT message yourself for free assuming you have the 
> ASN.1 for the message.

The document that SAE charges for is a grammar (ASN.1).  That grammar
feeds the reader called asn1c, an open-source freely available tool.
That asn1c generates the C code; this code has no license.  That C code
is further compiled to generate an executable that will create a SPAT
message according to the grammar.

Without the grammar it is impossible to generate a SPAT.

Sure, it could be possible for a human to read the SPAT spec and write
the ASN.1 grammar.  I believe the SPAT spec is another document that the
SPAT grammar, more human readable and commented hopefully with jokes.  I
believe that SPAT spec is also paying.

However, a human to read the non-grammar SPAT specification is a complex
operation that takes time.  Because the SPAT message format is not as
simple as CAM.  The SPAT message format is complicated because it wants
to express the complicated situation which is an intersection.  The
urban intersections I deal with may have up to 20 traffic lights for one
controller.

So a programmer must not only understand the intersection but understand
the SPAT specification too.  It's absurd to even try.  It's like if
programmer needed to understand Assembler in order to program in Java.

There is an additional detail : SPAT is a US format used in America,
whereas Europe rather says 'SPAT-EM' which is a SPAT encapsulated with a
specific ETSI ITS header (which is itself weakly specified with respect
to time representation).  The SPAT-EM ASN.1 grammar is freely accessible
but it is useless without the SPAT ASN.1 grammar (it says "IMPORT SPAT").

Last but not least: the traffic lights in the country where I live do
have the ability to program the intersection, represent its state, and
so on.  However, that uses a country-specific protocol which is called
'DIASER'.  Originally DIASER was for RS-232 lines, but recently one can
send DIASER messages over IP, and presumably over IPv6.  This 'DIASER'
is not related at all to 'SPAT' yet they do the same thing.  Worse, just
like SPAT, the DIASER spec is paying, and more expensive than the SPAT.

I can guess that Germany has its equivalent for DIASER that may be
called something else.

In this situation, I dont understand why not using any other than SPAT
format to do the intersection management.  Or maybe if SPAT wants to
succeed over DIASER then make the SPAT spec open and put it over IP.

Alex

> 
> As for GeoNotworking and the patents thereon, ABSOLUTELY DO NOT use 
> that networking protocol ... EVER ... for anything.  It is useless 
> and encumbered.  Instead, work to get any mention of that 
> dysfunctional protocol removed from ALL your RFCs, and more 
> importantly, from every mandate issued by the EC!  Anyone who thinks 
> paying royalties for something that simply does not work and NEVER 
> WILL has serious problems.  Allowing the companies that foisted this 
> travesty on the ITS community to get away with this blatant abuse of 
> the standards process is nothing sort of complicity!
> 
> Cheers,
> 
> RR
> 
> -----Original Message----- From: its [mailto:[email-masked]]
> On Behalf Of Alexandre Petrescu Sent: Thursday, April 19, 2018 8:59
> AM To: [email-masked] Subject: Re: [ipwave] IPWAVE Recharter Topics?
> 
> For those who wonder what is 'XER' it is an encoding rule specified 
> by ITU, in a same family like 'UPER'.  XER is like XML human
> readable and UPER is Unaligned Packed Encoding Rules which is more
> compressed. UPER is preferred by CAM but makes little sense to
> humans; worse - UPER-CAM is ambiguously specified from a purely
> formal standpoint. ITU and others would like one day to join JSON
> into these encoding rules, maybe as a XER derivative.
> 
> asn1-playground and marben websites.  We tested on several platforms 
> of different endianness (endianness is important for embedded and for
> interoperable stack for ITS are: - various licensing conditions on 
> geonet and a few other ITS-related ETSI messages still risk knocking 
> at the door asking. - price tag of the SPAT grammar at SAE (in the 
> order of hundred(s) dollars).
> 
> Alex
> 
>> - QoS OCB-Ethernet, - ND over OCB, - XER-CAM/UDP/IP (instead of 
>> UPER-CAM/Geonet), - RA prefix exchanges for V2V, - 65-SLAAC 
>> (instead of 64-SLAAC), - IPv6-over-802.11-NGV, - IP Discovery of 
>> nearby vehicles, - Security.
>> 
>>> I saw very little excitement for rechartering the IPWAVE WG. 
>>> There were a small number of people want to do something, but 
>>> most people felt that other standards bodies should tackle
>>> non-IP topics.
>>> 
>>> Are there any IP-related topics that need to be tackled?  If so, 
>>> is there enough interest and energy among the IPWAVE WG 
>>> participants to tackle them?
>>> 
>>> Russ
>>> 
>>> _______________________________________________ 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
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 20 Apr 2018 13:22:30 +0200

I stand corrected: it is the 'MAP' message that describes the 
intersection, not SPAT.

Alex

Le 20/04/2018 à 10:17, Alexandre Petrescu a écrit :
>> The only thing SAE charges for is the document, not the code.  You can 
>> code the SPaT message yourself for free assuming you have the ASN.1 
>> for the message.
> 
>> that networking protocol ... EVER ... for anything.  It is useless and 
>> encumbered.  Instead, work to get any mention of that dysfunctional 
>> protocol removed from ALL your RFCs, and more importantly, from every 
>> mandate issued by the EC!  Anyone who thinks paying royalties for 
>> something that simply does not work and NEVER WILL has serious 
>> problems.  Allowing the companies that foisted this travesty on the 
>> ITS community to get away with this blatant abuse of the standards 
>> process is nothing sort of complicity!
>>
>> Cheers,
>>
>> RR
>>
>> ITU, in a same family like 'UPER'.  XER is like XML human
>>> UPER-CAM/Geonet), - RA prefix exchanges for V2V, - 65-SLAAC (instead 
>>> of 64-SLAAC), - IPv6-over-802.11-NGV, - IP Discovery of nearby 
>>> vehicles, - Security.
>>>
>>>> I saw very little excitement for rechartering the IPWAVE WG. There 
>>>> were a small number of people want to do something, but most people 
>>>> felt that other standards bodies should tackle
>>>> non-IP topics.
>>>>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 23 Apr 2018 18:38:33 +0900

Hi Russ,
As you know, I am working for the Problem Statement document for next steps.
I think the topics in the content will be next steps for IPWAVE WG.

I will try to have a revised document by May 11, 2018 and share it with
IPWAVE WG.

Thanks.

Best Regards,
Paul
Paul

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Apr 2018 15:32:48 -0400

Paul:

I am trying to summarize the discussion from the end of the WG session in London.  We talked about things that the WG might do next, and this thread gives people that were not there an opportunity to share their view.

Russ

> On Apr 23, 2018, at 5:38 AM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> 
> Hi Russ,
> I will try to have a revised document by May 11, 2018 and share it with IPWAVE WG.
> 
> Thanks.
> 
> Best Regards,
> Paul
> Paul
> 
> On Thu, Apr 19, 2018 at 3:39 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> 
> -- 
> Email: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 24 Apr 2018 00:09:52 +0000

Russ,
I see. :)

If there are important items with certain consensus for our Problem
Statement document from this, I will include them into the revised document.

Thanks.

Best Regards,
Paul

2018년 4월 24일 (화) 오전 4:32, Russ Housley <[email-masked]>님이 작성:

> Paul:
>
> I am trying to summarize the discussion from the end of the WG session in
> London.  We talked about things that the WG might do next, and this thread
> gives people that were not there an opportunity to share their view.
>
> Russ
>
>