Ned, See below... -- Eric Gray > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of ned+ietf@xxxxxxxxxxxxxxxxx > Sent: Sunday, July 20, 2008 10:50 AM > To: Spencer Dawkins > Cc: ietf@xxxxxxxx > 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@xxxxxxxx > > 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf