Subject: RE: [seamoby] Seamoby Charter Last Call

From: "Gary Kenward" <[email-masked]>
Date: Mon, 14 May 2001 13:08:46 -0400

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.

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.

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

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.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Monday, May 14, 2001 12:40 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 12:34:30PM -0400, Gary Kenward wrote:
> 
> > 
> > It did not come across as serious, but, to be frank, rather
> > flippant. 
> well, that was not the intended message I was targetting. It was 
> to the point (in my mind). In any case...
> 
> > Perhaps you might ask when the requirements draft
> > will be completed, and what people believe are good dates for
> > the follow on work. 
> 
> Right, well my proposed charter was exactly that.
> 
> I would have sent multiple e-mails to everyone, but it seemed 
> more logical
> for me to write the charter, propose it, and then have the 
> group discuss
> it.
> 
> > 
> > As far as I can tell, the design team is near to completion
> > on the requirements draft. It is my intention to have a "last
> > call" in the dt this week. I have reason to believe that we
> > will achieve reasonable consensus. Of course, there is always
> > a possibility this won't happen), however, it does seem reasonable
> > that we do not need 4 more months and an interim meeting to complete
> > the draft. 
> 
> ok, but *do* keep in mind that the document has to go through 
> WG review
> once it is done within the DT. Then the document has to go through
> IETF and IESG review. Perhaps these will not necessary raise points
> that would need to be discussed within an interim meeting, but we 
> (myself and the ADs) felt that scheduling an Interim meeting in the
> milestones could prepare people for possible travel. If there is no
> reason to meet, then the meeting would be cancelled.
> 
> > I think we need milestones that represent the work that has been
> > done, and the progress that can be made.
> 
> Yes, but given history, I prefer to have dates that include a little
> cushion, and the other folks interested in our work (e.g. SDOs) can
> schedule their work based on our dates. If we are done early, then 
> they are happy. If we are late, then it throws off their schedules.
> 
> PatC
>

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 14 May 2001 10:14:08 -0700

> indicated, the dt should be ready to release the reqs

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.

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.

> plausible to set a near term wg release date. I suggest

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.

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

> 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?

PatC

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 May 2001 10:51:11 -0700

> Again, if we are done early, we just look better.

Having spent a year as a Sales Engineer, I'm a firm believer in "Under 
promis, over deliver."  However, having no experience in the whole 
process involved here, I have no (informed) opinion on what a reasonable 
time would be.

> can point to a requirements I-D that went through last call.

My wife, a professional software developer, has a saying that I think 
applies here:  "Write software to spec is a lot like walking on water.. 
  It's much easier when frozen.."

-Mark