Re: Last Call: <draft-resnick-on-consensus-05.txt> (On Consensus and Humming in the IETF) to Informational RFC

[Ted Hardie <[e-mail]>]

Some comments in-line.

On Tue, Oct 8, 2013 at 8:47 AM, Dave Crocker <[e-mail]> wrote:

> On 10/8/2013 8:36 AM, Ted Hardie wrote:
>
>> And what are the RFC numbers for the comments?  If none, as I suspect,
>> then the comments aren't the same status as the documents--that's fine
>> for RFC 791 and 2460, but it is not clear that Pete's document falls
>> into the same class.  I would argue it does not.
>>
>
>
> Unfortunately the concern you are raising has often been applied to all
> sorts of IETF work.  Many bits of IETF work are subject to on-going
> comments and often reach the practical status of de facto -- or, in the
> case of the errata mechanism, IETF de jure -- modifications to the
> published document.
>
> In fact, the line of argument you raise has frequently been lodged against
> the BCP construct.  Yet we keep finding BCPs useful to create.
>
>
>    1.  Does the IETF need a modern, thorough, community-approved statement
> of it's consensus model and the application of the model? That is, both
> theory and practice.
>
>        So far, it looks as if the community certainly thinks we do, and
>  strongly agree.  In fact I think we suffer greatly by not having it. And
> as we've gone through multiple generations of participants, we've tended
> towards reliance on catch-phrases, without a shared understanding of their
> deeper meaning and specific practice.  So folks invent their own meanings
> as best they can.  Something like Pete's draft is needed to provide shared
> substance to what we mean when we talk about rough consensus.
>
>
If the community believes that we need a community-approved statement of
its  decision-making model and how it is applied, then we should develop one
in a community process.  It may at that point be something that becomes a
BCP.

As an input draft to that discussion or community process, I think Pete's
draft is very useful--it has sparked multiple rounds of discussion.  But I
don't think it is clear that this is its intended function (that "unclear
on the audience bit") and I think it might be read to be a proposed output
document from that process. I don't think it is anywhere near ready to be
considered as an output document, for reasons I already laid out.


>    2.  Should the statement be an RFC or something more malleable (and
> therefore ephemeral)?
>
>        Why would we not want something this essential to be available
> through our formal publishing and archiving mechanism?  To the extent that
> later discussions prompt modifications, that's what the errata mechanism is
> for.  And eventual revision to the RFC.  Unless someone thinks that this
> core construct for the IETF is going to be subject to constant and
> fundamental modification???
>
>
Again, I think this is the question of the document's audience and
function.  If the aim is to use it to spark debate, than ephemeral is
better than fixed.  If it is meant to be a community statement of our
process, in theory and practice, it should be fixed--but this document is
not that community statement in its current form.

regards,

Ted


> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>