Re: Laugh Test: Next Steps in Mobility BOF [nsiim] Request

["James Kempf" <kempf@docomolabs-usa.com>]

Hi Thomas,

A few comments for clarification. In general, I have some concerns about the
recharter plans expressed in the BOF description, but I'll save the details for
the recharter list. Below are the high level bits.

> I'm not so sure how important it is to agree or disagree on how
> different they are. MIPv6 has route optmization with return
> routability. RR is new stuff. AFAIK, there really isn't interest in
> MIPv4 for even bothering with route optimization anymore (though in
> theory, it could pick up the basic RR design from MIPv6).
>
> What I think is worth noting is that MIPv6 vs MIPv4 involves different
> consituancies, and different immediate short-term issues.
>

Yes, this is certainly true.  But I believe there are different constituencies
in MIPv6 itself, in particular, and so a finer grained tuning might be in order.
As mentioned, I'll take the details up on the mipcharter list.

> > What has changed, and rather drastically I think, is how MIPv6
> > supports local link configuration and change, with the demise of the
> > Foreign Agent.
>
> I'm not sure I understand that. Link configuration is not a
> MIP-specific issue and MIP just uses what's available.
>

Right, that's the point. Current mechanisms need improvement for mobility, which
is where some of the work in MIP, IPv6, and Seamoby seem to be pointing in
addition to testing results (Monash, Docomo).

> FWIW, another idea that was tossed around was separating along the
> lines of "deployment issues" vs. "protocol work". But that tends to
> end up having the v4 vs v6 split without actually calling it out.
>

I think it makes more sense to split along architectural boundaries in addition
to the basic MIPv4/MIPv6 split, at least for MIPv6. Arguably, MIPv4 is in
maintenance mode, so there is really little need for a structure that would
faciltate further technology development. I think MIPv6 needs that strucuture,
since it is still under active development.

> > > Another issue to be discussed is to figure out how to best determine
> > > when items should be adopted by the working group(s). As an example,
> > > when items are more of a research nature, it may be best not to
> > > pursue them in the IETF as other organizations may be better suited
> > > for this. Other potential criteria to apply are the existence
> > > of independent implementations and/or deployment plans as  a measure
> > > of interest in a given proposal.
> > >
> > This is an excellent topic but I'm not sure whether this WG is the
> > right place for this discussion, as it is a topic that is applicable
> > to any item that comes before IETF. The problem has been somewhat
> > more severe in MIP, but I can't really see any possibility for
> > resolution at this BOF and so it sets off my rathole
> > detector. Moving this discussion to the Problem Statement WG might
> > be a better bet.
>
> I agree this is an issue for problem-statement as well. But we also
> have an immediate problem of how to recharter the MIP work. I don't
> think we can really wait on problem-statement to figure this all out
> (if indeed it can). Part of the reason for making this a BOF is to
> allow folk from outside the traditional MIP community to come in and
> provide input. Input on this topic would be welcome.
>

OK. One caution here is that my perception of the work currently on the MIP
agenda (from the drafts) doesn't lead me to the conclusion that any of it is
research work. Some of it requires additional prototype implementation and
experimental testing, but I would not characterize it as research. (For one
particular topic, this opinion comes from having some reviewers explicitly tell
me this about a research paper I submitted to a conference on some work done
involving prototyping and testing of a particular protocol from the MIP list of
drafts). I think we must be careful to avoid confusing research with questions
that need prototyping and testing to answer in order to proceed with the
technology development.

> Both ADs will be in the room. And FWIW, I'm not so clear that the
> chairs know exactly what they want the outcome to be. Well actually,
> one thing that has been made clear is that they inherited a WG and
> culture that they feel, in retrospect, had a number of problems. They'd like
> the recharter to also act as a reset on some of those tendencies.
>

I agree the WG had problems and I think some of those problems reflect some of
the discussion on the problem statement list and what we discussed last fall in
the retreat. I think there is an opportunity to address them by using some
solutions that have worked well for IETF in the past, but I am not convinced
that simply just splitting the WG along IPv4/IPv6 lines, and sending some work
to IRTF or dropping it is going to solve them. But that's a topic for the
mipcharter list.

            jak