Re: [ipwave] [Int-dir] 118

神明達哉 <jinmei@wide.ad.jp> Fri, 19 April 2019 14:42 UTC

Return-Path: <jinmei.tatuya@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 595AC12030E; Fri, 19 Apr 2019 07:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Level:
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 1V2-IAttdeqR; Fri, 19 Apr 2019 07:42:34 -0700 (PDT)
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 383281202ED; Fri, 19 Apr 2019 07:42:34 -0700 (PDT)
Received: by mail-wr1-f47.google.com with SMTP id w10so7223308wrm.4; Fri, 19 Apr 2019 07:42:34 -0700 (PDT)
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=JB0Tgn6j1WaBmJuTF6q5DuMWBtOKt5rwQoViYCYWNeI=; b=W3wmfBOkMKQSyvJHLQ+jkmVMHsIsnBhy7AC3GrWKBejqDuNs7tvBMlU+hsKZauqWVx pDZA51trfPY8qPf47Z4iNah8P4KPhNMFF314ixeeb52gTizYf3Zn3G5nPnO9JMsfNj9+ uPQfhSMoh3VAfVJgs9sSLVfcvamJj0aWvH5OZcYxVU13cD+fTaDYg60sFWWebGSdiRQt 0dThoFFyts+Sc7BnE4lzypAq7bQtg0yOr3ZpjDb9W7TioEv1ywaXMyV7t7kEdVI5CONM SIFU6ph9yhGs9B99ODBKg7XKVH22C/CdkSQNTCR8UFBmC6kACYYzdoNXt+kp8NmjpYA5 44WQ==
X-Gm-Message-State: APjAAAWDRgLLzi/WiAUX7gsl8/gMxzLgNdYY3SjnAtJD973Pmogd3L9E UpBWOfPObqjIar2sXoIFY7hTvRmlvabMoFYx4Vo=
X-Google-Smtp-Source: APXvYqxJlCMhRu2EURVzabQSneU3HXd01c1uMQ0lfzeQZlCUoX180a3SdEUy40sM8MWDWgVwdOtENXaX38ANWORtwKw=
X-Received: by 2002:a5d:5111:: with SMTP id s17mr3108074wrt.159.1555684952368; Fri, 19 Apr 2019 07:42:32 -0700 (PDT)
MIME-Version: 1.0
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <b2459889-f8d6-43c0-acc2-2ffe00fb1985@gmail.com> <26900f46-88da-cf3e-9ae0-b23e056ee840@gmail.com> <ad32743d-981a-0ae7-a6ca-f7a4e9841831@gmail.com> <ece445c6-d599-152c-80aa-670495cbb64d@gmail.com> <CAJE_bqdVqPT761+59TOPHXnr5RqtjNk6WAA81_jZAogGqpJX2A@mail.gmail.com> <350c5cf2-b338-047d-e99b-db6d6a4f6574@gmail.com> <4b717f2c-e8b3-8a47-96d4-67901a98c15f@gmail.com> <f3f722c3-ace5-2e9a-7aaa-30cdc6b5980c@joelhalpern.com> <374342fd-0cf6-30ab-94ae-ef401b005c08@gmail.com> <CAJE_bqcft94gRMUA4Xdq3zzEwZGBxcarZfSQn_HzDoeJ9m=MZg@mail.gmail.com> <2c4dd3e9-90ff-e2d3-5461-f55dcf45717f@gmail.com> <CAJE_bqfd_YQeYrdh9HCu-3mkWmrbAomcL10p1VPG4eaW1gwfRA@mail.gmail.com> <da98f944-bb9e-04b7-ed45-f8fbb11c45ea@gmail.com> <CAJE_bqdb+Uj4+imD5pycBgXkJxiuJsMBKf+jByaYmCtwqLayTg@mail.gmail.com> <a512529d-0d36-efc8-c231-73421c63d9ec@gmail.com> <CAJE_bqd_0kqqNnHww9-bzN7P_d7LvZnSFCHD1DzEwSMpd7sWBA@mail.gmail.com> <1a5503c2-7bed-06bd-ba29-3f9e84f07d13@gmail.com>
In-Reply-To: <1a5503c2-7bed-06bd-ba29-3f9e84f07d13@gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Fri, 19 Apr 2019 07:42:20 -0700
Message-ID: <CAJE_bqevWNNPs5b0Q9D0ozqmmmkp-B_fwbwXnw57nuS2PGZKhw@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, "<int-dir@ietf.org>" <int-dir@ietf.org>, draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org, its@ietf.org, IETF Discussion <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f7ecb00586e3202b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/MQH6GI9RVCwPNWUwKk7Le4s05ks>
Subject: Re: [ipwave] [Int-dir] 118
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: Fri, 19 Apr 2019 14:42:43 -0000

At Fri, 19 Apr 2019 10:51:03 +0200,
Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

> > Actually, that's exactly why my primary suggestion is to stick to the
> > status quo for now.  Changing the status quo needs a discussion at
> > 6man, and it will take long time and can possibly fail, so if you want
> > to avoid the delay, the only feasible option for now is to stick to
> > the status quo and defer any incremental changes to that separate
> > discussion.  Hence the suggestion.  I believe I've always been clear
> > about it, hiding nothing.
> >
> > And it's now your call.  If you don't like to go with the status quo
> > for now and do believe you can get a quick consensus at 6man, I just
> > wish you a good luck.
>
> The status quo is the following: the IP-over-OCB does not specify the
> len of  IID.  It refers to "other documents".
>
> If we go to 6man is to get 6man consensus and quickly.  Otherwise we
> dont go there.
>
> If you, or the AD think we could not get consensus there, then you, or
> the AD, should not direct us there.

I didn't think you can never get consensus there, but I was pretty
sure that it would be hard and take long time and can even fail.  I
already emphasized these several times, and only suggested you go there
if you still think you want the change.  Perhaps you interpreted it as
if you just go to 6man you can quickly get an approval of whatever you
want.  If so, sorry, I probably still didn't emphasize the point enough.  I
guess it was beyond my writing ability to clarify it further, though.

It looks like you're determined to only get a quick agreement on
sticking to the IID len of 118, reusing to consider any other option
for any reason or for any discussion results at 6man.  At this point I
think we have to agree to disagree, then.  If you believe that
approach survives the AD evaluation and subsequent IETF last call and
the IESG ballot, go ahead.  I have no power to stop it.  All I can and
will do is to raise the point that it violates RFC4291 and can't be
published without updating 4291 at the time of the IETF last call, if
this doc ever reaches there.

--
JINMEI, Tatuya