Re: [ipwave] [Int-dir] 118

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 19 April 2019 14:56 UTC

Return-Path: <alexandre.petrescu@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 A63911202E3; Fri, 19 Apr 2019 07:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham 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 YvTpe6gw2_R1; Fri, 19 Apr 2019 07:56:40 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42931200F8; Fri, 19 Apr 2019 07:56:39 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3JEuboc032997; Fri, 19 Apr 2019 16:56:37 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8EE072069AD; Fri, 19 Apr 2019 16:56:37 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7763C206998; Fri, 19 Apr 2019 16:56:37 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3JEubps020134; Fri, 19 Apr 2019 16:56:37 +0200
To: 神明達哉 <jinmei@wide.ad.jp>
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>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.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> <CAJE_bqevWNNPs5b0Q9D0ozqmmmkp-B_fwbwXnw57nuS2PGZKhw@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <fc6d1e1b-1fb1-55b8-8853-9b1cf2c73d4f@gmail.com>
Date: Fri, 19 Apr 2019 16:56:37 +0200
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: <CAJE_bqevWNNPs5b0Q9D0ozqmmmkp-B_fwbwXnw57nuS2PGZKhw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/kwpSobeYBjTVFllljFtZVfUGTpA>
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:56:42 -0000

Tatuya,

Thank you very much.

See below.

Le 19/04/2019 à 16:42, 神明達哉 a écrit :
> At Fri, 19 Apr 2019 10:51:03 +0200, Alexandre Petrescu
> <alexandre.petrescu@gmail.com <mailto: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.

To clarify: no, I did not interpret it as getting a quick approval from
6MAN.  Actually I know very well 6MAN backfires very strongly.  It is
the case with ND and with IID len now.

6MAN provided ND reviews a couple of times last year; each time I did my
best to address them.  It seemed as a solved issue.  Then other reviews
came in, and again ND, as if nothing was done before.

It is as if it was not 6MAN who originally redirected this IP-over-OCB
work to create another WG.

Now I understand better what happened a few years ago: actually 6MAN
wanted us to actually stop working on this; they did not ask us to
create a WG and solve it.  They just wanted that we should not do this.

The same happens now: 6MAN is not asking me to solve some problem with
this IID length - they just want this IID len work to stop.

In a sense, I agree with 6MAN that wants to slow down some too fast
evolutions of a protocol that is not deployed as expected.  In another
sense, it is difficult to keep a WG alive without any new work.

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

YEs, let us agree to disagree, as they rightfully say.

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

You seem right in your intentions.

Along these lines, all I can do is this.

I posted a request for support for that I-D in 6MAN.  I wait to see
whether there is support for it.

Someone recommended to write another I-D in 6MAN, requesting the
'assignment of fe80' from IETF/IA/nA.  He does not agree with that draft
either.  I wait to see whether there is support for it, maybe from others.

I will wait a few days, no more.

After that I will give up: if there is no support in 6MAN after a few
days then I will retire from the IPv6-over-OCB draft.

Alex

> 
> -- JINMEI, Tatuya