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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf