Re: [ipwave] [Last-Call] Artart telechat review of draft-ietf-ipwave-vehicular-networking-27

[Francesca Palombini <[e-mail]>]

Jim: thank you very much for this review. Authors, thank you for addressing Jim’s points. I have balloted No objection.

Francesca

From: last-call <[e-mail]> on behalf of Mr. Jaehoon Paul Jeong <[e-mail]>
Date: Wednesday, 30 March 2022 at 18:51
To: Jim Fenton <[e-mail]>
Cc: Chris Shen <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Last Call <[e-mail]>, skku-iotlab-members <[e-mail]>, Mr. Jaehoon Paul Jeong <[e-mail]>
Subject: Re: [Last-Call] [ipwave] Artart telechat review of draft-ietf-ipwave-vehicular-networking-27
Hi Jim,
Here is the revision of IPWAVE PS Draft:

https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-28
I attach a revision letter to explain how Chris and I have addressed your comments
on the revision.

Thanks.

Best Regards,
Paul


On Tue, Mar 29, 2022 at 6:52 AM Jim Fenton via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Reviewer: Jim Fenton
Review result: Almost Ready

I am the assigned ART reciewer for draft-ietf-ipwave-vehicular-networking-27.
Please note that since I don't have specific background in mobile networking,
these comments tend to be editorial in nature.

2. Terminology

The introduction to this section refers to terminology described in RFC 8691,
but several of the definitions overlap with definitions there but are not quite
the same. Please make it clear which version of the definitions apply here. For
example:

- IP-OBU has the additional phrase, "and a device (e.g., smartphone and
Internet-of-Things (IoT) device." Does this mean that an additional device is
needed in order to have a complete IP-OBU?

- IP-RSU has the additional sentence, "Also, it may have an IP interface unit
that runs in a C-V2X along with an "RSU" transceiver."

Definition of VSP: It appears there is a word missing following "privacy"

The definitions of Edge Computing and Edge Network use the term "for the sake
of". I'm not clear on what that means: perhaps "to be used by" or "to protect"?

Section 3.1, bullet 5: draft-templin-ipwave-uam-its has expired. Generally this
problem statement is not clear on whether Urban Air Mobility is in scope or
not. More comments on this below.

Section 3.1 paragraph 5 on EV charging might also mention notification of
charging stations that are out of service (a problem I have encountered).

Section 4.1 paragraph 3 spends more time talking about RFC 3849 documentation
prefixes than anything particularly relevant here. Suggest removing the example
prefix since it doesn't really add to the discussion.

Section 4.2 paragraph 2 describes connecting user devices to a vehicle's
internal network. This is a dangerous idea; it should at a minimum be a
separate network.

Section 4.2 last paragraph and section 5 paragraph 2 calculate dwell (not
dwelling) time based on a highway maximum speed of 100 km/h. It is not
acceptable to deny service to vehicles exceeding the speed limit, nor to
emergency vehicles that may be legitimately doing so. It also isn't clear how
this might apply to airborne vehicles. Suggest that if the network is designed
around a given maximum speed, that should be at least 250 km/h. It also assumes
that traffic can be passed for the entire dwell time, and does not consider
physical link establishment, authentication, packet loss, and channel
contention from other vehicles.

Section 5 paragraph 1 s/time relatively short/relatively short time/

Section 5.1 last paragraph s/changes with the legacy/changes with respect to
the legacy/

Section 6: Security Considerations

This problem statement has extreme security considerations so I am glad to see
considerable text on this topic. Again, inclusion of driver/passenger's mobile
devices (paragraph 2) introduces yet more (possibly avoidable) security issues
and should perhaps be reconsidered.

One of the primary concerns is the threat to human life. It is essential that
these mechanisms fail safely, and be resilient to both malicious attack and
equipment failure. As an example of the latter, one can imagine a situation
where a cooperating vehicle has a sensor failure (e.g., LIDAR) and reports
incorrect information about surrounding vehicles. If that caused other nearby
vehicles to collide, there would be a rather interesting question of liability
for the collision. While this is not a security concern in the classic sense of
most IETF protocols, it needs to be considered in the design of IPWAVE
technology.

Privacy considerations are mentioned several times; this is a distinct enough
topic to consider the inclusion of a Privacy Considerations section (RFC 6973).
The document does describe the use of ephemeral IP addresses to evade tracking
based on IP address, but also needs to address the need to protect other
mechanisms such as authentication certificates as well. The threat actors for
privacy need to be further considered: the document seems to focus primarily on
the inability of passive attackers to perform tracking, but some users are also
concerned about the ability of the roadway operator (effectively the
government) to track their location as well. I am not sure how this problem
would be solved, but it should be mentioned.

8. References

I'm not sure what constitutes a normative vs. informative reference for a
problem statement such as this. But it does seem odd that all of the normative
references are RFCs and nearly all of the informative references aren't.

With so many references, it would be nice to have them in alphabetical order.
Perhaps the RFC editor will take care of that.



_______________________________________________
its mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/its