Re: [ipwave] Datatracker State Update Notice: <draft-ietf-ipwave-vehicular-networking-19.txt>

Erik Kline <ek.ietf@gmail.com> Mon, 14 June 2021 00:44 UTC

Return-Path: <ek.ietf@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD28E3A176E for <its@ietfa.amsl.com>; Sun, 13 Jun 2021 17:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn9_gzomc54w for <its@ietfa.amsl.com>; Sun, 13 Jun 2021 17:44:51 -0700 (PDT)
Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3703A176B for <its@ietf.org>; Sun, 13 Jun 2021 17:44:51 -0700 (PDT)
Received: by mail-oo1-xc2d.google.com with SMTP id s20-20020a4ae9940000b02902072d5df239so2269615ood.2 for <its@ietf.org>; Sun, 13 Jun 2021 17:44:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=27RUdZrLjx+xEdm4dgcl2b2T77FjEwAacqViJjxlhC8=; b=SomNwkKxdIcG46g0EIicUsxYzMDGwVcvC7GJ74HulBjeC9FYQ1QVetN8+IWIbxB5/J xWGlgxcvOfhLXTfHlJNYEuXTHQrQCZizAZz8Mb4YL1RyMc8N1x7Z4Xz5U+Gv+Gbs8w3q dn2SJwsgwjvopTMwVoJ74btLcuFAB+FDfx1m20XUd3N+STbOpTzxoII1a8+3uwaeqIcO G9ljMGKbba6rg596dCSBUIWTNga1im1npM1mab7eI7ltCvUYrq5DUM9yGnIF/OsxPvJb uqF1/qg+lWYSoc7lejjbUNThNPEfYGiayFUJIeA0yeL/B58Qy3PgFehqNiUpjchZ1DPV zCMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=27RUdZrLjx+xEdm4dgcl2b2T77FjEwAacqViJjxlhC8=; b=b4Z3+vhNiDOGbd5GX16EQGwW/O60wxSb8yzSSbLd8No2LXKN+wmvz5VBkBOcAUKyZZ K4QpYzRhxEEB6cTyjhQGPCwp0sdMN6QDwBJI3g3TbO22bgVvbuGWqllocB1S18YYxFzS r72QkCSCeM80o8WPvlk7ypjThFK15Gd0lOa8nakKYlU5BejCOIYLlFnu5SOZr/XS4R3F i2LkWhkcd65uyjlRYazjHq1TEH/PRr+MiOkHWm7t/eZlkRC6bWVGsR3HConXiTwiQk/9 JpMqQ6SSGRi56+HZg2bo/+QdGecpq7mptkh3q3Cy76EnUYw3qZI660C0HBhWewijgBdV AhqQ==
X-Gm-Message-State: AOAM530vFHMjUthT26xNTGwP2AcP9y4/eEEJv1buZzRyCXoeomZKkoFJ tk5M7JT9jHlitvL8wdqOdEfdtay67vDdsy3ddfU=
X-Google-Smtp-Source: ABdhPJx0Fpg0TumaX5/BcN3+9uWapSd3yzcYDOgADiY0rSrinBHEMxs5nXiTZ9grHRdcve5qzAu2MKP5ni3iyYM895U=
X-Received: by 2002:a4a:d41a:: with SMTP id n26mr11463036oos.66.1623631490047; Sun, 13 Jun 2021 17:44:50 -0700 (PDT)
MIME-Version: 1.0
References: <161516725619.22797.1003603720092861577@ietfa.amsl.com> <CAPK2Dex+CWArXvidz24F6XG2S+gw+c4uxFfLRDAdJ-NGv2cz8Q@mail.gmail.com> <CAPK2Dey6OW4j_14GTS+kwib_otUsHjfVhoy8FdFK=BX=Fc7+xQ@mail.gmail.com>
In-Reply-To: <CAPK2Dey6OW4j_14GTS+kwib_otUsHjfVhoy8FdFK=BX=Fc7+xQ@mail.gmail.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Sun, 13 Jun 2021 17:44:39 -0700
Message-ID: <CAMGpriV3NB3dxhQ1OvPuF3sj+4j0aWvRxSeQgOQmDH14ThTi0w@mail.gmail.com>
To: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Cc: Carlos Bernardos <cjbc@it.uc3m.es>, Russ Housley <housley@vigilsec.com>, its@ietf.org, skku-iotlab-members <skku-iotlab-members@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/iN1dXrDtXWyPL8QWyJKiNle0uIs>
Subject: Re: [ipwave] Datatracker State Update Notice: <draft-ietf-ipwave-vehicular-networking-19.txt>
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jun 2021 00:44:56 -0000

