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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
