On Fri, Feb 24, 2017 at 4:04 AM, Erik Kline <ek(_at_)google(_dot_)com> wrote:
On 24 February 2017 at 12:41, Christopher Morrow
<morrowc(_dot_)lists(_at_)gmail(_dot_)com>
wrote:
gosh people are being literal today :)
On Thu, Feb 23, 2017 at 10:34 PM, Lorenzo Colitti
<lorenzo(_at_)google(_dot_)com>
wrote:
On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow <
morrowc(_dot_)lists(_at_)gmail(_dot_)com> wrote:
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2017-03-01. Exceptionally,
comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain
the
beginning of the Subject line to allow automated sorting."
Nothing in the past really matters here, what matters is: "Is the bis
draft all set, did we fix all the things which must be fixed before this
draft becomes a real 'standard'?"
I don't think you can say nothing in the past matters here. We know that
there have been host implementations that relied on this guarantee, and we
have to consider that if we change the standard, those implementations will
become non-compliant.
I don't think the proposed (now 160+ messages back) text really says:
"FREE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to use /64
because the application you are being placed into requires it (slac, blah
and blah and ilnp and blah - see rfc7k) then do that, else any other prefix
length works"
how's that not 'ok' for host folks? "Hi, my host is going to be in a
slaac world.. so /64 it is!"
For manual assignment among consenting adults: as you like it. (For all
prefixes longer than /64, the trailing 64bits would still end up being
unique; there is no real issue here.)
I agree.
And I gather everyone agrees that at a minimum the /127 RFC and other
working-group-graduated documents should be suitably incorporated and
referenced.
I think that's in the proposed text, yes... or easily is a list of
[this][that][theother]
Otherwise, this feels like another round of "why isn't IPv6 just 128bit
IPv4?" IMHO having /64 as the logical unit of allocation to network leaves
is a very good thing.
For enduser deployment picking 'something' (/64 is perfectly fine) is
totally sane, and already in the proposed text. The sticking point isn't so
much: "ipv6 is ipv4 with more bits" (which the network treats it as) but:
"hey, we know we allocate longer prefixes all the time for 'reasons' on
things that have bespoke config, let's not make that harder by letting
vendors/etc take shortcuts... acknowledge the fact that we really do have
interfaces with >/64 deployed.
I don't see how that damages network-ops folks, nor host-ops, nor
developers.
There is certainly a discussion for 'not this list' about networking
providers doing 'short sighted' things on their network with respect to
attached customers, but... that's not this document and not this discussion
and not this list (except as an opionion/editorial piece).