Community time as a limited asset (was: Re: Last Call: <draft-yevstifeyev-ion-report-06.txt> (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Wednesday, July 13, 2011 10:20 +1200 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:

> Mykyta,
> 
> I think the draft is fine without this addition, which
> contains some statements that I disagree with. I don't think
> analysis is needed; this is all ancient history anyway.

Brian and others,

I think your note, when combined with this document, identifies
a much broader issue that I think we need to start considering
more carefully.

The number of people in the community who actually do work and
who, in particular, feel obligated to review every Last Call
about which they might have knowledge, to make constructive
comments, etc., is not very large.  By definition, they have
finite time.  Relatively few of us have the luxury historically
accorded academics (students and faculty alike) of being able to
set priorities independent of intrusive external complaints
(many academics don't have that luxury any more either).

If we want the specifications and documents that really do need
careful attention, review from different perspectives, etc., to
get that time, then, IMO, we have to start becoming more
disciplined about identifying what is really important...
especially in times when available resources seem to be
shrinking rather than increasing.  Our questions need to include
not only "is this correct" and "does it address an issue that is
either known or that it identifies" but "is it actually
important".

I would hope that much of that discipline could be applied by
authors exercising judgment and maturity.  However, if it is
not, I would hope that IESG members considering whether or not
to sponsor individual contributions would assume that an hour
that goes into reviewing one document (even one that is
unimportant in the grand scheme of things) is an hour that isn't
going to go into reviewing another one, especially one that
might, through the week of the draw, be announced right after
someone has used up all of her available IETF time for a while.  

So, my conclusion about this particular document is ultimately
identical to yours: this is all ancient history anyway (and, by
the way, the IESG has already issued a statement on the
subject).  But that conclusion leads me to disagree with you:
"ancient history" doesn't imply that we should publish the
document, it implies that we should stop wasting time and drop
it.

When I express agreement with Harald's call for more analysis
that might lead us to avoid similar attempts in the future (if,
indeed, IONs were a mistake), it is not because I think that
work would be worth publishing.  I would be much more likely to
still come down on the side of "ancient history; let's not waste
time having a Last Call, discussing it, and publishing".   But
at least in Harald's model we'd be publishing some serious
analysis and new information that would add to the record.  I
don't see this document, freed of all or most analysis, adding a
thing to the existing IESG Statement.  And that makes it a
bigger use of community time, RFC Editing resources, etc.

In case it isn't clear, while this particular document inspired
this comment, the comment applies with equal force to, e.g.,
reclassifying RFCs that are even more ancient history and about
which no one is paying attention any more.  We can do it, the
reclassifications are usually correct technically and
procedurally, but processing them is justified only if we assume
that the community has infinite time and resources and/or that
time spent on something like those efforts isn't time taken away
from other things.

    john


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]