--On Tuesday, July 06, 2010 08:23 -0700 Dave CROCKER
<dhc2@xxxxxxxxxxxx> wrote:
> On 7/5/2010 10:17 PM, Brian E Carpenter wrote:
>> On 2010-07-06 08:49, SM wrote:
>> Although the IETF Chair is also an IETF participant, it can be
>>> perceived as problematic when the person writes a
>>> non-technical proposal that has to be evaluated by the IESG.
>>
>> It could be, but if the proposal is a matter of common sense
>> and blindingly obvious simplification, it isn't, IMHO. Let's
>> just do it; there is no down side. There may be many other
>> issues, as suggested by John, but this simplification can
>> only help everybody.
> Brian,
>
> I agree that there seems to be quite a bit of blindness in the
> way this is being discussed. This is something for which
> there is no urgency, and about both the needs and the benefits
> being offered are squishy, at best. Added to this is
> unfortunately strong resistance to serious discussion and
> consideration of concerns and questions being raised.
>
> The assertion that it is possible to take a core construct
> that has been in place for 20 years, and that making a change
> that is certain to have no downsides, is an example of the
> problem in the current process.
>
> This sort of change has costs. /ANY/ change has costs. It
> does not necessarily have any benefits. At the least, there
> should be careful attention to the implementation effort and
> the potential impact on community use of labels.
>
> Also at the least, folks who are promoting this need to
> produce a compelling benefit statement. So far, that's
> lacking.
Brian,
I largely agree with Dave. In fact, I can't see any aspect of
this where we disagree. But I think I would go further in a
few respects:
(1) We know from experience that the community is easily
exhausted when dealing with process matters. If approving this
left us unable to consider more fundamental changes -- changes
that would actually solve problems that we can identify-- that
would be a very significant "down side".
(2) Independent of the question of community energy and
bandwidth, no one has done an analysis of whether these changes
would make it easier or harder to address and solve other (or,
if you prefer, "real") problems. If the answer were "harder",
then that would be a very significant "down side" -- almost
certainly sufficient to justify rejecting this proposal. That
is not a matter of the best being the enemy of the good. It is
more a matter of a quick patch being the enemy of any real
solution to any real problem.
(3) While I'm as offended as anyone else by the continued
presence of the never-used RFC 2026 "advance in grade or die"
provision, if that were really the problem, the "common sense
and blindingly obvious simplification" would be to explicitly
deprecate that provision, replacing it with nothing, and do
nothing else. If that had been proposed, I wouldn't be
objecting. But the actual proposal is neither [obviously]
common sense nor a blindingly obvious simplification. It isn't
clear to me that, statistically, it would be a simplification in
practice at all. Yes, it means one fewer pass through the IESG
for a relatively small number of documents, but the IESG's
treatment of Proposed Standards in excess of what 2026
anticipates could lead a reasonable person to predict that the
only real effects of this proposal would be to eliminate one
level and, over time, cause the IESG to drastically increase the
de facto requirements for the second level. That would not be a
simplification in practice, much less a "blindingly obvious" one.
I don't know if the reading is correct, but one way to read the
proposal is that the goal is to make life a bit easier for the
IESG. The IETF's job is to make the Internet work better -- and
that includes, IMO, a whole series of things about more timely
and accurate documents with clear status. I can think of ways
to make the IESG's job easier -- some probably worthwhile,
although, with one exception, I wouldn't go as far as "common
sense and blindingly obvious"-- but that goal should be
secondary to the needs of the Internet. (The exception might be
described as "the IESG should stop making extra work for itself
and then complaining about it", with, in this context, the
threshold for approval of Proposed Standards above and beyond
what 2026 anticipates and doing editing work that could be left
to the professionals of the RFC Editor function, heading that
list.)
> ps. SM raises a concern that falls under the category of
> conflict of interest. This is something that does not
> require bad intent or bad action; it merely requires
> potentially competing goals (interests). Having a proposal's
> proponent also be in charge of a proposal's approval is the
> essence of conflict of interest.
+1
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf