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

[Job Snijders <[e-mail]>]

i think we are experiencing a breakdown in both communication and
process. this is very unfortunate.

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

whoever shepherds this draft should note this.

Kind regards,

Job

On Sun, May 5, 2019 at 11:54 PM Mark Smith <[e-mail]> wrote:
>
> 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
> > --------------------------------------------------------------------