Some comments in-line.
On Tue, Oct 8, 2013 at 8:47 AM, Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
On 10/8/2013 8:36 AM, Ted Hardie wrote: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.
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.
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.
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
Ted
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net