RE: Progressing I-Ds Immediately Before Meetings

["Eric Gray" <[e-mail]>]

Ned,

	See below...

--
Eric Gray 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of [e-mail]
> Sent: Sunday, July 20, 2008 10:50 AM
> To: Spencer Dawkins
> Cc: [e-mail]
> Subject: Re: Progressing I-Ds Immediately Before Meetings
> 
> > I don't actually mind a two-week cutoff (it's in 2418). The 
> relevant text in
> > 2418 says
> 
> > 7.1. Session documents
> 
> >    All relevant documents to be discussed at a session should be
> >    published and available as Internet-Drafts at least two weeks
> >    before a session starts.  Any document which does not meet this 
> >    publication deadline can only be discussed in a working group 
> >    session with the specific approval of the working group chair(s).
> >    Since it is important that working group members have adequate
> >    time to review all documents, granting such an exception should
> >    only be done under unusual conditions.  The final session agenda
> >    should be posted to the working group mailing list at least two
> >    weeks before the session and sent at that time to [e-mail]
> >    for publication on the IETF web site.
> 
> Funny, I myself don't see anything in here at all about an 
> I-D cutoff. What I do see is a fairly reasonable rule 
> (I think two weeks is a bit too long, but that's a quibble) 

Actually, 2 weeks is not too long as a general rule, and maybe
not even long enough in some cases (notably this case).

Many (most?) of us have other things we need to be doing (as
you note yourself below), and having a huge dump of IDs in the 
last few days before an IETF meeting will - for many people - 
mean we haven't even had a chance to see them, let alone down-
load and read them.  Which is an excellent segue to another 
point - i.e. - in case some people haven't noticed, it can be 
hard to download drafts in the last few days before a meeting 
because the ID repository server tends to be overwhelmed by 
such requests (and a later dead-line is not going to help).

Another thing that is a clearly observable fact is that people
tend to push the deadline, and moving it to some time slightly
before the meeting - or worse, eliminating it entirely - would
be an excellent way to ensure that very few of them get posted
with a reasonable lead time to allow reading.  Again, this is
something you've also commented on below.

Finally, one thing that is likely to get worse, with current 
cost of travel getting ready to sky-rocket, is that the number
of activities that people going to an IETF meeting are likely
to be expected to participate in will increase rather than
decrease.  Hence the number of drafts that each attendee will
be expected to have read is going to increase - hence this is
probably not a good time to talk about reducing the time that
may be available to read those drafts.

> about having stuff available for review sufficiently early.
> 
> The I-D cutoff is at best a clumsy attempt to enforce this 
> rule mechanically.

Yes, it is clumsy, and mechanical.  But mechanical is not
always bad.  People frequently reconize how useless it is
to argue with a mechanism (when was the last time you found
yourself yelling at a automated voice menu system?). With 
a mechanically enforced cut-off, people are likely to feel 
that there is little opportunity for argument, so they make
a little more effort to be on time.  And THAT is a good 
thing, especaily if you would like to consider the overhead 
of addressing these arguments to the probably already hard 
job of dealing with the occasional failures of the clumsy 
mechanical submission process.  I suspect the secretariat 
feels considerable angst at having to deal with each person 
who feels that their own ID submission is the only important 
thing the secretariat has to do with their time before a 
meeting.

Also, not having the late drafts actually available before
a meeting makes the WG chairs' job easier (at least for the
most part, I believe) because it makes agenda management a
bit easier if they don't have a lot of people arguing that 
their nearly-on-time draft should be included in the agenda.

> 
> > So I don't know where the "must have AD approval for 
> > exceptions" thing came from, unless it's a misplaced 
> > need to have ADs approve everything.
> 
> You're confusing a rule with a procedure which has as one 
> purpose to try and enforce that rule. Since the procedure 
> is something implemented by the Secretariat, the question
> is what whose authority would they accept to make an
> exception. Maybe they'd accept a request from a WG chair. 
> Or maybe not.
> 
> But let's suppose we can get ADs out of the exception 
> process. As Dave pointed out last night, the real problem
> is having to make such exceptions, and this still doesn't
> fix that.
> 
> > If ADs do discover copious and uncharted spare time, I 
> > would MUCH prefer that they spend it steering their
> > working groups, and specifically noticing milestone
> > offsets so we can move away from the current situation,
> > where many so many milestones are expressed in terms of
> > ID cutoffs for the next  meeting, more than half the
> > updates are posted within two weeks of the ID cutoff, 
> > and we're floundering through the drafts getting ready
> > for the meetings.
> 
> This is a consequence of the RFC 2418 rule and more generally 
> of the way our process revolves around our meetings. And while
> I share your dislike here, I don't think making exceptions to
> the cutoff or getting rid of it entirely will change this in
> any significant way. We're all busy, IETF work is not the
> primary thing most of us do, and it is simple human nature to 
> wait until the last minute to do stuff.

This confuses me.  Above, you say that 2 weeks is "a bit too
long" - yet here you're making a strong argument for having
as long a lead time as possible.  What do you really want?

> 
> > I am particularly irritated when I see a draft that I 
> > submitted comments on immediately after the last IETF 
> > meeting (which was a long time ago), updated for the 
> > first time within a week of the ID cutoff for the next
> > meeting. This does not give us timely publication - we
> > can't even remember what we were talking about, in some
> > cases.
> 
> An argument for doing less work at meetings and more work on 
> mailing lists, perhaps, but again I don't see how any sort
> of change to the cutoff rule can fix this.
> 
> > I do, of course, appreciate working group chairs that do 
> > stagger their milestones,
> 
> You know, it is interesting you should say that, because if 
> it is true it highlights how different parts of the IETF work
> quite differently.
> 
> In most of the groups I participate in nobody pays any 
> attention at all to milestone dates. When a group meets
> it considers the documents that are ready to be considered,
> not the ones that the schedule says must be considered.
> Prodding by chairs to meet milestone dates is practically 
> unheard of.  And lots of these groups have milestone lists
> with missed dates. (In fact I believe there have been cases
> of milestones seven years or more out of date.)

I think all that you say in the above two paragraphs is true 
in a lot of working groups, and this is something that many
people probably would like to see fixed - rather than used as
an excuse for continuing with the current bad behavior.

The IETF needs to work toward being slightly more predictable
in its deliverables, given the way that some IETF delays tend 
to be directly translated into delays in other sectors of the 
industry.

This is something we need to work on, if we want to drive the
Internet standards of the future.  Driving the process based
on "the documents that are ready" - without a conscious effort 
(and focus) to ensure that the right documents are the ones 
"that are ready" is a recipe for making the IETF a paper
outlet for quasi-interesting rumours about what a subset of
Internet products and services are doing already.

If the IETF continues to foster processes and behaviors leading 
to inaccurate reporting of de facto standards - instead of ways
to define those standards - it is headed for its own "historical" 
status.

> 
> 				Ned
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
> 
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf