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

[Mark Smith <[e-mail]>]

On Mon, 6 May 2019 at 09:13, Brian E Carpenter
<[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------