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

[Barry Leiba <[e-mail]>]

I think John has it exactly right here.  What we really need it for
document shepherds and responsible ADs to agree on a suitable Last Call
period.

Perhaps there should be a question added to the shepherd writeup asking if
the document is long or complex, or otherwise might need extra time in Last
Call.  And then let the responsible parties go from there.

Barry

On Fri, Oct 18, 2024 at 8:07 AM John C Klensin <[e-mail]> wrote:

>
>
> --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
>
>
>