[ipwave] Some review comments for draft-ietf-ipwave-vehicular-networking-11

[Charlie Perkins <[e-mail]>]

Hello folks,

I made a review of the document 
draft-ietf-ipwave-vehicular-networking-11.txt.  Besides editorial 
comments, I had some other more substantive comments on the document, as 
follows.

First, I thought that the document should contain an easily identifiable 
problem statement.  Here is some text that I devised for that purpose, 
which could fit naturally at the beginning of Section 5.

    In order to specify protocols using the abovementioned architecture
    for VANETs, IPv6 core protocols have to be adapted to overcome certain
    challenging aspects of vehicular networking.  Since the vehicles are
    likely to be moving at great speed, protocol exchanges need to be
    completed in a time relatively small compared to the lifetime of a
    link between a vehicle and an RSU, or between two vehicles.  This
    has a major impact on IPv6 neighbor discovery. Mobility management
    is also vulnerable to disconnections that occur before the completion
    of identify verification and tunnel management.  This is especially
    true given the unreliable nature of wireless communications.  Finally,
    and perhaps most importantly, proper authorization for vehicular 
protocol
    messages must be assured in order to prevent false reports of accidents
    or other mishaps on the road, which would cause horrific misery in
    modern urban environments.

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

Although geographic routing is mentioned early in the document, it is 
not discussed in later sections.  This makes me wonder whether the early 
mention is really relevant.  In fact, for fast moving objects, I think 
it is already questionable whether geographic routing has value.  For 
the RSUs, it is a lot easier to imagine a good use for geographic 
routing, or perhaps some other use of geographic information to 
establish links between application endpoints.  If geographic algorithms 
are mentioned at all, a lot more development is needed to establish 
relevance to the problem statement.

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

More description is needed for OCB in the Terminology section. It would 
also be a good idea to include definitions for "context-aware" and for 
platooning.

class-based safety plan needs a definition and a list of classes.

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

As a general comment, it seems to me that a proposed architecture is 
usually considered to be part of the solution, not the problem 
statement.  In the case of this document, the architecture is really a 
depiction of IPv6 as it might be normally considered to live in a 
multi-network deployment (e.g., between a lot of cars and RSUs).  But 
anyway some care has to be taken so that the proposed architecture 
doesn't otherwise place strong limits on acceptable solutions.  So, for 
example, in section 4.1, it needs to be clear whether or not a single 
subnet prefix can span multiple vehicles.  This is an important choice.

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

In section 5.1.1., a claim is made that a new link model is required.  I 
think this is a very ambitious claim, and I am not even quite sure what 
is meant.  IPv6 already provides for "on-link" and "off-link" variations 
on subnet operation.  Unless I am missing something here, the claim 
should be made much more clear (or else retracted).

Similarly, the suggestion that VANETs need to be merging and 
partitioning as part of the problem statement seems at least ambitious 
and might present a very high bar that could disqualify otherwise 
suitable solutions.

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

It would be nice to have a citation about why current implementations of 
address pseudonyms are insufficient for the purposes described in 
section 5.1.2.

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

It seems to me that the discussion in section 5.1.3 lives almost 
entirely in solution space.

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

In section 5.1.4, it was not clear to me about why Neighbor Discovery 
really needs to be extended into being a routing protocol.

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

It seems to me that section 5.3 really belongs in section 6. Also, even 
a perfectly authorized and legitimate vehicle might be persuaded somehow 
to run malicious applications.  I think that this point is not 
sufficiently covered in the current text.

Regards,
Charlie P.
Blue Sky Networks