On Fri, Feb 24, 2017 at 4:04 AM, Erik Kline <ek@xxxxxxxxxx> wrote:
On 24 February 2017 at 12:41, Christopher Morrow <morrowc.lists@xxxxxxxxx> wrote:gosh people are being literal today :)On Thu, Feb 23, 2017 at 10:34 PM, Lorenzo Colitti <lorenzo@xxxxxxxxxx> wrote:On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow <morrowc.lists@xxxxxxxxx> 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@xxxxxxxx mailing lists by 2017-03-01. Exceptionally, comments may be> sent to iesg@xxxxxxxx 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).