Well, I know it seems like I just asked this, but I've gotten the periodic
nudge from the IETF secretariat that's issued prior to IETF agenda
scheduling, saying 'do you want to schedule something at Minneapolis?' The
March meeting kinda sneaks up on you.
The dates, FYI, are March 15-19th. Yes, just about sixty days away. The
next meetings after this are in July in Norway, and in November in
Washington (DC). The next meeting after that is in March 2000, in Adelaide,
Australia. The next North American meeting after that won't be until at
least the third quarter of 2000, insofar as I know.
For practical purposes, then, for most North American participants, I think
we've got our choice of Minneapolis in March or Washington in November for
any possible short-term BOF or WG meetings.
I'd again remind the list that we've had one formal BOF already; we're
allowed a maximum of two on the same topic, after which we go to WG or
abandon-in-place, at least to the extent that we won't get another shot at
an IETF agenda slot on the same topic.
We have to get Area Director (Patrik and Keith's) approval for any proposed
scheduling request, I would note, so it's probably best to talk about this
right away.
Following our informal meeting at Orlando (see Tim's message from 12/7/98
titled 'Sieve Meeting Notes'), I personally think we're in very good shape
with respect to 'Sieve 1.0'. (I'm calling the current draft 'Sieve 1.0' to
mean the future, final version of what we're working on now.) We've got
multiple implementations from a variety of client and server vendors
underway, agreement on the base spec's scope and much of the details, and
it seems like we're down to more minor issues on the list. This leads me to
believe more than ever that a formal working group is NOT necessary.
There's just not enough stuff to go through to justify a full working
group, imho.
When we had the formal BOF in LA last year [see 'LA IETF BOF Notes',
Laurence Linblade, 4/1/98], there were a lot of what I would call
scope-creep discussions.
Here, quoted as reported by Laurence in the minutes, is what we concluded
on 3/31/98:
There was good humming(tm) about going forward on sieve in general.
Roughly equal humming in favor and opposed to forming a working
group. Those opposed said:
- will take too long
- not baked enough to start a working group
- will thrash if we don't have something more cooked
Course of action decided on is to work on sieve in the mailing list,
come up with another draft and consider a working group in a few
months after things are more cooked.
The fact that these newer suggestions either did not percolate up on the
list in detail or have been rejected by list participants since makes me
think that while there may have been many valid points raised, they weren't
fundamental to the 'Sieve 1.0' concept, as evidence by the number of
implementations in progress that do not incorporate.
So I'd basically propose, and seek discussion and response from the list,
that we have three options:
(1) schedule a second BOF for Minneapolis.
My theory is that this will provide another opportunity for an open-door
meeting, but we'll have implementation experience at that point. If a
second BOF isn't sufficient to complete the bulk of work by that point,
then that suggests we might actually need formal WG status after all. So at
the end of the meeting in Minneapolis, we'd have three possible outcomes:
(a) set a timetable to submit the Sieve draft to the IESG as a Proposed
Standard,
(b) agree to a charter for a WG, or
(c) defer and/or abandon the work in place.
(2) defer another BOF, reserving Washington in November (+six months) as a
potential meeting time.
This would have the advantage of being 8 months in the future instead of
two, so presumably more work would have been done by then, and it may turn
out the meeting isn't at all necessary after all0.
(3) not plan to meet.
If we don't have to, why bother?
My instinct at this point is to go for option (1), with a goal of (1a),
getting the document, as amended in this next BOF, to standards track
submission, bypassing a working group.
My rationale:
-- the clear consensus of the last few meetings we've had are that sooner
is much, much better for a relatively simple specification, and we all need
this yesterday. To my mind, this means getting whatever IETF open meeting
we need to have scheduled at the earliest opportunity.
I would also note that given the two non-North American meetings coming up
in the next four, it may be that other activities (perhaps as yet
unforseen) may distract our individual and collective attentions, so it may
be best to meet sooner.
-- my .02 units is that the document is in very decent shape, thus worthy
of attention now.
-- Next question: wy bother with another BOF? I believe scrutiny of the
broader community in a second BOF will help both the document and getting
it to Proposed Standard ASAP by further exposing it to the community
(especially if we do NOT procrastinate and submit a revised document at the
last minute, but get it out at least 4-6 weeks in advance of the meeting).
Possible objection: won't we just get meeting hoppers at this BOF who will
make the same proposals for complexifying the document we got last year,
who will then go away and not show up on the list again, thus delaying us
even further? Response: The difference between this meeting and a year ago
will be we will have multiple working implementations to demonstrate the
running-code part, to try to make the point that further complication of
the spec would simply delay presently-available functionality, and that it
would be more adequate to declare the rough-consensus part in submitting
the document to the IESG for consideration as straight-to-proposed.
-- if we don't get good consensus on the document at that point, we'd
probably have difficulty getting the IESG to approve straight-to-standard
anyway, at which point we'd have to get up a WG anyway to continue.
So, please, can I have a quick show of e-hands indicating which of the
above options, (1), (2), or (3), seems best to each of you.
We need an idea of whether to make a scheduling request within the next
week or ten days. Please chime in as soon as you can.
- Matt