Re: [Int-dir] 118

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx <mailto:alexandre.petrescu@xxxxxxxxx>>
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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux