Scott, Brian, John, et al,
On 10/28/2015 9:45 PM, Scott Bradner wrote:
> I also do not think section 1.1 would inform any reader of any changes in process that this ID proposes
Since it doesn't seek to do that, it should not be surprising that it
doesn't accomplish it.
Here are a few simple points:
1. The draft dramatically reorganizes the text. The draft has
extensive wordsmithing. And, yes, the draft probably has bits of
procedure that differ from what is in RFC 2418.
2. Changes that extensive do not permit the sort of bookkeeping
you are focusing on. Or rather, such bookkeeping is extremely expensive
to develop, while -- I believe -- being is entirely useless for any
reader who isn't a bookkeeper. Broadly speaking, the actual practice of
process management in the IETF is not nearly precise enough or
consistent enough or faithful enough to the precise details of RFC 2418
to make such fine-grained historical auditing anything close to useful.
3. The actual IETF working group practices today often differ from
what is in RFC2418. No one seems bothered by that. So rather than
focus on auditing for changes, the goal for the draft is to accurately
reflect what is done today and/or what the community seems to believe
/should/ be done today. Anyone wanting to audit the details of the
document needs to focus on current reality, not historical reference.
For those who feel otherwise, they are free to do the considerable work
of creating a changes audit.
4. The draft was first released publicly 7 months ago. A mailing
list was set up for discussion. 36 people are subscribed, though it's
notable who some of the folk /not/ on the list are... On that list,
Brian offered some detailed comments and they were factored into
revisions of the draft. But other than Brian's comments back in March,
/no one has offered comments on the substance of the draft/. Not on the
wgguide mailing list and not on the ietf list. Seven months.
The draft was produced because Ralph and I felt that the community
needed a revised handbook of working group operations. Revised both in
terms of making the details better match current practice (and/or
current /desired/ practice) and in terms of organization to facilitate
actual use as a reference document.
The organization that I put together for the original version of the RFC
(maintained in the current RFC version) has an expository style typical
of specifications. The organization Ralph and I have developed is meant
to be more helpful for multiple kinds of readers and multiple kinds of
consultation.
The substance of open processes has to do with making things available,
allowing public discussion, and making changes responsive to input.
We've been doing that. A working group format is not a mystical process
for open collaboration. It's a tool. Other tools work well too. In
particular, working groups only perform well when there is serious
community motivation to participate. After 7 months and multiple draft
revisions, there is no evidence that the community wants to put in the
very considerable overhead effort of having a working group and making
it succeed.
So I hope that the energy you folk are currently putting into arguing
about process formalities can instead be channeled into the substance of
the draft.
Section 1.3 has a significant list of significant open issues for the
draft. I invite folk to put some effort into suggesting content that
will permit closing those open issues.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net