Re: Telechat reviews [Re: Tooling glitch in Last Call announcements and records]

[John C Klensin <[e-mail]>]

--On Thursday, October 17, 2024 20:46 +0000 "Salz, Rich"
<[e-mail]> wrote:

>> We should make it a general policy to add two weeks to the last
>> call period when a document is long, for some value of "long" (I
>> might say over 60 pages of substance (not counting change logs and
>> such)).
> 
>> We decided on the two-week last call period at a different time,
>> when the IETF was a different organization. Maybe we should
>> re-think it now, and keep in mind that an extra two weeks of
>> last-call review is *not* going to be the most significant delay
>> in a document's life cycle.
> 
> RFC 2026 in Section 6.1.2 says "at least two weeks". This language
> is preserved in the 2026bis document[1]. I guess the IESG can just
> make a rule and promulgate it.
> 
> 
> [1]
> https://www.ietf.org/archive/id/draft-rsalz-2026bis-12.html#section
> -8.1.1-1

Rich, thinking about that, my prior reaction to Barry's suggestion,
and a couple of offlist discussions, I reach a different conclusion.

I think a "general policy", even if the IESG could make such a rule,
would be a bad idea.  We should start by remembering that the IETF
has already been criticized for being too slow and that some work
that probably should have come here has not done so because of that.
Equally important, while watching the debate about exactly how long a
document is allowed to be before the Last Call period time doubles
might be very amusing, I doubt that it would be productive.

The reality is that we have short documents that are very complex and
that should get  extra time and long documents that are quite
straightforward and can be handled quickly (often either because they
are really short documents with lots of pictures and examples or
because they are replacements for previous documents where most of a
review can be done from diffs).   So let me suggest something else
that takes advantage of the flexibility you cite and perhaps the
spirit or Barry's suggestion.

* Nothing has ever prevented an AD from insisting on selected reviews
before releasing a document into IETF Last Call.  Possibly we should
remind them that, when faced with a document that is complex and/or
likely to take a long time to review, they may want to take advantage
of that.

* Nothing prevents an AD from deciding that a particular document is
complex, long, or likely to require extra effort and attention and
persuading the IESG to issue a three week, four week, or even longer
Last Call.  That could be particularly important if there were
reasons to consult an external organization about a document that
might be seen as overlapping with their work.  I think it would be
nice if an announcement of an extended Last Call contained the reason
for it, but I don't thing a rule is needed there either.

* Nothing prevents a reviewer, or a review team leader, from going to
the relevant AD and saying "this one is going to need extra time
because...".  If the AD (or the IESG) agrees, I don't think anything
prevents extending a Last Call after it has started.  That has been
done informally many times; perhaps we should move toward having it
leaves tracks in the datatracker.

With the possible exception of having the think about, and then
implement as needed, whatever is needed in the datatracker to allow
those flexibilities, no changes of rules or policies are needed only,
perhaps, an occasional reminder to ADs that they do have those
flexibilities and maybe should take advantage of them when
circumstances seem to require doing so.

   john