Subject: RE: [mobile-ip] Protocol Decision Fixed?

From: Phil Roberts <[email-masked]>
Date: Fri, 27 Apr 2001 09:03:40 -0400

Hi,

In the interest of progress it's probably not a good idea to be constantly
revisiting which drafts are working group items.  Some questions
should be asked "What is different now from when we made the decision?"
or "What do we know now that we didn't know when we made the decision?" or
"What requirements have changed since we made the decision?"  
How to proceed is based on working group consensus.

Phil

> -----Original Message-----
> From: Phil Neumiller [mailto:[email-masked]]
> Sent: Thursday, April 26, 2001 3:50 PM
> To: [email-masked]
> Subject: Re: [mobile-ip] Protocol Decision Fixed?
> 
> 
> Phil R.,
> 
> So if I submit a new draft, that competes with the existing 
> two protocol
> proposals will it  be ignored?  If the requirements of the 
> existing proposals
> are suitable then its a horse race right?  What if I have a 
> faster horse?
> 
> Thanks,
> 
> Phil N.
> 
> ----- Original Message -----
> From: "Phil Roberts" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, April 26, 2001 1:28 PM
> Subject: RE: [mobile-ip] Protocol Decision Fixed?
> 
> 
> > Hi,
> >
> >     Is there a question buried in here or are you just 
> venting?  I think the
> > WG is having a fairly productive discussion of requirements 
> right now.  Why
> > don't we finish that before trying to decide whether to 
> revisit the choice
> > of draft to take forward?
> >
> > Phil
> >
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:[email-masked]]
> > > Sent: Thursday, April 26, 2001 12:50 PM
> > > To: [email-masked]
> > > Subject: [mobile-ip] Protocol Decision Fixed?
> > >
> > >
> > > Hi Phil,
> > >
> > >
> > > >I'm hoping we don't restart the protocol selection process.
> > > If there are
> > > >compelling reasons to do so we shall.  The requirements
> > > gathering is more of
> > > >a way to get some convergence on what is really needed in
> > > the protocol.
> > > >There has been a fair amount of reflection that has gone 
> on since the
> > > >working group selected the HMIP approach.
> > > >
> > > >
> > >
> > > A requirements phase is usually gone through in order to 
> define what
> > > the protocol needs to accomplish. Doing a requirements analysis
> > > subsequent to selecting a protocol is a bit like putting on your
> > > bathing suit after you've jumped into the water with your cloths
> > > on. :-) The tendency is to "cook" the requirements to satisfy the
> > > already selected protocol. IMHO, we are seeing a bit of that
> > > now, with the authors of the selected protocol arguing strenuously
> > > against including requirements which their protocol currently
> > > can't support. In addition, they seem to be getting support
> > > from one WG
> > > chair and an AD who may have some vested interest in keeping
> > > the protocol decision fixed, despite the somewhat dubious 
> technical
> > > grounds on which it was selected in the first place.
> > > Meanwhile, those other
> > > members of the working group who have spoken up have largely
> > > been arguing in the
> > > opposite direction.
> > >
> > > If the IESG and WG chairs decide they want to keep the protocol
> > > decision fixed, then let's simply drop discussion of requirements
> > > and rubber stamp HMIP. I'm perfectly fine with that. There's
> > > no point in wasting
> > > transcontinental bandwidth on email any further. Clearly,
> > > we're in the
> > > "political" layer of the IP stack here. :-)
> > >
> > > jak
> > >
> >
> 
>

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 27 Apr 2001 07:03:23 -0700

> How to proceed is based on working group consensus.
and if consistuents believe that a simpler approach, which may be radically
different from existing proposals, would be better, and still meet the
requirements, should we ignore them?

I think not.

To be honest, this recent requirements gathering process, which consisted
primarily of the I-D authors anyways, was sort-of a backwards approach. I
think that the WG should be open to starting the process from scratch, 
gathering the requirements and documenting them, and then allow people
to contribute their protocol of choice.

I think that limiting contributions to existing proposals is the wrong
approach.

my 2 cents,

PatC