Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 14 April 2019 20:30 UTC

Return-Path: <brian.e.carpenter@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 1CC51120241; Sun, 14 Apr 2019 13:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 aBhcIO9Qu_yB; Sun, 14 Apr 2019 13:30:07 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 94CE01200B1; Sun, 14 Apr 2019 13:30:07 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id b3so7553349pfd.1; Sun, 14 Apr 2019 13:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6jsE8HSc53gD0hVosRV3JvMKAyI91oUymIjDVwgyXAw=; b=X4SGWjd4/LhdewQUTMKszH/CRwQoIZ2A8WTF9mrGy1Jbf+pL/Wr4Qv+p66MopHIelf uw7wAvxPsA2ORgfsOb9jbGPs5C/D+tOfZQNVYopOBQdJNFkfiL8QFNqoZkJO7LTtd/Nv WUUjgHLiobMvFga5sx3rofrf4+CBVZ/8eZYC5magtzGTqVpbNMAh1uPxYsNdIHT0IU0y PNuDOV0tUD4JibmiA5vfdUFH8BMYzNQ/wedL2e+zXfrbp1WDpzSBUE4A7x+iFfA1sUOd 3JoG1tDvq6XsvJLmfB/k/656pyh8m/LYo0NDGWjVA0agc96445CvbWVdYhHmTq3eY8H7 v9QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6jsE8HSc53gD0hVosRV3JvMKAyI91oUymIjDVwgyXAw=; b=kID8VhROOFu2nOFMx+/SKQBbNxWab8Bs4XgD8OCpjIQoBAqrc1zhK/EP0E0CUByfJm QxQO0b0wtiR5XSLKIVmS+7l0KdIk9Ndm7T5S/aJe+5lnxdpgGjtjimr2JMOPemeFMyNX dcYOqJ/wzdUs/GLXuGYwLJK9ZQoiyDin5hAScpD7EsHsOoFzupytho0T+3x+db44P1co kGF2c2UdKheJYRF9vW+iske/2gwdtgV5KL4vMMeVcwLYJpwh/5a/eR51BaANYfgUGGK7 Gc7pbmPsb+Csb8QnzZmkHO1uBNnhuSA9ywDxzA7RQmnG2y69jKncLlK2uIecaB+K74Er ylyg==
X-Gm-Message-State: APjAAAUxC6EdFfRfNt+FH7dUwoVD844c3j9BAWxInNfxv/LVofHwfSKy 3JjVOlJzLl+FWHyo+1aS6iKYEXlN
X-Google-Smtp-Source: APXvYqySHpPilsHKBASgei88mwOkTljwCZik/uJ97dH3VfwgvqJ1b4R7bA3EWeMLoFHKJH795mXYIw==
X-Received: by 2002:a65:64c8:: with SMTP id t8mr65441115pgv.248.1555273806836; Sun, 14 Apr 2019 13:30:06 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id v189sm100701176pgd.77.2019.04.14.13.30.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Apr 2019 13:30:06 -0700 (PDT)
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Nabil Benamar <benamar73@gmail.com>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "its@ietf.org" <its@ietf.org>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <a8aad636-069c-4451-dbf1-72c1db2204ef@gmail.com> <CAD8vqFfx_FVi5NobrR1p6xEKjkSNa1_ZejgrEs3JPDHJQoxD7A@mail.gmail.com> <MN2PR11MB356570FDBC5798F155DDEE25D82C0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMugd_Xce5cWLtVB4DbR1ZEaFbdfiRpXre9oq61ukRC+n+3cZw@mail.gmail.com> <D8D5F0B7.2F2BB8%sgundave@cisco.com> <D8D5F510.2F2BC8%sgundave@cisco.com> <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com> <D8D7B1E7.2F2CA2%sgundave@cisco.com> <CAD8vqFfSGKhw_ou3VB98C8r1gq=4WD8+f8C5P53C46k-0V+XuA@mail.gmail.com> <66e7c810-45a5-5244-59dc-4b764b6fb346@gmail.com> <CAMugd_Wnnj0cPfokjb8Os6nhPkuZq_eeuYZ=9k0ODTTcreXo3w@mail.gmail.com> <ddb7f6a9-ed58-df80-14ea-0ed1da98316f@joelhalpern.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <7be541b0-f4e3-6436-97e0-5ef7bc43f175@gmail.com>
Date: Mon, 15 Apr 2019 08:30:02 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <ddb7f6a9-ed58-df80-14ea-0ed1da98316f@joelhalpern.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/HapDzXtlaT4QFxiT_IQ1KZkbPtM>
Subject: Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34
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: Sun, 14 Apr 2019 20:30:09 -0000

On 15-Apr-19 02:50, Joel M. Halpern wrote:
> I presume I am misreading this exchange.
> Brian seems to have suggested publishing the I-D under discussion as an 
> RFC, with a warning that implementors should not start implementing 
> because we have not figured out other critical bits that will affect the 
> implementation.

I'm no expert, but my understanding at the moment is that ND will work
in some OCB deployment scenarios and not in others. So I'm suggesting
that the draft should clearly state in which scenarios it will work,
and recommend avoiding other scenarios until an alternative is
standardized.
 
