Subject: RE: [seamoby] Seamoby Charter Last Call

From: "Gary Kenward" <[email-masked]>
Date: Mon, 14 May 2001 14:35:00 -0400

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Monday, May 14, 2001 1:14 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; [email-masked]
> Subject: Re: [seamoby] Seamoby Charter Last Call
> 
> 
> On Mon, May 14, 2001 at 01:08:46PM -0400, Gary Kenward wrote:
> > Ok. So, in the interest of moving on, I propose that
> > we set June 8 as the deadline for the working group
> > requirements draft. That allows 4 weeks for the ct
> > team to finish the draft and the wg to review. As I 
> > indicated, the dt should be ready to release the reqs
> > draft this week.
> 
> ok, but let me turn this around. Let's assume that someone in 
> the Working
> Group needs changes, and getting the spec off to the IESG 
> takes an additional
> month (a week to discuss, a week to update specs and post, 
> and another 2 week
> last call), then we end up being late again.
> 
> What, exactly, is the problem with adding a cushion to the 
> milestones that 
> will allow us the time to work on the spec, if we need it.

The problem was the size of the cushion. I clearly mis-understood
the purpose of the milestones, which is to identify the point
at which the drafts are approved by the IESG? (I don't know how or
why one would want to predict such an event ;^}, but so be it).

As long as we can proceed with the solutions work before the end
of May. I think everything that needs to be said about requirements
has been voiced one way or the other. Yes, there is probably more
requirements to come out later on, but it's not worth waiting for
that possibility to happen.

> 
> Even if the milestones states that the spec isn't to be ready 
> by November,
> and it is ready next month, then we are early, scratch off 
> the item from
> the list, and move on.
> 
> Can we, somehow, negotiate a date somewhere between your 
> (much too agressive)
> June 8th, and my (perhaps too far out to accomodate a possible interim
> meeting) date? How about July?
> 
> Again, if we are done early, we just look better.

Having had many project roles, I realize the value of setting milestones
that you can meet. In my experience, if you pad the schedule enough, 
people lose faith and the work goes elsewhere.

'nuff said.

> 
> > 
> > The problem statement has been release. Given the lack
> > of discussion on the email list, it would seem to me
> > plausible to set a near term wg release date. I suggest
> > May 25.
> 
> good. so I will do a WG last call on the spec, and if we receive
> no comments in during that last call (or no comments that 
> would require
> another last call), we can simply move the spec ahead.
> 
> I will make the date Jun, to add necessary padding.
> 
> > 
> > This is all going to slow. I think many people are losing
> > interest because they want to work on solutions and the
> > "fuzzy front end" of problem statements and requirements
> > is taking too long.  Yes, I know these documents are important,
> > but I also know that we can spend until September 2010 analyzing
> > requirements, and still not get it right. Only by working on
> > the solutions will we uncover the really unexpected "gotchas".
> 
> Well, it sounds like we are almost done with requirements, and ready
> to move on. btw, designing a protocol when you have a concrete set of
> requirements is MUCH faster than without. So the time savings 
> can in many
> cases be justified. Further, if someone accuses creeping 
> featurism, you
> can point to a requirements I-D that went through last call.

Yes, yes, yes. But as someone instructed me early on in his career:
analysis can lead to paralysis.

As long as everyone is happy with the idea that we are working on ct
solutions without achieving IESG approval on the problem statement,
never mind the requirements, then I am happy.

> 
> > As for "lining up with the SDOs"? When did this become a schedule
> > driving priority? I think liasing with SDOs is important, but
> > I don't see the need to link up the efforts explicitly. 
> More importantly,
> > I don't see how it can be done. You might link up with one SDO, but
> > there are at least four that I can think of that are of 
> equal importance,
> > and we cannot favour any one over the others.
> 
> ok, perhaps the wording needs to be changed, but the ADs liked it. We
> aren't expecting to send liasons, as you know the IETF 
> doesn't do that.
> This paragraph is an invitation to other SDOs (which, btw, 
> are made aware
> of our new charters), to send people to work with us, if they 
> are interested.
> 
> I, personally, don't see the harm in asking for people to participate
> in our work.
> 
> Is there another way to put it that you would feel more 
> comfortable with?

I really don't want to get into wordsmithing the charter. I like the
original
one just fine ;^}. My only concern was that the involvement of the SDOs was
driving the schedule.

> PatC

GWK

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 14 May 2001 12:25:49 -0700

> why one would want to predict such an event ;^}, but so be it).

right :)

However, the IETF does try to stay on schedule, when possible, but as
you know, outside forces (or in most cases inside forces) delay documents.
This is a heads up for people interested in the work, to give them sort
of an idea as to when the work could be completed.

I will make some slight wording changes to the charter vis-a-vis the
interim meeting. It can be used for the next stage of work if we are
done with requirements.

> that possibility to happen.

Right. If the DT and WG can agree on the requirements, then we can move on.
As you state, new requirements MAY come in later on, but it should be more
difficult for someone to introduce new requirements later on, as opposed
to now. Of course, if we (the WG) clearly forgot something, and it obviously
will be of limited use, then we can discuss it on the list. However, we need
a clear set to begin with, and I think you guys have done a great job.

> analysis can lead to paralysis.

right, and as you agree, requirements gathering phase shouldn't take *that*
long, and as I understand it, you're nearly done.

PatC