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

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Thu, 18 March 2021 13:33 UTC

Return-Path: <jaehoon.paul@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 9932B3A2BBE for <its@ietfa.amsl.com>; Thu, 18 Mar 2021 06:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.588
X-Spam-Level:
X-Spam-Status: No, score=-0.588 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, HK_NAME_FM_MR_MRS=1.499, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 ALiS0Y1mySCI for <its@ietfa.amsl.com>; Thu, 18 Mar 2021 06:33:22 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 9D2E93A2BBD for <its@ietf.org>; Thu, 18 Mar 2021 06:33:21 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id u4so7493629ljo.6 for <its@ietf.org>; Thu, 18 Mar 2021 06:33:21 -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=zOJB1u5/3VGDfwDD0iNkQBmh1rXq0m3Vlwj6nuFqZvc=; b=O7RwX/Hwiov/mNZ6rk2t6DgJaCkdSSuDomcx2P+X4R5DWBrvkApRnfGmcbonOHVZ9w ROZ2dvzwRH77JwqMStLUw5Ffb9YpvrtEnsXY6JhZ3KDlH4A7JEwWOiuYeCfxHEAbwh+/ EVZuGOpJCRVM5Iky6fxnY0Kqjg/uDFYKdlsbjTnRkRkG/2PRxpgbHKPXF3sI8A2dDHsr AatsJu06I4EoFZg60y5nfJL7SADOao67bzVxD/RnN/blvsA09CZrdnzBwh8qryDFzYzc EL8BIEllvtVvKatYs3oyhS3N7z1lSgmAZ9aXeG8dfBbWKdaFMqy32wP/Xhf7gFPApVKK dSLA==
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=zOJB1u5/3VGDfwDD0iNkQBmh1rXq0m3Vlwj6nuFqZvc=; b=ib5bTSVTqYVIoZs9sIjA7wEEuac4/bD4+DnpdhG0z2nK0+eo4OjtVzU+2tZrp7BhQ2 8wAAygSNWvWYEkeP+xgfXQYVwCKkMKjSFYhbOJMk82k/BeWTl3vvKljzI6opuNVabd+A vV7/+j4CG8IzDmGPuY6wjri6PWCGJ8OXU7z1j4G/8W6grClO+s2u2cPZYq1rAtTdF1N8 N80zsG4hqJtXFUKaIm9iFb0dGPK+bGO1rnPHQ4loQH0+aMjhny9a9RU9Sp62E3Byt16Y 5VBryDdEw2+L++XXSRarE+rPCZN3JmF6gtUTYEJFQZnv+i2Zs5nMtIqlH6pWnp00vqpc rfRQ==
X-Gm-Message-State: AOAM533RbtE6LwfYAMCZmLnu4QmWdJh25fXP01+TaTB0jUFjs4xNsr/b U1TWVVokMmTTXImDHGshL34qYOhhamhfEgCdiWc=
X-Google-Smtp-Source: ABdhPJx2096OO7SlPRGeo6ERQ8lehymFX3c2I2+9LHLnb7dpgs+tIesN9WxxeAz6GKtOoaNQGtRmJYtPd/S+GRBQbIQ=
X-Received: by 2002:a05:651c:1206:: with SMTP id i6mr5436540lja.426.1616074398961; Thu, 18 Mar 2021 06:33:18 -0700 (PDT)
MIME-Version: 1.0
References: <161516725619.22797.1003603720092861577@ietfa.amsl.com> <CAPK2Dex+CWArXvidz24F6XG2S+gw+c4uxFfLRDAdJ-NGv2cz8Q@mail.gmail.com>
In-Reply-To: <CAPK2Dex+CWArXvidz24F6XG2S+gw+c4uxFfLRDAdJ-NGv2cz8Q@mail.gmail.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 18 Mar 2021 22:32:41 +0900
Message-ID: <CAPK2Dey6OW4j_14GTS+kwib_otUsHjfVhoy8FdFK=BX=Fc7+xQ@mail.gmail.com>
To: Erik Kline <ek.ietf@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>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/mixed; boundary="0000000000007b2b5e05bdcfa49d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/v1RbEcZKYD0-PFjfS_kD_6bR8kM>
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: Thu, 18 Mar 2021 13:33:25 -0000

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/
>>
>>
>>
>>
>>
>>