> Is that really a useful thing to do?  Why?
> 
> If what you want to do is put in a normative reference to the missing 
> bits, put it through the IESG process, and then have it wait at the RFC 
> Editor until the working group finishes the missing bits and the IETF 
> approves them, I would have to ask again, why?

Well, that's exactly what the "MISSREF" status of pending RFCs does,
but I don't think that needs to be the case here if the draft is carefully
scoped as above.

Regards
    Brian

> 
> Yours,
> Joel
> 
> On 4/14/19 5:50 AM, Nabil Benamar wrote:
>> I agree with this view. ..so can we solve the ND issue this way and move 
>> the draft forward?
>>
>> Best regards
>> Nabil
>>
>>
>> On Sun, Apr 14, 2019, 03:20 Brian E Carpenter 
>> <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>>
>>      >> All we need is a simple statement in the spec which puts some scope
>>      >> limits, w.r.t the missing ND pieces and issues.
>>
>>     Yes, that is clearly essential, as well as an associated health
>>     warning that implementers must not rush ahead because of the risk
>>     of non-interoperability.
>>
>>     Regards
>>         Brian
>>
>>     On 14-Apr-19 13:58, NABIL BENAMAR wrote:
>>      > +1 Sri
>>      >
>>      > On Sun, Apr 14, 2019, 00:06 Sri Gundavelli (sgundave)
>>     <sgundave@cisco.com <mailto:sgundave@cisco.com>
>>     <mailto:sgundave@cisco.com <mailto:sgundave@cisco.com>>> wrote:
>>      >
>>      >     I understand your point Brian, but IMO there are enough
>>     reasons not to
>>      >     delay this work.
>>      >
>>      >     There are many use-cases/applications where there is a stable
>>     topology of
>>      >     RSU¹s and OBU¹s. The regulations around 5..9 Ghz (DSRC) band
>>     allows the
>>      >     channel use for non-priority/non-traffic safety related
>>     applications. For
>>      >     example, a vehicle in a gas station can receive a coupon from the
>>      >     802.11-OCB radio (AP/RSU) in the gas station. There, its a
>>     stable topology
>>      >     that classic ND is designed for. In this operating mode, its
>>     perfectly
>>      >     reasonable to use classic ND and it works. The authors have
>>     shown enough
>>      >     lab data on the same.
>>      >
>>      >     Ideally, I agree with you that it makes lot more sense to
>>     publish both the
>>      >     specs at the same time. But, for what ever reasons the WG
>>     went on this
>>      >     path. Authors have spent incredible amount of efforts in
>>     getting the draft
>>      >     this far and we cannot ignore that. You can see the efforts
>>     from the
>>      >     version number; when did we last see a draft version -037?
>>      >
>>      >     We also need to distill the recent ND discussions and filter
>>     out the
>>      >     threads that are clearly motivated to insert a ND protocol
>>     that is
>>      >     designed for a totally different operating environment. An
>>     argument that a
>>      >     protocol designed for low-power environments is the solution
>>     for vehicular
>>      >     environments requires some serious vetting. Looking at the
>>      >     characteristics, always-sleeping, occasional internet
>>     connectivity,
>>      >     low-power, no memory, no processing power, no mobility ..etc,
>>     meeting
>>      >     vehicular requirements is some thing most people in the WG do
>>     not get it.
>>      >
>>      >     Bottom line, IMO, we should move this forward and publish the
>>     document.
>>      >     All we need is a simple statement in the spec which puts some
>>     scope
>>      >     limits, w.r.t the missing ND pieces and issues. There are
>>     other proposals
>>      >     in the WG that will address the gaps and bring closure to the
>>     work.
>>      >
>>      >     Sri
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >     On 4/12/19, 1:28 PM, "Brian E Carpenter"
>>     <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>
>>     <mailto:brian.e.carpenter@gmail.com
>>     <mailto:brian.e.carpenter@gmail.com>>>
>>      >     wrote:
>>      >
>>      >     >On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote:
>>      >     >>If you go back and check 2017 archives, I did raise many of
>>     these
>>      >     >>issues.  But, we clearly decided to limit the scope
>>     excluding address
>>      >     >>configuration, DAD, ND aspect, link models. When there is
>>     such a scope
>>      >     >>statement, it should clearly move these comments to the
>>     draft that
>>      >     >>defines how ND works for 802.11-OCB links.
>>      >     >
>>      >     >This is of course possible. In general the IETF hasn't done
>>     that, but has
>>      >     >followed the lead set by RFC 2464 with the complete
>>     specification of
>>      >     >IPv6-over-foo in one document.
>>      >     >
>>      >     >However, I don't believe that publishing an RFC about the
>>     frame format
>>      >     >without *simultaneously* publishing an RFC about ND etc
>>     would be a good
>>      >     >idea. That would leave developers absolutely unable to write
>>     useful
>>      >     >code, and might easily lead to incompatible implementations.
>>     Since
>>      >     >we'd presumably like Fords to be able to communicate with
>>     Peugeots,
>>      >     >that seems like a bad idea.
>>      >     >
>>      >     >Regards
>>      >     >   Brian
>>      >
>>
> .
>