Subject: [babel] Buenos Aires: Babel BoF or WG creation?

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 11 Jan 2016 18:34:09 +0100

Dear all,

Sorry for the long silence, my teaching season has only just ended.

I'll definitely be going to Buenos Aires, and I know that a number of
people interested in Babel will be going too.  Hence, I think the very
least we can do would be to organise a Babel BoF at IETF 95.

In an ideal world, however, we'd be able to set things up so that we can
create a "Low complexity distance-vector protocol for hybrid networks"
working group at Buenos Aires.  I'm not sure how to proceed -- what is
required so we can create the working group straight away?

  - a proposed charter?
  - jauge whether there is enough interest for a WG?
  - a pair of chairs?

So how do we proceed from here?

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Jan 2016 18:16:04 +0000

I think the key is to identify the work that we want to do.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 11 Jan 2016 20:02:19 +0000

On 1/11/16, 12:34 PM, "babel on behalf of Juliusz Chroboczek"
<[email-masked] on behalf of [email-masked]> wrote:

Juliusz:

Hi!

>So how do we proceed from here?

Just pointing at dates/forms:

2016-02-19 (Friday): Cut-off date for BOF proposal requests to Area
Directors at UTC 23:59. To request a BOF, please see instructions on
Requesting a BOF (http://www.ietf.org/iesg/bof-procedures.html).

You should obviously work with an AD well before this deadline.  As Ted
already said, a clear sense of what the work will be is one of the keys.
You will eventually need to fill out the information here:
http://trac.tools.ietf.org/bof/trac/

Alvaro.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 11 Jan 2016 22:08:30 +0100

Hi Ted,

> I think the key is to identify the work that we want to do.

You mean at the BoF, or as a WG?

The goal of the BoF would be to create a WG.  I have no idea how WGs are
born, so I kindly request guidance from you, Mark, Joel, Alvaro, and any
other Wise Men or Women who are willing to help.

The goal of the WG would be to define a Standards Track protocol that is
roughly equivalent to the combination of RFC 6126 and RFC 7298 ("RFC 6126
Babel").  Unless there is a strong reason to do otherwise, the resulting
protocol should be backwards compatible with RFC 6126 Babel.

At the very least, that entails:
  
  - identifying any issues with RFC 6126 Babel that might justify an
    incompatible change (bumping the protocol's version number);

  - making a precise list of clarifications required to RFC 6126, based
    exclusively on implementation experience (there are 4 independent
    implementations of RFC 6126 now);

  - merging RFC 7298 into RFC 6126.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 11 Jan 2016 22:13:28 +0100

> 2016-02-19 (Friday): Cut-off date for BOF proposal requests

Noted, thanks.

> You should obviously work with an AD well before this deadline.

Right.  Perhaps you could advise me (perhaps by private mail) who to
contact?

> As Ted already said, a clear sense of what the work will be is one of
> the keys.  You will eventually need to fill out the information here:

Which means that we need a friendly AD, two friendly chairs, and a rough
idea of how many people will attend.

-- Juliusz

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Jan 2016 16:24:06 -0500

Even if all we get is a BoF, the best starting point is a clear 
description of what we hope the eventual working group is to accomplish. 
  Given that, we can figure out what open items a BoF should focus on, 
potentially including determining interest and a set of people 
interested in doing work.

So, as soon as we have a decent description of the goal, get that onto 
the BoF wiki.  We can then work with ADs for sponsorship and finding BoF 
chairs.  If we make enough progress that the AD and IESG decide to 
charter the WG before Buenos Aires, all well and good.  If not, we have 
the BoF request in.  That request can also serve as a public anchor for 
further discussion of what we are trying to do.

Yours,
Joel

On 1/11/16 4:08 PM, Juliusz Chroboczek wrote:
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: "Russ White" <[email-masked]>
Date: Mon, 11 Jan 2016 23:50:52 -0500

> required so we can create the working group straight away?

I would think we need a more specific use case than "hybrid networks..." We
could go back to the ideas on the list from earlier -- a lightweight
protocol for spine and leaf data center fabrics, a protocol that supports
hub and spoke and other topologies well, maybe some others... I'd like to
have at least one other use case than homenet just to make certain we have
some sort of wider community interest to drive this forward. I don't know if
homenet is going to produce enough fire to cook this thing (just based on
current interest levels). 

Of course, that bit is up to the AD's, so...

:-)

Russ

---

From: Tim Chown <[email-masked]>
Date: Tue, 12 Jan 2016 10:50:01 +0000

Hi Juliusz,

> On 11 Jan 2016, at 17:34, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear all,
> 

Have a read of RFC 5434 - lots of good advice in there.

Tim

---

From: Ray Bellis <[email-masked]>
Date: Tue, 12 Jan 2016 12:52:16 +0000

On 12/01/2016 04:50, Russ White wrote:
> I'd like to have at least one other use case than homenet just to
> make certain we have some sort of wider community interest to drive
> this forward. I don't know if homenet is going to produce enough fire
> to cook this thing (just based on current interest levels).

Homenet is ultimately just going to be a consumer of routing protocols,
and our charter prevents us from actually working on them within the WG.

So, whilst we can no-doubt provide interested parties who will watch
with avid interest and contribute where they can, we're not well endowed
with routing experts who can work on the minutiae.

Ray

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 12 Jan 2016 22:36:45 +0100

Hi Russ,

> hub and spoke and other topologies well, maybe some others...

As far as I am aware, Babel has seen actual production deployment in three
kinds of situations:

  (1) in trivial networks, as a (double-stack) RIP replacement;

  (2) in overlay networks interconnecting servers over a mixture of wired
      Ethernet and low- and high-latency tunnels ("distributed could");

  (3) in community networks consisting of a mixture of wired ethernet, high-
      and low-latency tunnels and lossy wireless links.

AFAIK, Babel has not seen any deployment in data centers.  Babel has also
not taken over pure mesh networks, where there are perfectly fine protocols
available (notably OLSR-ETX and OLSRv2 with DAT).

So what are the features of Babel that make it appealing in those use
cases?  Perhaps some of you see more reasons, but in my opinion:

  - in case (1) -- it works and has a solid reference implementation;

  - in case (2) -- it has support for varying metrics depending on the
    tunnel RTT and is able to remain stable in the presence of continual
    fluctuations;

  - in case (3) -- (i) it has support for varying metrics depending on the
    packet loss rate and (ii) supports arbitrarily mixing mesh-style
    (non-transitive links with IP addresses on loopback) and
    Internet-style (transitive links with IP prefixes on links) topologies
    in a single routing domain.

So how would you express Babel's strengths in a single phrase?  I'm not
particularly attached to the "hybrid network" formulation, but I don't see
a better wording.

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Thu, 14 Jan 2016 10:02:13 -0500

> particularly attached to the "hybrid network" formulation, but I don't see
a
> better wording.

The problem is we need to find interesting use cases to get routing folk
interested in working on the protocol -- ie, we have to find a niche it will
fit in too and solve some set of problems that is larger than homenet or
wireless/wired (or hybrid) networks. 

>  Ethernet and low- and high-latency tunnels ("distributed could");

Might be interesting, but I'm not certain where/how this applies. The only
thing I can think of is possibly a mobile provider network with a virtual
endpoint box in a DC connected to the handset or other wireless device. I'm
not certain we'll get Verizon interested in this sort of thing, though, as
BGP seems to be the "solution of the day" for most everything, and I'm not
certain we want another control plane running in the overlay (it would be
hard to justify). I was hoping to find more focused use cases that can be
interesting, larg'ish scale, and cordoned off from the "rest of the world"
in some sense. 

:-)

Russ

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 14 Jan 2016 18:10:10 +0100

> wireless/wired (or hybrid) networks. 

It looks like it's a huge niche to me -- every single network that uses
a tunnel or a wireless link for transit is "hybrid" according to this
definition.  (It might not be fashionable with the routing people, but
that doesn't make it any less important.)

> Might be interesting, but I'm not certain where/how this applies.

  https://www.erp5.com/NXD-re6st.Two.Page

-- Juliusz

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 19 Jan 2016 13:52:10 -0000

I love routing protocols and playing with a "new " one could be great fun, but
Ted nailed it when he said "What work needs to be done?" He might have added
"And why do we need a WG to do that work?"

A further key question for the proponents here (for example, at a BoF) is going
to be: why do we ned another routing protocol? That is: what problem is Babel
solving that both needs to be solved and is not already solved or could be
solved by a minor mod to an existing protocol?

Commercial answers to that question might be acceptable (e.g., "everyone wants a
new protocol, so get over it"), but it should be clear that introducing new
protocols into spaces where protocols already exist does not enhance
interoperability even if it enhances market choice. Therefore some caution will
be needed to scope the proposed deployment (as suggested in others' emails on
this thread) both so that interop issues can be avoided and so that the protocol
can be optimised for its intended environment.

I suppose one last warning is needed for the supporters of Babel. Creating a WG
will involve turning the protocol over to the community: all control of the
protocol will be surrendered, and it may evolve in unexpected ways.

Adrian

> -----Original Message-----
> From: babel [mailto:[email-masked]] On Behalf Of Juliusz Chroboczek
> Sent: 11 January 2016 17:34
> To: [email-masked]
> Subject: [babel] Buenos Aires: Babel BoF or WG creation?
> 
> Dear all,
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Jan 2016 15:33:02 +0000

> "And why do we need a WG to do that work?"

This is really a layer 9 issue.   I don't think that the IETF will accept a Babel proposed standard that is AD sponsored.   I had a hard enough time getting depth-first forwarding through the IESG that way as an Experimental document.

> solved by a minor mod to an existing protocol?

This isn't really the correct question.   We already have the routing protocol we are discussing, and in a stronger sense than any similar competing routing protocol of which I am aware.   E.g., you could perhaps argue that EIGRP is a competing protocol, but there is no IETF standard describing it, and efforts to make one failed (according to what I have been told, apologies if I got that wrong).   The question is not "do we need it," and hasn't been for some time.   The question is, "is it in good enough shape."

> interoperability even if it enhances market choice.

The decision taken by the Homenet working group is provisional, but definite.   I believe it is sufficient motivation for doing the work, if there are people interested in doing it.   It would be harmful to reverse it for any reason other than a genuine consensus that Babel actually won't work.

> Therefore some caution will

Yes, I think this is exactly right.   Personally, I would prefer to see the work start from the very constrained scope of the current proposed application (homenet) and only expand out of that scope if concrete proposals are made and obtain consensus.

> protocol will be surrendered, and it may evolve in unexpected ways.

I think that as long as this is a constructive process and doesn't drive us off into the weeds, that would be a very good thing.   I think that the working group should be skeptical of gratuitous changes, but welcoming to useful improvements.

BTW, participants in the homenet discussion may feel that there was a fair amount of layer 9 activity.   I don't think this layer 9 stuff comes out of anybody trying to be deliberately obstructive--it seems to me in retrospect that there was a lot of talking past each other without realizing it.   In order for this process to work, I think some patience will be required of all participants, because I think there are definite language barriers.   If you feel like the person you're talking to is being obstructive, it's probably worth trying to carefully unpack what they are saying before jumping to conclusions.  I suppose I say this as much for my benefit as anyone else's.  :)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 19 Jan 2016 17:39:50 +0100

> to be: why do we ned another routing protocol?

We already have another routing protocol -- Babel is here to stay whether
it gets standardised by the IETF or not.  Babel is being used experimentally
by the Homenet WG, Babel is being used in production by a number of
community mesh networks, and Babel is being used in production by a number
of startups.

So the question is somewhat different -- do we need another standard, or
is the current Experimental RFC good enough?  Both the community networks
and the startups are happy with the current standardisation status of
Babel (reasonably complete and comprehensible experimental RFC with
a rock-solid and well-maintained open-source reference implementation well
integrated into OpenWRT).  I probably wouldn't be trying for Standard
Track if it weren't for Homenet.

> That is: what problem is Babel solving that both needs to be solved and
> is not already solved or could be solved by a minor mod to an existing
> protocol?

A sea of electronic ink has been expended on this question in the Homenet WG.

> Therefore some caution will be needed to scope the proposed deployment

Adrian, we're not "proposing deployment", we're deploying right now.  The
question is not whether to deploy, the question is whether to standardise.

> Creating a WG will involve turning the protocol over to the community:
> all control of the protocol will be surrendered, and it may evolve in
> unexpected ways.

We're trying very hard to be part of both the IETF community and the
community that's currently deploying Babel.  Obviously, being part of two
mostly disjoint communities can lead to friction, we'll need to be careful
to meet the needs of both.

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 21 Jan 2016 12:14:16 +0000

---- On Tue, 19 Jan 2016 13:52:10 +0000 Adrian Farrel<[email-masked]> wrote ---- 
 > "And why do we need a WG to do that work?" 
[...]

Hello all.

My own interpretation is that an already existing informal goal of the already existing informal working group is to study the potential gain of applying the Babel protocol solution space to new problem spaces as for mesh networks it is already delivering the intended results. I understand different people may disagree whether this goal statement is particular enough for an IETF working group charter, though experienced engineers may agree that fully formalizing a development work is one thing and actually getting it done is at times another.

I am personally happy with any form of working group that keeps it a good research and development group.

-- 
    Denis Ovsienko

---

From: "Russ White" <[email-masked]>
Date: Tue, 26 Jan 2016 15:37:54 -0500

> We already have another routing protocol -- Babel is here to stay whether
it
> gets standardised by the IETF or not.  Babel is being used experimentally
by
> the Homenet WG, Babel is being used in production by a number of
> community mesh networks, and Babel is being used in production by a
> number of startups.

Which again begs the question -- what is the point here? 

1. To get more routing folks involved in BABEL?
2. To expand the scope of BABEL?
3. To keep its scope, form, application, etc., the same, and just ask for an
RFC number so it's all "official?"

We can't form a WG based on, "we'd like one." There has to be a reason to do
the work (what new thing is being done that's not already done?"), and there
has to be interest in doing it from a broad enough community to spread the
work around and "make it happen." Given the perception is that the "mesh
networking problem" is "solved," what's left to do?

We really need an answer to that question before we can build a WG. I'm not
trying to be a pain, just trying to actually figure out what the point is --
WG's with no goal and no community don't do well. It's just a matter of
history, no matter how much we might like it to  be different.

Hence my original set of suggestions -- make it a distance vector working
group to look at DFS numbering systems, EIGRP, and BABEL. Or expand the
scope of BABEL to something the community is already interested in. For
homenet, I couldn't get the folks who actually make this gear to even answer
my emails (not even to say "I'm not interested")... Which implies there's
not a lot of real interest from the folks making gear that will operate in
that space to participate. This doesn't seem to imply there's enough
interest to find the people needed to actually do the work (don't
underestimate the amount of work involved in running a WG -- and the
problems involved in having too few people to actually review documents,
etc.).

:-)

Russ

---

From: Dave Taht <[email-masked]>
Date: Tue, 26 Jan 2016 12:50:46 -0800

> that space to participate. This doesn't seem to imply there's enough

I have seen nearly zero interest from anyone "making gear" in the
homenet wg's outputs, not just the babel component of it.  As for me,
I have nearly given up participating in ietf processes entirely.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Jan 2016 15:58:23 -0500

At least from where I sit, the point would be to address those open 
issues that are keeping Babel considered experimental rather than 
Proposed Standard.

Having a working group to create a new DV protocol seems likely to be 
interesting, fun, and a complete waste of time.

Addressing minor points, like incorporating the security elements and 
agreeing on the most useful default metric size, seems to have value.

We could also work on explaining better why folks are finding Babel 
useful, so that the work is not dependent upon a few people be3ing able 
to explain it well.

Yours,
Joel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 27 Jan 2016 08:57:42 +0100

> Which again begs the question -- what is the point here? 

To write a revised RFC for Babel.

Babel is one of the rare non-standard routing protocols that has been
entirely described and has three independent, open source implementations.
While RFC 6126 serves us well (in great part thanks to Joel's input),
there's a need for a 6126-bis that clarifies a few issues and integrates
RFC 7557 (the extension mechanism).  6126-bis could be another individual
submission, but some people appear to prefer a Standards Track document.

(The above should not be taken to imply that the 6126-bis must be
compatible with 6126, although making the new protocol incompatible should
not be done without careful consideration.)

> There has to be a reason to do the work (what new thing is being done
> that's not already done?"),

Please let me know if the above answers this question.

> Given the perception is that the "mesh networking problem" is "solved,"
> what's left to do?

I could be wrong, but it seems to me that there's no IETF protocol that
can deal efficiently with both prefix-based and meshy routing in a single
routing domain (the mesh extensions to OSPF have been abandoned, AFAIK).

I also believe that there's no Standards Track protocol that can deal with
a mixture of good and bad links without manual configuration (Henning's
DAT metric is Experimental, and David's extensions to IS-IS haven't been
written down).

> group to look at DFS numbering systems, EIGRP, and BABEL.

Russ, I like EIGRP very much, and I can certainly relate to your wish to
revive it.  However, I'm not sure that trying to ride Babel's coattails is
the most productive way to do so.

(If you're serious about reviving EIGRP -- producing an open-source
reference implementation would be a good start.)

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 27 Jan 2016 21:33:43 +0100

Juliusz Chroboczek <[email-masked]> writes:

> entirely described and has three independent, open source
> implementations. While RFC 6126 serves us well (in great part thanks
> to Joel's input), there's a need for a 6126-bis that clarifies a few
> issues and integrates RFC 7557 (the extension mechanism). 6126-bis
> could be another individual submission, but some people appear to
> prefer a Standards Track document.

+1 on making this a working group standards track document.

While doing interoperability-testing between different implementations,
we have run into a couple of things that could use clarification (though
they are fairly minor in the greater scheme of things). I believe the
input of a working group is valuable in this process, and am definitely
interested in participating in this myself (and will also be going to
Buenos Aires).

Besides, no one says it has to be a Herculean effort spanning decades...

-Toke

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Jan 2016 16:15:28 -0500

I certainly hope that it wouldn't be a Herculean effort spanning decades :-)

To me, there are two large open questions.  The first is what is the
applicability
or need and work to be done.  While those in the mesh-networking world
may have a very clear idea of why OSPF, ISIS, RIP, etc. don't work, clearly
describing the requirements and applicability is necessary.  From that and
existing deployments, it sounds like one piece of work is improving RFC 6126
so that it is of the quality and has the review to go standards track.
Nailing
down the applicability/requirements and a first list of extensions and
improvements
or issues into one or two drafts would be a good first step.

The second open question is whether there is a community that is willing and
able to do the work.  That work can be done on the mailing list; it can be
done
at IETF and at interim meetings elsewhere as appropriate.  Without people
to do
the work, a WG will fail.

The BoF deadline is soon.  If there's real interest for Buenos Aires,
moving to a list
of what documents to write and who is going to write them would seem to me
to
be a useful first step.

Joel, Margaret, Russ, and Ted all have a good amount of IETF experience as
far
as process and the types of questions that get asked.  They are all being
personally
motivated to help; the suggestions are to try and get to a functionally
community
with a clearly defined and needed task.  That's what can turn into a WG.

Personally, I do not see the goal as a distance-vector IGP Working Group.
It could
be interesting to consider if there are features from other protocols that
might be
needed in Babel for particular use-cases - but that is very different.
Beauty competitions
among technologies are rarely pretty or useful.

Regards,
Alia

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 28 Jan 2016 17:54:42 +0100

> applicability or need and work to be done.

That's two questions :-)

I agree that I'll need to write a proper applicability document.  Last
time I tried, I ended up with

  https://tools.ietf.org/html/draft-chroboczek-babel-doesnt-care

which a number of people found entertaining but perhaps overly flippant.
I have good hope that Section 1.1 of this document could serve as the
basis for a formal (and boring) applicability statement.

> While those in the mesh-networking world may have a very clear idea of
> why OSPF, ISIS, RIP, etc. don't work, clearly describing the
> requirements and applicability is necessary.

Right.  Please see Sections 3.2 and 3.3 of the Doesn't Care draft, and let
me know if that's a suitable basis.

> The second open question is whether there is a community that is willing
> and able to do the work.

Yes, there is, although as you guessed many of us cannot afford the time
and expense of going to IETF meetings.  We are quite used to working over
mailing lists.

> It could be interesting to consider if there are features from other
> protocols that might be needed in Babel for particular use-cases - but
> that is very different.

I'm going to fight tooth and nail against extending the core protocol --
any extensions should go into protocol extensions.  On the other hand,
I think the extension mechanism could be made more powerful.

> Beauty competitions among technologies are rarely pretty or useful.

Very well put.

Thanks for your input,

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Sat, 30 Jan 2016 20:40:39 -0500

> implementations.

Two points --

- It's actually not. There are a number of others.

- This isn't about building a new RFC -- having a working group isn't about
building a new RFC, ever, really. It's about helping organize a community of
people interested in a particular line of work. I don't see a community. We
could try to expand the scope to create a community, or we could continue
limping along the way we are. Creating a working group to work on a single
RFC update, when there's no real community for an ongoing commitment to
expanding the scope and usefulness of the protocol -- I don't see where that
goes.

> > Hence my original set of suggestions -- make it a distance vector
> > working group to look at DFS numbering systems, EIGRP, and BABEL.
> 
revive
> it.  However, I'm not sure that trying to ride Babel's coattails is the
most
> productive way to do so.

*sigh* It's not about coattails -- it's about finding enough work that's
interesting to actually build a community. Again, working groups are
communities. We can call four people with a single RFC to modify a working
group, I guess, but it's not really the way the process is designed to run.

FYI, there is an open source implementation of EIGRP out there -- check git.
But my statement was more general, rather than specific. I'm not trying to
revive anything, I'm just trying to find some community that's actually
interested enough in the work to sustain an actual working group.

:-)

Russ

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 31 Jan 2016 15:30:42 +0100

> - It's actually not. There are a number of others.

You've certainly caught my attention.  Which protocol do you have in mind?

> limping along the way we are.

Right, I see where you're coming from.

I still think it's a dangerous proposition -- I'd feel much more
comfortable starting with a highly focused WG, chartered to do something
that we have a chance of achieving within a few months, and only consider
expanding the scope after our initial success.  As Alia put it, if we're
not focused enough, we risk getting into a "protocol beauty contest".

> FYI, there is an open source implementation of EIGRP out there

Yes!  (And it's almost a year old -- I wish I had gotten my grubby hands on
the code earlier.  If you'll please excuse me, I've got some reading to do.)

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Sun, 31 Jan 2016 10:22:47 -0500

> You've certainly caught my attention.  Which protocol do you have in mind?

There are at least two I know of -- I'll email you off list.

> I still think it's a dangerous proposition -- I'd feel much more
comfortable
> starting with a highly focused WG, chartered to do something that we have
a
> chance of achieving within a few months, and only consider expanding the
> scope after our initial success.  As Alia put it, if we're not focused
enough, we
> risk getting into a "protocol beauty contest".

I would be okay with that... IE, work on one protocol 'til done, see what
else is out there, etc. Carefully controller charter. The main thing is to
get more people involved, IMHO. 

The one problem is sorting out how and where to manage any overlap with
RTGWG.

> Yes!  (And it's almost a year old -- I wish I had gotten my grubby hands
on the
> code earlier.  If you'll please excuse me, I've got some reading to do.)

Donald Sharp, I think is the primary contributor. Drop me a line off list if
you have questions, and I'll either answer them, or put you in touch with
Donald, or both. Overall, I actually think D-V/DUAL based stuff is useful
for specific situations, so it's useful to keep the concepts and the
research in this direction going in the most optimal way possible. I know I
represent a minority opinion, though...

:-)

Russ