--On Monday, 22 May, 2006 09:17 -0700 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:
> John C Klensin wrote:
>>>> For #1, it removes the requirements for Last Call and
>>>> demonstration of community consensus that apply to BCPs.
>>
>>> In other words, these are IESG Operational Notes, not IETF
>>> Operational Notes.
>>
>> Some of them certainly are. Some of them aren't what I would
>> describe as "operational notes" at all. Others might well be
>> IAOC documents, secretariat procedural documents, or basic
>> IETF consensus documents that specify the standards process.
>> But creating separate document sets for each of those
>> hair-splitting categories doesn't seem consistent with either
>> efficiency or keeping a primary focus on products.
> If they are not all operational notes, then the series should
> not be called operational notes.
I can't speak for Harald or the IESG, but I would personally
welcome a constructive suggestion.
> Whatever their source and whatever their focus, they are
> approved by the IESG and not the IETF. They are roughly
> equivalent to Presidential Executive Orders, in the U.S. That
> is rather different from a law or constitutional amendment.
Since it is not relevant to this thread, I will skip making an
obvious comment about the present Administration and its
attitudes and behavior. But I would have chosen other analogies.
Regardless of that, in the IETF, the IETF doesn't really approve
anything. We can't, we don't vote. What we do is to charge the
IESG with interpreting community consensus and making decisions
on behalf of the IETF based on that consensus. Historically,
looking at practices rather than documented procedures, the IESG
has done that in three ways:
(1) Issue a Last Call, review the comments and general
impressions of community opinion, and decide on that basis.
(2) Decide what they community would like, or on a procedure
consistent with community inclinations, and then announce it...
without a Last Call but presumably subject to appeal.
(3) Decide what they would like, assume that what they want is
either consistent with what the community wants, or consistent
with what the community would want if it were better informed,
or that their preferences supercede any preferences the
community might have, then optionally announce it and, announced
or not, assume that the decision is not subject to appeal.
Now, as I read the I-D, it isn't intended to have any procedural
impact at all. I think it might reinforce a general trend to
get rid of the third category, pushing things that might
previously have been handled that way into the second one. If
it does, I think that would be A Good Thing.
But I find an effort to distinguish between the first two
categories in terms of what is "IESG approval" and what is "IETF
approval" to be unpersuasive. For relatively minor procedural
changes or specification of details, I actually prefer the
second because I think it wastes less of the community's time.
If the IESG can't get "relatively minor" right, I think we have
other problems that document categories are not going to fix.
And I continue to be a little surprised that we are disagreeing
about this one: mutual teasing notwithstanding, I'm usually
reasonably good at predicting where we will disagree, and would
not have predicted this one. To me, it seems like a fairly
low-impact way to excise the wart of having IETF procedures,
technical recommendations, and applicability statements
intermixed under the "BCP" label; to reduce slightly the load on
work on the RFC Editor and permit them to concentrate a larger
fraction of resources on the types of output we both consider
productive; and to get more of the IETF procedural stuff out in
the sunshine and organized so it can be found.
I don't think it is hugely important or that its impact will be
very significant: if we didn't have yet another revision to the
the IPR rules coming up, a revision to RFC 2223 bouncing arouhd
the system along with the techspec draft, my "independent
submissions" draft, and some other RFC Editor procedures in the
pipe, and pressure mounting for a comprehensive revision of RFC
2026, I might contend it wasn't worth the trouble to make any
change at all (and I expect all, or nearly all, of those
documents to be subject to at least an approximation to Last
Call). But precisely because those things are in the queue and
the details that will follow them are probably not far behind,
it feels to me that may be the right time to do this and see if
it accomplishes anything useful.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf