Re: disagreement on which OS should change

[Bob Hinden <[e-mail]>]

Alex,

> On Apr 27, 2019, at 8:03 AM, Alexandre Petrescu <[e-mail]> wrote:
> 
> Le 27/04/2019 à 10:33, Ole Troan a écrit :
>> Quite. The most prudent action is to stop responding to messages in these sets of threads. I will do so, and I encourage everyone else to do the same.
> 
> Ole,
> 
> I do not understand this.
> 
> You invited me to rate limit my messages.  I did.

I see 4 emails so far today, 7 yesterday, 4 on the 25th, and 13 on the 24th.

That doesn’t look like rate limiting to me.

Bob


> 
> Now you invite everyone (probably myself too) to not respond to these sets of threads I initiated.
> 
> I would like to ask you: do you think I should stop this topic?  Do you ask this as a WG Chair?
> 
> If so, please be explicit.
> 
> Thank you,
> 
> Alex
> 
>> Cheers,
>> Ole
>> On 27 Apr 2019, at 09:54, Brian Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
>>> I don't understand this discussion. LL addresses exist in the absence of any routers and are created spontaneously by hosts with no external inputs. Therefore, there is no such thing as an identity for a link, there is only an interface identifier which is strictly local to the host. Even in a point to point case, there is no reason that the two hosts would agree about the link's identity.
>>> 
>>> Regards
>>>     Brian
>>>     (via tiny screen & keyboard)
>>> 
>>> On Sat, 27 Apr 2019, 17:13 Gyan Mishra, <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>>    Alex
>>> 
>>>    I agree and that completely makes sense what you are saying.
>>> 
>>>    So with RFC 4291 all hosts for all subnets we’re actually sitting
>>>    on the same fe80::/64 even though different physical or logical
>>>    interfaces and each host was made unique by the EUI64 station id.
>>> 
>>>    So with the new  draft if all hosts would sitting on the same
>>>    global unicast subnet now also sit on the same unique Link local
>>>    subnet.  So the RA for Default route sent to all hosts on the
>>>    subnet would be this new LInk local set on the router
>>> 
>>>    Subnet 1:
>>>    Router A fe80:1::EUI64 bia vrrp vip fe80:1::1  ::/0 sent to host
>>> 
>>>    Router B fe80:1::EUI64 bia vrrp vip fe80:1::1 ::/0 sent to host
>>> 
>>>    Host A fe80:1::EUI64 bia
>>> 
>>>    Host B fe80:1::EUI64 bia
>>> 
>>> 
>>>    Subnet 2:
>>>    Router  A fe80:2::EUI64 bia  vrrp vip fe80:2::1 ::/0 sent to host
>>> 
>>>    Router B fe80:2::EUI64 bia vrrp vip fe80:2::1 ::/0 sent to host
>>> 
>>>    Host A fe80:2::EUI64 bia
>>> 
>>>    Host B fe80:2::EUI64 bia
>>> 
>>>    Gyan
>>> 
>>>    Sent from my iPhone
>>> 
>>>    > On Apr 26, 2019, at 5:11 AM, Alexandre Petrescu
>>>    <[e-mail]
>>>    <mailto:[e-mail]>> wrote:
>>>    >
>>>    >
>>>    >
>>>    >> Le 25/04/2019 à 18:09, 神明達哉 a écrit :
>>>    >> At Thu, 25 Apr 2019 09:41:35 +0200,
>>>    >> Alexandre Petrescu <[e-mail]
>>>    <mailto:[e-mail]>
>>>    <mailto:[e-mail]
>>>    <mailto:[e-mail]>>> wrote:
>>>    >> > >  > That an implementation allows you to do something does
>>>    not mean that
>>>    >> > > it is supported (in the product sense) nor that the RFC is
>>>    wrong.
>>>    >> > >
>>>    >> > > Right, but I actually don't understand why we still have to
>>>    have this
>>>    >> > > kind of conversation.  Almost all real-world
>>>    implementations have some
>>>    >> > > glitch;
>>>    >> >
>>>    >> > The problem here would be to ask which of the OSs have the
>>>    glitch: the
>>>    >> > ones that support fe80:1:: or the ones that dont?
>>>    >> Obviously the former.
>>>    >
>>>    > I think it is the latter: the OSs that dont support fe80:1::
>>>    should change.
>>>    >
>>>    > Alex
>>>    >
>>>    >
>>>    >
>>>    >
>>>    -------------------------------------------------------------------------
>>>    > If time permits:
>>>    >
>>>    > I would like to make a note here.  I know that AD and Chairs
>>>    read these messages.  I would like to invite consideration of
>>>    these messages, if time permits, when pondering about which way
>>>    the balance tips.
>>>    >
>>>    > My reading of these discussions is that:
>>>    >
>>>    > - one person, or small group of persons, indeed highly
>>>    knowledgeable, consider fe80:1:: to be a violation of standards,
>>>    an RFC to be right, one OS to be right, manual config of LLs to be
>>>    wrong.
>>>    >
>>>    > - probably more persons, or at least several persons, consider
>>>    fe80:1:: to not be a violation of standards, some other OSs to be
>>>    right, manual config of LLs to be right, 'liberal in what you
>>>    accept', 'open minded'.
>>>    >
>>>    > (some person is in both categories).
>>>    >
>>>    > This is my reading of the discussion.
>>>    >
>>>    > Alex
>>>    >
>>>    >
>>>    >   The question itself is nonsense to me, equal to
>>>    >> a question asking which OS has the glitch: an implementation
>>>    allowing
>>>    >> to send a packet with source=::1 outside of the node, or an
>>>    >> implementation that prevents it.
>>>    >> If you don't like to consider it to be a glitch, update
>>>    RFC4291.  As
>>>    >> you've already seen it would be quite hard, but it's not
>>>    necessarily
>>>    >> impossible.  Insisting a standard violation behavior is not a
>>>    glitch
>>>    >> because of the existence of the behavior is just a time wasting
>>>    >> effort.
>>>    >> --
>>>    >> JINMEI, Tatuya
>>>    >
>>>    > --------------------------------------------------------------------
>>>    > IETF IPv6 working group mailing list
>>>    > [e-mail] <mailto:[e-mail]>
>>>    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>    > --------------------------------------------------------------------
>>> 
>>>    --------------------------------------------------------------------
>>>    IETF IPv6 working group mailing list
>>>    [e-mail] <mailto:[e-mail]>
>>>    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>    --------------------------------------------------------------------
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------