Re: [ipwave] [Int-dir] link-local text (Re: Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34)

[Alexandre Petrescu <[e-mail]>]

Le 15/04/2019 à 23:02, 神明達哉 a écrit :
> At Mon, 15 Apr 2019 19:48:53 +0000,
> "Pascal Thubert (pthubert)" <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>  > The point on multilink subnet is that link local address that is 
> limited to the link cannot reach all nodes in the MLSN. This illustrates 
> that a link and a subnet are very different beasts, whereby the former 
> is physical and the latter logical.
> 
> Yes, I understand that.
> 
>  >  The sentence that requires using a link local prefix on a subnet is 
> therefore non sensical and denotes a confusion between the concepts. The 
> text discussed below is about link not subnet.
> 
> Agreed, that's exactly why I wondered whether the intent was to say
> it's NOT a multi-link subnet.  But, it looks like the intent is to
> just state somewhat obvious: "link-local addresses must be considered
> on-link", so it's probably better not to bother discussing whether
> it's a multi-link subnet or not.  And then, I agree that any
> link-local discussion should belong to somewhere else than the
> "subnet" section.
> 
> I personally still think Section 4.3 is the best place, and combining
> all of my understanding of the intent, it might read, e.g.:
> 
>     There are several types of IPv6 addresses [RFC4291], [RFC4193], that
>     MAY be assigned to an 802.11-OCB interface.  Among these types of
>     addresses, the interface MUST at least have one link-local IPv6
>     unicast address as specified in [RFC4291].  Only those link-local
>     addresses MAY be formed using an EUI-64 identifier, in particular
>     during transition time.
> 
>     [2nd paragraph unchanged]

The -41 text is in the draft.

If you feel like I should change it please let me know.

I need to understand whether Pascal agrees with the text in -41.

Alex

> 
>     Any other link-local addresses than those assigned to the
>     802.11-OCB interface MUST be considered on-link in terms of on-link
>     determination as defined in [RFC4861].
> 
> (The added 3rd paragraph looks too obvious to say to me, but that's
> what I might say if I have to say something about it).
> 
> Anyway, again, it's just an observer's suggestion for hopefully making
> it more readable without changing the author's intent.  If it rather
> introduce more confusion or controversy, please just ignore it.
> 
> --
> JINMEI, Tatuya