Re: <draft-ietf-6man-rfc4291bis-09.txt>

[Philip Homburg <[e-mail]>]

>> So let me call them 'host part'
>
>Hate to be picky but in RFC8200 'host' does not include 'router' and these
>bits certainly exist in router addresses.
>
>So it would have to be 'node part'. But in most cases (the only exception
>being anycast) these bits may be (not must be) different in the node per
>interface, so 'node' is still wrong. I just don't get why it isn't
>'interface part' (with an exception for anycast). And if it's 'interface
>part' I really don't see why it isn't 'interface identifier'.

I'm not attached to any particular term. However, I think it is important 
that the reader of rfc4291bis gets a clear under standing of the difference
between an IID as used for SLAAC. Which has a lot of properties, including
that it is generated locally on the node and is used for address configuration.

And on the other hand, what I called 'host part' which in general doesn't have
any properties. Calling it an 'interface identifier' is confusing if the
address is an anycast address. In the context of ND, an address is either 
covered by an onlink prefix which means that a sending node should try to
resolve the address to a link layer address or if not, the packet should be
passed to a (default) router. In the context of ND, the 'host part' is
completely transparent to the sending host, except that a NA indirectly
signals whether the address is anycast or not.

>Here's a thought. How would it be if the contentious sentence in 4291bis
>read, in its entirety:
>
>"Interface Identifiers are 64 bits long when used for Stateless
>Address Autoconfiguration (SLAAC) [RFC4862]."

In my opinion rfc4291bis should not be a random collection of true statements
that have to be assembled by the reader.