Paul,

Thanks for this, and my apologies for the delay.  I have requested
IETF LC for draft -20.

Regards,
-Erik

On Thu, Mar 18, 2021 at 6:33 AM Mr. Jaehoon Paul Jeong
<jaehoon.paul@gmail.com> wrote:
>
> Hi Erik,
> There is the revision of IPWAVE PS Draft:
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-20
>
> I attach the revision letter to explain how to address your comments.
>
> Thanks.
>
> Best Regards,
> Paul
>
>
> On Mon, Mar 8, 2021 at 10:33 PM Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
>>
>> Hi Erik,
>> I will address your comments this week.
>>
>> Thanks for your valuable review.
>>
>> Best Regards,
>> Paul
>>
>>
>> On Mon, Mar 8, 2021 at 10:34 AM IETF Secretariat <ietf-secretariat-reply@ietf.org> wrote:
>>>
>>> IESG state changed:
>>>
>>> New State: AD Evaluation::Revised I-D Needed
>>>
>>> (The previous state was AD Evaluation)
>>>
>>> [ abstract, section 1 ]
>>>
>>> * "lists up" -> "enumerates|sets forth|details|...", might be a better
>>>   word/verb phrase
>>>
>>>
>>> [ section 2 ]
>>>
>>> * "table PC"? Perhaps "tablet PC", like in section 6.
>>>
>>> [ section 3 ]
>>>
>>> * There are two sentences in the final paragraph which both direct the reader
>>>   to section 5 for vehicular IPv6 problem statement and requirements.
>>>   Probably only one of those sentences is really required.
>>>
>>> [ section 3.2 ]
>>>
>>> * "can facilitates" -> "can facilitate"
>>>
>>> * "can make the battery charging schedule" is technically correct, but the
>>>   multiple possible interpretations of "make" in this context tripped me up
>>>   looking for some final (indirect) object or something.
>>>
>>>   Suggest something like "can plan the battery charging schedule", perhaps?
>>>
>>> * "The existing IPv6 protocol must be augmented ..."
>>>
>>>   Should there be some explanation about why this needs to be done at the IPv6
>>>   layer and, more explicitly, why a Layer 2 solution is not an option that
>>>   can also be considered?  I can understand that L2 options are out of scope
>>>   for the IETF to work on, but are they also out of scope overall?  I could
>>>   believe that the reason is RFC 4903 -style issues, but I figured I'd ask.
>>>
>>> [ section 4.1 ]
>>>
>>> * "...vehicles under the coverage of an RSU share a prefix such
>>>    that mobile nodes share a prefix..."
>>>
>>>    Perhaps s/such that/(just as)|(in the same way that)/?
>>>
>>> [ section 4.2/5(.0) ]
>>>
>>> * The final paragraph of 4.2 hints at this, but I found myself wanting to read
>>>   about the expected "dwell times" for a vehicle connected to an IP-RSU.
>>>   For how long is a vehicle expected to be connected to any given access node?
>>>   I think the maximum is probably uninteresting (the vehicle could be parked,
>>>   for example), but what is the useful minimum time?
>>>
>>>   (I see that section 5.1.2 goes include a helpful timescale reference.)
>>>
>>> [ section 5.1.1/5.2 ]
>>>
>>> * During handover, can a vehicle be connected to multiple IP-RSUs on the
>>>   logical interface?  If so, does this mean they need to use RFC 8028 -style
>>>   address and next hop selection?
>>>
>>> [ section 6 ]
>>>
>>> * How can a vehicle authenticate other vehicles (and their ND information)
>>>   and the RAs coming from IP-RSUs?
>>>
>>>   Ah, I guess this is what the final two paragraphs are saying, actually, that
>>>   there needs to be such a mechanism.
>>>
>>> Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/
>>>
>>>
>>>
>>>
>>>