ietf
[Top] [All Lists]

RE: Progressing I-Ds Immediately Before Meetings

2008-07-21 07:28:51
Ned,

        See below...

--
Eric Gray 

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On 
Behalf Of ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com
Sent: Sunday, July 20, 2008 10:50 AM
To: Spencer Dawkins
Cc: ietf(_at_)ietf(_dot_)org
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 
agenda(_at_)ietf(_dot_)org
   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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf