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

[神明達哉 <[e-mail]>]

At Sun, 23 Jul 2017 11:55:06 +1200,
Brian E Carpenter <[e-mail]> wrote:

> Actually, by removing all the exceptions in the -09 text, I contend
> it is a considerable semantic simplification.
>
> > for no benefit other than to make non-64-bit IIDs appear to be more outcasts.
>
> Not at all. It sticks to the principle that an Internet Standard doesn't
> change the existing protocol but clarifies the applicability of the
> 64 bit rule. You need to compare it with RFC4291, not with the -09 text.
>
> If you want to *change* the rule for SLAAC IID lengths, that's outside
> the scope of promoting 4291 to IS status.

+1.  We really need to stop introducing the discussion on non-64 SLAAC
IID length to the rfc4291bis discussion.  It's perfectly fine to
discuss it in any post-rfc4291bis updates (although I'm quite
skeptical whether we can reach any consensus), or we could even say
"given the possibility of the post-rfc4291bis discussion we should now
give up promoting RFC4291 to IS".  But, due to the conservative nature
of rfc4291bis we can't simply have this discussion in that context
anyway, and given its controversy it would simply waste our time.  We
don't need any more unnecessary controversy for out-of-scope topics
and need to focus on the point.

BTW, as for this one:

>> "Interface Identifiers are 64 bits long when used for Stateless
>> Address Autoconfiguration (SLAAC) [RFC4862]."

>> Who here could not live with that?

I'd personally live with any editorial hack as long as we can reach
rough consensus (and unless it violates RFC4291 or current
deployments).  Also, IMO it's at least better than the draft-09 text
(excluding addresses "manually configured") as it's less ambiguous.
But I thought Bob didn't like to refer to a particular way of
generating addresses whether it's SLAAC or DHCPv6.

--
JINMEI, Tatuya