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

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Mon, 08 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 002D23A2A26 for <its@ietfa.amsl.com>; Mon, 8 Mar 2021 05:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 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, 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 zxT_LU9gLabS for <its@ietfa.amsl.com>; Mon, 8 Mar 2021 05:33:52 -0800 (PST)
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 023FA3A2A25 for <its@ietf.org>; Mon, 8 Mar 2021 05:33:51 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id p15so16043408ljc.13 for <its@ietf.org>; Mon, 08 Mar 2021 05:33:51 -0800 (PST)
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=3uJCiorre2eOtVHUJ0MW+R/qyQ/F/wxcKv0uEqFOVlU=; b=Rk8CjlegVMaRLmFWrfKI2V8PqzKWLQM673ZEcaj55htRA4DyrrnHGyEGNpuAtcTTW1 di1ySXBmvUU2+UNXHFud9gBiM+2JlXEYJfG8qeeyyUy0BMpngjek+cuaetWNf3DaJbZR cSgvniKhj8ibE4KykM0RaoMoMs9G6yZcc6PYHt5rh41xz/kKEgyZBQ/gyEtRUtVPC2/z 8rsz9YSmhoiAnzQBheHos5sOItgRBunTVPMAJrUFwGqwXTulkkwy8OdK8mYNKfoNJuSQ +R+P90EI9FIzrv5E2ezEOYuBvREDzKun144lfmYeLuD0+HyUjfGYnKr7HiReURhwXwZG uhcg==
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=3uJCiorre2eOtVHUJ0MW+R/qyQ/F/wxcKv0uEqFOVlU=; b=BMGkAVSxt5/3PuG3s0tmCsAEkB+ezzCwODo5g3ELriniLozQp/ZHjAtNgOeiA1UN4x koFmZzVwf6VqibepUHLiL/6V4JChZc9NpUKvDOMPjl2IeyQwzx9H6Y+2cns46o7mXvkX AKiOpfBnj9B1MwoqA/gIJY9TjVLu3AZtRyMsdNA2WDQi3x6qxSKPgTlIfs6WRpQV1Tui DYjBN9nAlaRIo6M7OLht9KkBt5vioA2t7FNNqadHybmXYVGwdU9zEmW4dap8Ora+YLhd 1WNfyO8D0NuIKD4NHi8jCHgCEi5K187ovKkJMZS2HV6icKM1xc5Ikwy2zIfEZ+aDG1GT 4jxw==
X-Gm-Message-State: AOAM5300bgtjXfDTy5zlwFttphjYUxK1Ykx+9VYY6bl/rUnMe0k6UI5e oEgnOjTx4yOHjqJ/1rT3MQOqwX3OGjVJEz8zx1M=
X-Google-Smtp-Source: ABdhPJzsC1s/u0mzVCwpscHckJzmf7T7zwD4UtKRgAs6PWYnZoQlVX/4LbRcXmdDEMPzsGKO8vnCsfDoc77uFAK/Qgc=
X-Received: by 2002:a2e:b0d4:: with SMTP id g20mr14060832ljl.127.1615210429782; Mon, 08 Mar 2021 05:33:49 -0800 (PST)
MIME-Version: 1.0
References: <161516725619.22797.1003603720092861577@ietfa.amsl.com>
In-Reply-To: <161516725619.22797.1003603720092861577@ietfa.amsl.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Mon, 8 Mar 2021 22:33:13 +0900
Message-ID: <CAPK2Dex+CWArXvidz24F6XG2S+gw+c4uxFfLRDAdJ-NGv2cz8Q@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/alternative; boundary="000000000000e79eb405bd067beb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/j3YY_qYp0f_xSgNflEiHVET8pxE>
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, 08 Mar 2021 13:33:54 -0000

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