--On Tuesday, June 23, 2009 09:54 +0200 Simon Josefsson
<simon@xxxxxxxxxxxxx> wrote:
> Marshall Eubanks <tme@xxxxxxxxxxxxxx> writes:
>
>> 2.e -- the review period for TLP changes has been changed
>> from 30 to 14 days, which is consistent with the last-call
>> period for other IETF documents
>
> John gave several reasons why this isn't good justification,
> and I agree with them. Reading his thoughts, my opinion is
> that changing the time frame from 30 to 14 days is a change in
> the wrong direction considering that these documents are not
> developed in an open way and that the IETF community may want
> to ask their lawyers to review the changes before responding.
> In my experience, getting those answers takes significantly
> more time than 14 days.
One additional comment on the review period and IAOC/Trustee
style of working more generally:
If one has to carefully review legal provisions, consult counsel
and others, and then comment with care and, when possible,
suggest alternate text, a review period of 14 days after one
first gets a hint that there will be document posted and seeing
the document falls into the "fire drill" category --I believe
faster than we require for any other document review in IETF or
IETF-related contexts. While I assume that the Trustees would
be careful to avoid it if possible, holidays, vacation periods,
day-job project deadlines, and conflicts with other meetings can
easily turn 14 days into almost nothing, effectively providing
some portions of the community (not just individuals) with no
opportunity for review.
This is not a topic on which we want to have fire drills if they
can possibly be avoided. We've repeatedly discovered that
inadequate review of IPR documents gets us documents that need
to be revised and retuned again, a process that wastes time and
creates confusion about exactly what provisions apply to which
documents. We have even has reviews that turn out to be
inadequate when WG processes have been used with multiple I-Ds,
open community discussion of drafts, public information about
what was going into Last Call and what was not, and so on.
However, after a few hour's thought, I believe that the basic
problem here isn't the difference between a two or four week
review window (although I still believe that two weeks is too
short). The problem is that the IETF develops documents by
iteration before going into a Last Call/ Final Review process.
Our assumption is that Last Calls are intended as a last chance
to take another look at a document (not a first look) to catch
previously undetected and fairly serious problems... problems
that we assume won't be there because they would have been
caught in the iteration process.
The Trustees (and IAOC) have not been operating in that style.
Instead, we get documents like this one (and, as another
example, some of the RFC Editor-related materials) that are
thrown over the wall to the community with notes that
effectively say "we've finished this, you have NN days to
comment, after which we expect to make whatever changes we have
been persuaded to make and approve it". In fairness, when the
changes have been significant enough, the community has usually
been given an opportunity to review them before final adoption,
but that is not required by these "here it comes over the wall"
statements and notes and the associated intended adoption dates.
This "throw it over the wall" model would be ok pragmatically if
the IAOC/Trustees almost always got things right. After all,
the plan and hope for the IASA is that it would permit the IETF
community from having to deal with administrative details. But,
using this draft with the serious problem Simon spotted and the
minor "no justification for adding boilerplate" one that I
spotted as the most recent of what have been many examples, it
appears that the IAOC/Trustees are composed of human beings with
many other things on their minds and calendars rather than of
infallible entities. That is no surprise and not a criticism of
any of them, but it may call for some rethinking beyond
discussion of dates.
I have realized in thinking about this that my several irritated
note to or about the IAOC/Trustees in the last year or so have
been a result of this situation: if a document is going to be
thrown over the wall for this kind of final review (or, in the
more common cases, for IETF Last Call), I believe that the
community has the right to expect that it will be refined enough
that finding serious problems will be a rare event. If
documents regularly come over the IASA/IETF wall that contain
significant problems or issues, then either the IAOC is not
doing its job or the review model is wrong. While I apologize
for the irritated tone of some of those notes (probably
including the note I wrote several hours ago), the "not doing
the job" problem seems quite real.
I propose that, once the Trustees (or IAOC) have a preliminary
version of a document ready that they should post that document
for preliminary review, ideally as an draft-iaoc-... or
draft-ietftrust-... I-D, not a link to a web site. That posting
should be followed by discussion between the IAOC and interested
participants in the community, iteration on that discussion as
needed, and posting of new drafts as appropriate. Only after
that discussion and iteration process have stabilized is it
appropriate for the Trustees (or IAOC) to issue a Last Call or
anything else that bears specific intent to adopt, target
adoption dates, etc.
I would favor giving the IAOC and Trustees authority to do
something that shortcuts the above process by declaring that the
situation is an emergency but, to protect the community's
consensus processes and maintain accountability, such a
declaration should require a recorded vote with an extraordinary
majority that includes both the IESG and IAB representatives
voting for approval.
Assuming that I'm not the only one who sees the recent patterns
as problematic, are the IAOC and Trustees willing to consider
procedures equivalent to the above on an informal basis or is it
necessary to open BCP 101?
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf