> > 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). That may well be true sometimes, like when a massive and complex new document is first introduced. But by the same token, in lots of cases it is too long, such as when a longstanding document receives a minor update. I think on average it is too long, which is why I made the side remark I did. But in any case i'm not proposing changing the two week limitt. > 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). You're confusing multiple things and are failing to acknowledge the reality of the situation. Thow in a few straw men to boot and it is difficult to even formulate a response to this. The I-Ds are going to get written or revised whenever the authors want to do so, and right now that's often right before a meeting. We have no control over that. The I-Ds are going to get posted somewhere if the authors so desire. Again, we hwat no control over that. We do have control over what's actually considered at a meeting, so if an author brings up a documeent that missed the deadline we can refuse to consider it. Apparently this happens in some groups, but while I've seen many cases where documents that missed the deadlines were brought up, I cannot recall a single case where the group refused to discuss it because of that. (FWIW, I"ve also seen plenty of cases where a document could not be considered because nobody had read it, but this includes quite a few documents posted months before the deadline. So much for the other side of the "if it is there soon enough we'll read it" contract.) The bottom line is that the only things we have control over are are our meeting agendas and the official repository. I'm arging that attempting to control agendas with repository rules is a losing proposition. That's all. In particular, I'm not saying that having a rule about material that's going to be considered be available in advannce is a bad idea, and your apparently making arguments against removing such a rule is nothing but a straw man. > 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. The fact that our work schedules revolve around our meeting dates is the root cause of a number of serious problems, but fidding with that opens a huge can of worms. While we may lament the effect it has, nobody is proposing any changes in this area AFAIK. Nor is anybody proposing a change to RFC 2418 rules. Again, this is a strawman of your own making. > 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. Increased travel costs may impact us in a numbvr of ways, although I'm very skeptical it will produce the results you claim it will. (A far more likely outcome is that attendence drops dramatically while remote attendance escalates, with all that implies.) It may in fact eventually force us to open that aforementioned can of worms. But that's a separate discussion for a different day. > > 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?). You know, that's an excellent example, because what happens in practice is that if these sorts of automated systems are too cumbersome people simply route around them just like they route around the cutoff now: They hit "0", forcing costly manual intervention for routing purposes, they use some other means of communication, or they may even game the system by dialing extensions or other tricks. (Yes, I'm guilty of multiple counts of all three, and quite proud of my serial offender status.) As for yelling, its going to be at whoever they end up talking to. I would not want to be the person actually taking orders at Herb's World of Junk (in Moonsocket, Rhode Island), would you? > 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. Let's just say you have a much better opinion of human nature than I do. > ... > > 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? Again, AFAIK nobody is proposing changing the two week rule. But to answer your question, the rule has to strike a balance - if the gap is too long too many documents will miss and too many exceptions will have to be made in the groups themselves. I happen to think two weeks is a bit too long on average. > ... > > 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. This is really off topic, but since you brought it up... No doubt you'd like to see more rules added to try and get rid of what you see as "bad behavior". This is exactly what we should not be doing. What we should do instead is to take a close look at why milestone dates are not being used in any meaningful ways by a lot of groups and see what changes make sense to address that. Perhaps more rules are indeed needed to force groups to use these dates, but I think that's a very unlikely outcome. I haven't given this any serious consideration, but the place where I'd look for a solution to this particular problem would be to completely rethink the relationship between groups, drafts, and milestones, in the process getting rid of some update rules we currently have. In particular, for draft-related milestones, tie the updating to the draft itself, not the group's charter, and give the author/editor the ability to update the milestones for their own drafts. Maybe even make it automatic - when a revision is posted check to see if there are related milestones and right then and there ask if this revision addresses any of them. Again, this is just off the top of my head. But I think fewer rules and more automation are where the answer lies. > 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. Agreed, but it is going to be extremely difficult to do in a volunteer organization. And I don't think making more rules will help. > 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. And I see all the rules we have accreted as helping us along that path at an ever-accelerating pace. Ned _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf