Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

[David Farmer <[e-mail]>]

On Fri, Feb 24, 2017 at 1:55 PM, Christopher Morrow <
[e-mail]> wrote:

>
>
> On Fri, Feb 24, 2017 at 2:51 PM, David Farmer <[e-mail]> wrote:
>
>>
>>
>> On Fri, Feb 24, 2017 at 1:36 PM, Christopher Morrow <
>> [e-mail]> wrote:
>>
>>> sorry, a clarification request below.
>>>
>>> On Fri, Feb 24, 2017 at 1:42 PM, David Farmer <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Feb 24, 2017 at 12:11 PM, james woodyatt <[e-mail]>
>>>> wrote:
>>>>
>>>>> On Feb 24, 2017, at 03:11, Nick Hilliard <[e-mail]> wrote:
>>>>>
>>>>>
>>>>> Let me be more specific then: are you proposing that vendors write code
>>>>> to allow or disallow interface subnets which aren't /64 (or /127)? This
>>>>> is a binary choice; a vendor needs to choose one way or another.
>>>>>
>>>>>
>>>>> I don’t know how I can be more clear about this: I insist that general
>>>>> purpose host operating system developers should be expressly permitted to
>>>>> write code that declines to accept subnet prefixes of any length other than
>>>>> /64 on the grounds that these are not used in general IPv6 networking and
>>>>> the successor to RFC 4291 continues to say so.
>>>>>
>>>>> I know there are operating systems with billions of units in the field
>>>>> today that do exactly this because RFC 4291 and its predecessors have for
>>>>> years given them clear license to do so, and I don’t want to see the
>>>>> publication of I-D.ietf-6man-rfc4291bis as RFC come to remove this license
>>>>> as a side effect of promoting IPv6 to full Standard category.
>>>>>
>>>>> You want to remove that license? I suppose we can continue discussing
>>>>> that, but I think you should try to do it in a separate draft once IPv6 is
>>>>> officially promoted.
>>>>>
>>>>> --james woodyatt <[e-mail]>
>>>>>
>>>>
>>>> I would not want to make code that does /64 only out of compliance with
>>>> the spec, especially for SLAAC.  I would like to discourage that stance,
>>>> maybe for DHCP, but for sure for manual configuration if that mode is
>>>> provided.  But, I don't see /64 only as a invalid stance for an host OS to
>>>> take.  But neither do I want the spec to disallow non-/64 for DHCP, manual
>>>> configuration, or potential new modes of configuration if we ever get
>>>> there.  I think SLAAC should to remain /64 only. I think DHCP and manual
>>>> configuration should be encourage to support non-/64 options, but even they
>>>> should allow /64 only.
>>>>
>>>>
>>> please restate your last sentence... I think you missed a word or three?
>>>
>>
>> It's still ok for a host OSes to do /64 only with DHCP and manual config,
>> not preferred.  I'd prefer host OSes support non-/64 as well for DHCP and
>> manual config, but not mandatory.  Only /64 should be REQUIRED of anyone,
>> host, router, or what ever.  Non-/64 should be OPTIONAL for everyone.
>>
>> Is that clearer?
>>
>>
> clearer, but not what I was expecting...
>
> OPTIONAL means 'will not happen without customer loud voices' (generally).
> I'm worried that OPTIONAL is going to cause problems :(
>

I was trying to be conservative in the change to push through the process.
I'd be open to RECOMMENDED, but I don't see REQUIRED as an option, it would
break too much

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================