limiting reading load

[Steve Bellovin <smb@research.att.com>]

Let me restate a proposal I mentioned in passing in December:  let's 
cap the number of pages on any one telechat's agenda.  This call's load 
is preposterous -- about 585 pages, by my calculations, much of which 
wasn't scheduled until about a week ago.  There's no way we can do 
careful analysis on that much material.  

Let me suggest the following algorithm.  We set a cap at, say, 300 
pages.  (We'll adjust that number with experience.)  And it will be 
arbitrarily adjustable by the chair after the usual groveling.  After 
the first I-D that takes us over the limit, the read list for that call 
is closed; further documents go to the head of the queue for the next 
call.

If we want, we can scale the page count by the lead-time -- pages that 
are marked for reading two weeks in advance count for less than ones 
that show up on Friday.  Returning documents count for much less.  Etc.
But if we go too far down that path, we'll need a protocol definition 
and a MIB...

Forgive me -- I'm grouchy this morning for lots of reasons, not nearly 
all of which are attributable to how late I was up last night reading 
I-Ds or to my wife's situation.  But as I said, I first made this 
suggestion in December.  (I'd suggest adding it to the agenda as a 
management item, but I'm not convinced we're going to get to that part 
of the agenda today...)


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)