John C Klensin wrote:
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 documents that the community does not see before approval, there
will obviously be no delay in publication because of public discussion.
Some IONs will be appropriate for such processing. Some will not be.
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.
If the published document is identical to the approved document, there
is no post-approval editing.
# 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.
Today's practice is that several of the documents that could qualify for
the ION series are published as HTML (web pages) - sometimes as the
output of the "note" variant of xml2rfc. I did not want to force what
some people would think of as a step backwards on those documents.
# 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.
What I was getting at was that an Info document (like the IESG charter,
or the RFC Editor's instructions to authors) has no stable identifier
except its current RFC number. If there is a new version, there is no
stable identifier that will continue to point to the "current" version.
# 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.
I'll happily leave the discussion of RFCs to Techspec. My intention was
to get something done about operational notes, not to change the RFC series.
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.
IONs are not a very big deal. But unlike some of our other problems that
need solving, it seems to be possible to make things a little bit better
in this area.
And after running the experiment for 12 months, we *might* know more
about how it works.
Harald
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf