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

"Mr. Jaehoon Paul Jeong" <> Wed, 30 March 2022 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 797923A14F6; Wed, 30 Mar 2022 09:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.087
X-Spam-Status: No, score=-7.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, T_HK_NAME_FM_MR_MRS=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UMkClFTiePSL; Wed, 30 Mar 2022 09:49:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F3163A14FC; Wed, 30 Mar 2022 09:49:56 -0700 (PDT)
Received: by with SMTP id r22so28500335ljd.4; Wed, 30 Mar 2022 09:49:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qlElM/izMI5jLqwuloZOFu+TNQBBDT24faN51Phgvpc=; b=Pt35h2SW61ugf0sE3EjWvMN+EZ5mVtacLZOc3Q8vCcbVEZ0GEw2m77DwX1QADU8UNg i/yxtYltbDXuSv8wLlccT5iEEouEvMAwgaRA7wYmQzUOdEh24cZrm/E7W84P+xWullgM gueQhZ+p0ardJQI+Tu9ay10gmKcweS6SOiKxCn604pjVl00fXu7tAisz2MEtQS2gjeEq CZYjpEtI0rie75I7qESssDeucONS37TlZSDUq+bWDW1YXfLUqJaDIxlepI36Ue1iy0JI ctJTcub6ip+KWqbGBWJVXHJe19WcQV7HqSI2l3uPs444iktwVIpoPQKB2dy4HA5AtrKN UEVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qlElM/izMI5jLqwuloZOFu+TNQBBDT24faN51Phgvpc=; b=5xBwIoBwBePZ4zToB+22ylw9TKWSyWlUElQHngvYauAcosXTDtjn8Zoe1LQlj1moSW x1pMQg/zIFNKK/Y4J04mI5tKccBa6CATh2VgInVafWNc5mCukoyVY5h2pX/YeCRp/TqK JdXpiUWQfTRKg3+fTsE9xPKRUgoj7G9UeSZ8xA+W8QMepgSXA0TnpPdf27RelE8TEXM7 eZ3s+qtDfBJubsAUrYP/2+cO8IklNBRLCM/WtIEQ75x7+mbfHRSxdcFeXXpVsOyk/sSK Mnfvd2fWrMafRfK89nCfAUP/DxcuphBUhZnAMcwy4kQv3AZkvyBd4BI58QgNl1RWHda1 Q1uA==
X-Gm-Message-State: AOAM532886xv8QmDn+OQFfo9sSVWuyWBeiG21gjWQk+vO1A9R3BgXPP6 Bf1I/y5F3PNcjTuUX2Ou60C59jKDC5B8Qf0watI=
X-Google-Smtp-Source: ABdhPJzzwL/+KbZe4kFFu478JV2xaXlS9G/YT+alHUcyViwoWwMy6A4SLFNUe7XgDbHpulIp33A91hAvSq97hPi13yg=
X-Received: by 2002:a2e:bd13:0:b0:246:1ff8:6da1 with SMTP id n19-20020a2ebd13000000b002461ff86da1mr7355111ljq.219.1648658993614; Wed, 30 Mar 2022 09:49:53 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Mr. Jaehoon Paul Jeong" <>
Date: Thu, 31 Mar 2022 01:49:16 +0900
Message-ID: <>
To: Jim Fenton <>
Cc:, Last Call <>,, Chris Shen <>, skku-iotlab-members <>, "Mr. Jaehoon Paul Jeong" <>
Content-Type: multipart/mixed; boundary="000000000000abae5505db725509"
Archived-At: <>
Subject: Re: [ipwave] Artart telechat review of draft-ietf-ipwave-vehicular-networking-27
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2022 16:50:03 -0000

Hi Jim,
Here is the revision of IPWAVE PS Draft:

I attach a revision letter to explain how Chris and I have addressed your
on the revision.


Best Regards,

On Tue, Mar 29, 2022 at 6:52 AM Jim Fenton via Datatracker <>

> 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