Re: Progressing I-Ds Immediately Before Meetings

Hi, Ned,


> > 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
Agreed.

> do see is a fairly reasonable rule (I think two weeks is a bit too long, 
> but
> that's a quibble) about having stuff available for review sufficiently 
> early.
Agreed with "fairly reasonable".

> The I-D cutoff is at best a clumsy attempt to enforce this rule 
> mechanically.
I'm sure.

> > 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.
Probably. I've been confused about this before.

> 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.
I probably wasn't being clear enough - I don't disagree with Dave here, what 
I was saying was that we were arguing about (please tell me if I'm doing a 
better job of saying this) a procedure that was intended to enforce a fairly 
reasonable rule mechanically), and the conversation seemed to assume that AD 
approval would be required for exceptions, which wasn't required by the rule 
that the mechanical procedure was intended to enforce.
I am sympathetic to the idea that the rule is more Procrustean than it needs 
to be, in addition to the procedure requiring something that the rule 
doesn't require (please tell me if you think I'm agreeing with you, because 
I think I am).
> > 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.
Agreed. My attempted point was that I could think of things that I'd prefer 
to see ADs doing, rather than worrying about "exceptions".
One of my earliest process memories at IETF was in Munich (IIRC), where an 
IAB member and primary document author had submitted a draft by e-mail 
several *minutes* after the I-D cutoff, and people seemed to think that 
missing the cutoff prevented the working group from discussing the draft. I 
was confused by that memory into thinking that exceptions weren't possible, 
for several years thereafter. I was wrong, but I wasn't the only person who 
thought that, at the time.
> 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.
Agreed. I am wondering why we all have to have the same "last minute", only 
once per IETF cycle, but if we're going to enforce rules mechanically 
through procedures that don't quite seem to match the rules, I guess we're 
getting what we deserve.
> > 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.
Agreed. I was still thinking of more consistent milestone steering, not that 
changes to the cutoff rule would affect how often drafts were updated. Sorry 
that I didn't make this clearer.
Interesting that you would go off to the land of "more work on mailing 
lists". That would be lovely. I remember Harald talking about the absence of 
working group mailing list traffic for months between IETFs, for working 
groups that met at both IETFs, as a not-terribly-healthy sign.
> > I do, of course, appreciate working group chairs that do stagger their
> > milestones,
> Youi know, it is interesting you should say that, because if it is true
> it highlights how different parts of the IETF work quite diferently.
>
> 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 charis 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.)
Agreed.

Thanks for your note, and for the opportunity to (once again attempt to) say 
what I was thinking more clearly. The communication problem may not be in 
your receiver, of course :-(
Spencer 

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