At Fri, 19 Apr 2019 10:51:03 +0200,
Alexandre Petrescu <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. 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
Alexandre Petrescu <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. 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
