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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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]>
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]
> https://www.ietf.org/mailman/listinfo/its
>