Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

On 06-May-19 23:50, Job Snijders wrote:
> i think we are experiencing a breakdown in both communication and
> process. this is very unfortunate.

Job, I don't think there is any failure of communication. It's
clear enough that you (and Nick and Sander) have reached the
conclusion that the operational costs of the proposal greatly
exceed its value. Other people have reached the opposite
conclusion.

There's also no process failure, because we're still in the process
of determining WG consensus (see the subject field of this thread).
What the WG Chair will conclude is unknown.

> i'll rephrase my words in context of the ietf process: i will appeal,
> because i've observed extreme discontent

Of course you are entitled to appeal a WG recommendation, or to
raise objections during IETF Last Call, or to appeal an IESG
decision. But we're not there yet.

> whoever shepherds this draft should note this.

Actually, no, they shouldn't, because they should reach their
conclusion based on the technical arguments.

Regards,
    Brian

> 
> Kind regards,
> 
> Job
> 
> On Sun, May 5, 2019 at 11:54 PM Mark Smith <markzzzsmith@gmail.com> wrote:
>>
>> On Mon, 6 May 2019 at 09:13, Brian E Carpenter
>> <brian.e.carpenter@gmail.com> wrote:
>>>
>>> On 06-May-19 08:04, Job Snijders wrote:
>>>> Dear Ole,
>>>>
>>>> On Mon, Apr 29, 2019 at 02:01:43PM +0200, Ole Troan wrote:
>>>>>> On 29 Apr 2019, at 13:03, Nick Hilliard <nick@foobar.org> wrote:
>>>>>>
>>>>>> So, is this ID proceeding on a point of procedure at this point?
>>>>>> I.e. is the the slate going to be wiped clean every time an update
>>>>>> is issued, no matter how minor, and all previous objections are
>>>>>> automatically invalidated?
>>>>>
>>>>> Yes, I think that's a somewhat correct reading of working group process.
>>>>
>>>> No.
>>>>
>>>> This interpretation of the working group process is flawed. This is not
>>>> all how IETF works.
>>>>
>>
>> <snip>
>>
>>>> Conceding when there is a real outstanding technical objection is not
>>>> coming to consensus.
>>>
>>> No, but the IETF works by rough consensus, which means that a document
>>> may be advanced even with technical objections that cannot be resolved.
>>>
>>
>> This is an important point.
>>
>> There are some ideas that some people might not fundamentally accept
>> (for me, it is DNS information in RAs, and /127s). However, minority
>> objection shouldn't prevent the idea being accepted if the majority
>> rough consensus on it.
>>
>> It is worth reading RFC 7282, "On Consensus and Humming in the IETF",
>> to understand that rough consensus doesn't mean unanimous agreement,
>> or that a few objections to a mechanism or disagreement as to whether
>> a problem exists or not, means that consensus cannot be achieved.
>>
>> On Consensus and Humming in the IETF
>> https://tools.ietf.org/html/rfc7282
>>
>> (Related to DNS information in RAs, and Alex's wanting to be removed
>> as an author from the 64 bit IID RFC, I'm an acknowledged contributor
>> to the most recent DNS in RA RFC. I've always fundamentally disagreed
>> with the idea, however I still contributed to that draft to make it
>> work better for people who choose to do that. In the future, I may
>> change my mind about DNS information in RAs. If unanimity was
>> required, I alone could have stopped this RFC being published because
>> of my disagreement.)
>>
>>
>>> In this case, *speaking for myself alone*, I don't know of any more
>>> text changes that would meet the objections that have been raised.
>>> In fact, the only suggestion for change that has been made is to drop
>>> the whole idea. The WG could decide to do that. That's not my decision
>>> to make; as an author of a WG draft, I do what the WG requests.
>>>
>>>> The misuse of process has been brought up before
>>>> https://mailarchive.ietf.org/arch/msg/ipv6/GAIeuDbH3q1u9YQvQLHYaYK4sXU
>>>> It gives me great cause for alarm to observe these proceedings.
>>>
>>> There's no cause for alarm. There's a difference of opinion - some
>>> people have expressed support for the proposal, others have said
>>> it is intrinsically bad. Further wordsmithing can't fix that.
>>>
>>> There are thoughts about how a WG can resolve such a difference of
>>> opinion in https://tools.ietf.org/html/rfc7282 .
>>>
>>
>> Ok, robustness in reference redundancy ;-)
>>
>> Regards,
>> Mark.
>>
>>
>>>    Brian
>>>
>>
>>
>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
> 