Dave,
I think one can like, or dislike, this proposal. My first
objective was to make sure we were complaining about what was
there/ intended, rather than what wasn't. It is not the best
document I've ever seen wrt specifics and explanation
(including, I imagine, some of what you describe as "cryptic"),
but, to some degree, that is part of the point. Specific
comments below...
--On Friday, 19 May, 2006 08:40 -0700 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:
>...
> The reasons the document offers for not using BCP status are:
>
> 1. usually a great deal of debate and effort to change
> 2. bind up editing resources in the final edit stage
> 3. as well as being limited (in practice) to ASCII
> 4. not available for Info documents
> 5. "updates/obsoletes" ...can also be quite confusing to
> follow
>
> Does anyone think that the new mechanism will not suffer #1
> and #2?
For #1, it removes the requirements for Last Call and
demonstration of community consensus that apply to BCPs. If I
were advising the IESG, I'd suggest that there were many
documents that would fall into this category for which the right
procedure would be to expose a draft, announce intent to
publish, wait two weeks (or some other short period), and do it.
I.e., we would shift, for some of these materials, to more of a
"take action and back away if the community finds problems"
approach, rather than the BCP pattern. There are issues in
knowing which things should be handled that way and which ones
should still get BCP-equivalent processing (see my other note
about the issue of specifics and this proposal), but I note
that, if all policy documents were handled according to this
outline, it would eliminate the "IESG makes decision, quietly
puts up a document without telling anyone, then yells 'gotcha'
when anyone violates one of those rules". I think the IESG is
moving away from that approach, which is good; anything that
reinforces that trend is, IMO, very good.
For #2, this gives the IESG the ability to figure out when
something is "good enough", post it, and tune as needed. That
is a very different model from the RFC Editor's determination to
have all documents be of uniform high editorial quality and of
archival quality and stability. I think that separation is also
a benefit... see below.
># 3 is a universal issue; if anything, IETF process documents
># need more powerful font and graphics capabilities less than
># our more interesting technical specifications, so it is
># difficult to guess why this new mechanisms warrants a new
># formatting convention.
Part of the reason for the ASCII focus on RFCs (and RFC
Editor-published archival documents should we ever invent other
kinds) is that they need to be archival. Historically, methods
for providing more powerful fonts, graphics, etc., is that they
get tied to software that doesn't stand the test of time
(whether we have gotten past that with PDF is the subject of a
different conversation). These documents are not archival and
hence not subject to the same constraints. That said, if the
only reason for this was more flexibility about formatting and
presentation, I'd be violently opposed to it -- just not work
the marginal effort of doing something different.
># 4 is the interesting objection, because it appears to have
># real substance. However the new series is for operations
># documents, not "informational" ones.
But we are publishing tools documents and similar things as
informational now, if we publish them at all.
># 5 implies that the updates/obsolets mechanism is generally
># problematic, but I do not recall hearing about this before.
># Is there some undercurrent of community dissatisfaction with
># it?
For procedural materials, I think "yes". One example is what it
takes to figure out what our procedures actually are, given the
number of things that have updated, modified, or fine-tuned RFC
2026.
> On reflection, the proposal could easily be taken as intended
> to begin an end-run around the RFC editor process. If indeed
> the RFC Editor process is problematic for IETF documents, then
> we
> need to worry about it more for our primary output than our
> internal process documents.
Interestingly, I'd argue exactly the opposite. As another
recent thread points out, the RFC Editor's special expertise is
in the vetting, editing, and publishing of technical, archival,
documents. These documents are neither. Getting them out of
the RFC Editor's processing queue could free up resources that
would be better spent on our primary output materials. If that
sped those up, even a little bit, it would be, I think, a net
gain. And certainly separating IETF procedural documents from
the RFC process is not an end run around what other documents
call the "technical publisher" role associated with the RFC
Editor.
> And, by the way, the premise of the proposal is that we need
> to be more agile in being able to produce process documents.
> As if producing new and different process documents is somehow
> a current problem in the IETF???
I think maybe it is, at least if part of our goal is to have our
processes described in some coherent and accessible way.
Is this the highest priority I can imagine? No. But I find the
arguments for separating this work from the more technical
publications that the RFC Editor handles and putting it under
the more direct control of the IESG and Secretariat seem to me
to be, on balance, constructive and time-saving steps.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf