RE: Progressing I-Ds Immediately Before Meetings

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

Ned,

	Just to be clear, my last response below was to the notion 
that it is okay for a working group to consider the drafts that 
are ready to be considered, as opposed to those that are nearing 
(or past) their milestones.  This was how you responded to part 
of Spencer's (I think) assertion that some WG chairs do try to 
create reasonable schedules (i.e - the reference to staggered 
milestones, which has been elided below).

	You seemed to be saying that such effort is wasted in your
experience.

	Also, I was not asserting that any existing rules are in
place to help with that, nor do I think automated rules would be 
likely to help.  But I do think that working group chairs and 
(where necessary) area directors should invest some effort in 
ensuring that the work is progressing to schedule and that one 
of the ways to do that is to create schedules that make sense.  

	Assuming the schedules do make sense, sticking to a schedule 
- it seems to me - would be easier if the working group were to 
work on things based on where they should be (from the schedule), 
as opposed to where they are.  And that would mean it would be a 
more productive use of a working group's time to spend it trying
to determine why a draft that should be at a certain point is not 
at that point than to spend an equivalent amount of time discussing 
work that just happens to be ready to discuss.

	There are issues with this, particularly in an all-volunteer
organization.  But let's face the fact that the IETF is a volunteer
organization - for the most part - in name only.  Most people don't
have to have their arms twisted to be a WG chair (or AD) in an IETF
WG (or Area) in which their employer has interest, and the people
who are doing the work in the working groups are - mostly - not
doing it for free either.  People are certainly not getting enough 
compensation for the work they're doing in the IETF, but I think it
unlikely that it would be impossible to get people to continue to
do it if there was the additional cost of doing it according to a
set of milestones, according to a plan they themselves helped to 
set up...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Ned Freed [mailto:[e-mail]] 
> Sent: Monday, July 21, 2008 11:02 AM
> To: Eric Gray
> Cc: [e-mail]; Spencer Dawkins; [e-mail]
> Subject: RE: Progressing I-Ds Immediately Before Meetings
> Importance: High
> 
> > > 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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf