From: barryleiba(_at_)gmail(_dot_)com
[mailto:barryleiba(_at_)gmail(_dot_)com] On Behalf Of
Barry Leiba
There is no formal process that involves "adopting" anything. Working
group chairs appoint document editors (this is in RFC 2418, Section
6.3). There is nothing anywhere that specifies how the first version of
a WG document is formed.
[WEG] snip
We seem to have settled into
a culture of starting with individual submissions and "adopting"
them, but there's nothing that requires that
[WEG] What this says to me is that we are adhering to an ad hoc or de facto
process, and therefore in most cases we're not really thinking about why we do
it, or even if we should, we're just going with the flow of past precedent.
AKA, "that's the way we've always done it/that's just the way we do things
around here". We wouldn't do that with a technical protocol that we defined,
we'd update the standard to reflect reality as implemented. So why are we
behaving differently with our internal protocol?
If it works and people like it, let's document it so that it can be applied
consistently. If people think it's unnecessary and we should stick to the
documentation as written (no adoption), let's do that. If we actively *don't*
want an IETF-wide procedure here, we can even document that the process for WG
adoption of drafts is WG-specific and could document those specifics in a WG
policies wiki document maintained by the chairs. There are plenty of WGs that
have specific ways that they like to handle document submission, reviews, and
requests for agenda time. It might be useful to have that all in one place so
that people can know what's expected of them.
So, yes, the chairs get to decide how they want to seed the document
development process, and they have a pretty free hand in making that
decision. Your ADs are always there for further guidance if you need or
want it. But there's no formal process for that, and I think that's how
we want it to be.
[WEG] Barry, I respectfully disagree. The whole point I'm making here (and
Geoff underscored nicely) is that it's currently too variable and too reliant
on a small group of individual volunteers implementing it correctly. When
things are not documented, we are dependent on having leadership who innately
know how to do the right thing. But that leadership turns over fairly
frequently. so assuming that we'll always have people in leadership who know
how to make this process work "correctly" without some guidance is pretty
risky, IMO. As the IETF ages and grows, and personnel (participants and
leaders) turn over, the oral tradition breaks down in a hurry. Further, no
matter how good the individuals are at their "jobs" within the IETF, applying
undocumented policy (especially doing it inconsistently) looks to the outside
world as arbitrary and capricious, or as centralizing authority, and that's not
at all productive in an open standards development process. It can be
discouragi!
ng to new participants, because it contributes to the overwhelming nature of
figuring out how to get started as a new document author, and it can make the
process seem more closed than it actually is.
It is quite possible to document a policy or procedure with directional
guidance and enough flexibility to allow intelligent adults to think for
themselves and adapt to the reality of the situation during implementation. I'm
willing to work on an update to 2418 to cover this apparent gap, but I'd like
to know whether others agree that this is a problem (and are willing to work on
the update with me).
Wes George
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.