Greg:
I am happy that you took this mail in good sprit.
Here are my three comments:
1) Goals and BCP drafts are Ok for novices, but there are no fundamental advancement of knowledge in these drafts. So, they are just the place holders, similar to padding in the data frames to align on certain boundaries;-)
2) If you ignore Alper et. al's link hint draft which pre-exist before DNA group, all other drafts that you mentioned below have been co-authored by just the three authors - yourself, Jin-choi, and Narayna. That, by any definition, is extremely limited participation from the standardization point of view.
3) Honestly, I don't find any thing compelling in the solutions because all we have are variations of fast RA with various names such as det RA, probalistic RA or stochastic RA (waiting for it ;-). RA caching in light weight APs is big no. Unless, someone can prove near-optimality of a pure L3 solution, you are simply advancing something that will do more harm than good.
Thats all that I have to say.
James
On Sat, 12 Feb 2005 Greg Daley wrote :
> > DNA group has been very inactive for quite some time.
> >
> > There are only two messages in February - one is an IESG
> > announcement, and another is from the chair.
>
>I'm sorry, postings here have been pretty light,
>and it seems I'm taking more than my fair share.
>
> > There were no
> > messages in January and only a few messages in December all between
> > Pekka and Jinkchok on the goals draft.
> >
> > It appears that people have lost interest in this group, and not
> > many seem to care any more about the work pursued in this group.
> > There are only 3 or 4 people have any interest left in DNA group?s
> > continued activities.
>
>
>Certainly mailing list traffic has been light.
>
>This is of concern to both the Chairs and the Area
>Directors.
>
>There are, as you say, a small core of people
>actively driving work for this group. The number of
>people is probably about three times as large
>as you say, but the silence of the other
>Mailing list members should be explored.
>We really need to see if the (list) members are
>actually interested in the outputs of those
>currently spending cycles on the development.
>
>It is worth noticing that there are at least
>two implementations of ideas under discussion,
>and interest from manufacturers.
>
> > This is very rare for an IETF group where it is easy to see even a
> > smallest working group attract a few hundred people in meetings
> > (and /or on mailing lists). The main reason is that DNA group
> > hasn?t produced any thing useful ? goals and bcp drafts are just re-
> > iteration of what already exist in IPv4 and IPv6 mobility
> > architecture documents.
>
>At the last IETF session, we didn't have room
>for one of the A-D's to squeeze in (sorry!)
>
>Perhaps we have or will see a waning of interest.
>
>It's worth working out whether this is the case,
>though.
>
>The goals document is a distillation of the
>discussions which originated back in the days of
>MIPv6 development. At the time, the understanding
>of the problem was actually quite poor, and
>JinHyeock and I (and others) proposed some
>solutions which look naive now.
>
>A set of goals to measure solutions against
>is certainly worth having. Now that it has
>been approved, the work can move onto something
>closer to implementation.
>
>The BCPs are similar in that people have previously
>been able to design solutions which work in a
>some constrained environments (Eager Cell Switching,
>etc), but have significant drawbacks in others.
>the BCPs are to give something defined in the
>current standards which is useful, safe and
>reasonably fast.
>
>Personally (biased), I think that these documents
>aren't redundant. As far as I can see there
>weren't really any architecture documents for
>mobility in IPv6 :)
>
>Please be aware: this is not a mobility group.
>It's a connectivity group. Erik Nordmark
>(then an AD) said that he thought the problem was
>broader than movement detection.
>
>So while mobility documents may have had a go at
>defining mechanism for fast reconfiguration
>in a particular network, not everyine will have
>50ms mean delay between RAs, nor FMIPv6.
>
> > Based on past proceedings and discussions, it appears that DNA
> > group cannot propose any solution without Layer 2 event
> > modifications; something that is outside the scope of IETF.
>
>This is not the case.
>
>There are several interesting and widely applicable
>ideas of how to do this at L3.
>
>By monday, a design discussion draft will be
>posted (one of the Design Team products), which
>will shed light on this.
>
>At this stage, DNA-DT discussions have been
>in-camera. Pekka and I aren't even on the list.
>It's not surprising that details aren't leaking
>out onto the DNA list yet then.
>
>While this is not aimed at secrecy, the DT have
>been doing a good job of effectively and efficiently
>evaluating various solutions. New ideas and
>knowledge have been uncovered.
>
>Please wait and see for this (only a few days more).
>
> > I
> > don?t see any interesting proposals being discussed in DNA WG. On
> > the other hand, there are over a dozen actively pursued proposals
> > in IEEE 802.21 ? protocol independent handoff group. For Layer 3
> > solutions, I have not seen any thing better than fast RA draft that
> > exists from pre-DNA group creation.
>
>Well, that depends on your point of view.
>
>There are plenty of drafts in the repository.
>
>
>https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=-dna-&search_rfcnumber=&search_area_acronym=&search_button=SEARCH
>
>You'll notice:
>
>(In the existing protocol space)
>draft-ietf-dna-link-information (None)
>
>draft-narayanan-dna-hosts-bcp
>draft-narayanan-dna-routers-bcp
>draft-jinchoi-dna-cpl
>draft-hong-dna-if-l2
>
>(in the proposal space)
>draft-narayanan-dna-rrd
>draft-daley-dna-det-fastra
>draft-daley-dna-nonce-resp
>draft-daley-dna-prob-fastra
>
>More drafts are expected on monday or by monday.
>
>As you know, a lot of the drafts
>come from a small core of people.
>If they're missing something, then people should
>contribute a more effective solution.
>
>
> > Yes, I know two or three active people in this group are trying to
> > create some sort of solution document, but it appears, based on
> > rather poor traffic on the mailing list, that mobility community
> > has already given up.
>
>Perhaps you are correct with regard to mailing list activity.
>
>It is certainly worth finding out if people
>are interested in the outputs of the group.
>
>Another alternative idea may be that while people
>are interested in the outputs, they are unable
>to devote time to the document and protocol
>development themselves (except for example
>at IETF).
>
>Perhaps we can poll people as to what their
>current level of interest is, and determine if
>some actions need to be taken.
>
>Certainly there needs to be more input on the ML
>for the IETF process to be fully effective.
>Lulls with furious activity around meeting times
>have the potential of blindsiding the group if
>new technical details come out too late to be fixed
>before a session.
>
> > What is the point of creating a document in which most people seem
> > to have lost the interest? In my opinion, the group should become
> > dormant or be closed until IEEE comes up with better event
> > definitions for layer 2 for facilitating faster hand-off.
>
>If people have lost interest and don't
>want to see a document, please speak up.
>
>If you're interested, but quiet, please indicate
>if this is so.
>
>Your advice on how best to advance the group
>is also welcome.
>
>(Chair Hat Off)
>
>Personally, being biased, I think that new
>trigger primitives are only half of the story.
>
>It may take a long time to upgrade or replace
>the majority of deployed link-layer equipment,
>especially those with a firmware or part hardware
>implementation.
>
>Software upgrades on host and routing
>infrastructure are either more common (for routers)
>or don't require co-ordination (for hosts).
>This may give L3 solutions earlier momentum
>than new L2 solutions.
>
>It's also worthwhile to remember that while
>IEEE's protocols are pervasive, they're not
>universal.
>
>Thanks again for having the courage to
>express an opinion.
>
>Greg